Ce que plus de 2 000 sites WordPress nous ont appris sur les paramètres de sauvegarde

Votre sauvegarde bloque au même endroit à chaque fois.

Vous cherchez donc de l'aide. Un fil de discussion sur un forum dit de réduire la taille des blocs. Un autre dit de désactiver la compression. Vous essayez les deux.

La sauvegarde bloque toujours. Ou elle se termine maintenant, mais elle prend beaucoup plus de temps qu'avant.

Ce conseil a bien résolu la sauvegarde de quelqu'un. Il l'a simplement résolue sur son serveur, et le vôtre peut ne pas autoriser les mêmes choses.

Au lieu d'échanger des anecdotes, nous avons examiné les données. AutoTune, le testeur de paramètres intégré à Duplicator, exécute de vraies sauvegardes de test sur le serveur d'un site jusqu'à ce qu'une se termine. Nous avons examiné où 2 000+ sites ont abouti.

Dans cet article, je vais passer en revue ces résultats et expliquer ce qu'ils signifient pour vos paramètres de sauvegarde.

À propos de ces données : Ces chiffres proviennent de sites qui ont exécuté AutoTune. Ils ne constituent pas un échantillon représentatif de tous les sites WordPress ou utilisateurs de Duplicator. Les partages de configuration décrivent les résultats de réglage réussis, tandis que les chiffres de succès globaux décrivent les sessions de réglage.

Table des matières

Principales conclusions

Pour ceux qui veulent d'abord les chiffres, voici ce que montrent les données. Chaque chiffre provient des données d'utilisation d'AutoTune de Duplicator.

• AutoTune a modifié au moins un paramètre de sauvegarde dans environ 9 sessions de réglage sur 10. Cela ne signifie pas nécessairement que les paramètres précédents étaient défectueux.
• Shell ZIP avec mysqldump représentait environ la moitié des configurations réussies.
• PHP ZIP représentait un peu moins de 4 configurations réussies sur 10, tandis que DupArchive en représentait moins de 1 sur 10.
• Mysqldump est apparu dans environ 2 configurations réussies sur 3. L'exportation de base de données basée sur PHP gérait le reste.
• La quasi-totalité des configurations réussies utilisaient la compression et la taille de bloc de 128 Mo.
• Environ 9 sessions de réglage réussies sur 10 se sont terminées lors de la première tentative de test.
• Plus de 8 sessions de réglage sur 10 ont trouvé une configuration réussie.

EN BREF : La plupart des sites qui ont exécuté AutoTune ont été déplacés vers des paramètres de sauvegarde différents, mais aucune configuration unique n'a fonctionné partout. Exécutez AutoTune (inclus dans Duplicator 5.0, y compris la version gratuite) pour trouver les paramètres qui fonctionnent le mieux sur votre serveur. Si rien ne fonctionne, demandez à votre hébergeur quelle est sa limite de temps PHP et son espace disque.

Comment AutoTune teste-t-il votre serveur ?

AutoTune de Duplicator exécute de vraies sauvegardes de test sur votre site. Il commence par la configuration la plus rapide. Si un test échoue, il ajuste les paramètres et essaie une autre configuration.

Une fois qu'un test réussit, il enregistre automatiquement ces paramètres. Si le problème est une limite du serveur qu'aucun paramètre ne peut modifier, il vous l'indique à la place.

AutoTune est inclus dans Duplicator 5.0 et versions ultérieures, dans les versions Lite et Pro.

AutoTune ajuste quatre groupes de paramètres de sauvegarde. Voici ce que chacun contrôle :

• Moteur d'archive et compression : Comment les fichiers sont empaquetés dans la sauvegarde.
• Mode ZIP et taille de bloc : Comment le traitement des archives est divisé en étapes.
• Moteur de base de données et mode de vidage : Comment la base de données est exportée.
• Réduction de la charge du serveur : Si le traitement ralentit pour réduire la pression sur le serveur.

Son Aperçu du serveur rapporte également des informations sur votre environnement, y compris les limites PHP, la disponibilité du moteur et les vérifications de traitement en arrière-plan.

Si vous souhaitez l'exécuter sur votre propre site, je vous guide étape par étape dans Comment réparer une sauvegarde WordPress échouée.

Combien de sites ont fini avec des paramètres différents ?

AutoTune a modifié au moins un paramètre de sauvegarde dans environ 9 sessions de réglage sur 10.

C'est une part substantielle, mais « modifié » ne signifie pas « corrigé une configuration cassée ».

Un site pouvait utiliser des paramètres qui complétaient les sauvegardes de manière fiable, tandis qu'AutoTune trouvait une option prise en charge plus rapide. Un autre site pouvait avoir besoin d'un repli car sa configuration existante ne pouvait pas se terminer.

Le premier test d'AutoTune utilise sa propre configuration de départ, pas les paramètres que le site avait déjà. Ainsi, une session peut réussir du premier coup et modifier quand même les paramètres du site.

Il y a plusieurs raisons de revoir vos paramètres de sauvegarde :

• Le site a été déplacé vers un autre serveur.
• Votre hébergeur a modifié sa configuration PHP ou ses limites de ressources.
• Vos fichiers ou votre base de données ont augmenté.
• Vous avez copié les paramètres d'un autre site.
• Vous n'avez jamais testé d'alternatives aux paramètres par défaut.

Les données ne nous disent pas à quel point ces situations sont courantes sur tous les sites WordPress. Elles montrent que l'exécution d'AutoTune a souvent entraîné une modification de la configuration parmi les sites qui l'ont utilisé.

Si votre environnement d'hébergement a changé, retester est plus utile que de supposer que vos anciens paramètres conviennent toujours.

Existe-t-il une meilleure configuration de sauvegarde pour WordPress ?

Il n'existe pas une combinaison que tous les serveurs peuvent utiliser.

Certains hébergeurs fournissent des outils d'archivage et de base de données en ligne de commande. D'autres restreignent ces outils mais prennent en charge des alternatives basées sur PHP. Les limites de ressources affectent également les configurations qui peuvent se terminer.

Voici où les configurations AutoTune réussies ont abouti :

Configuration	Part des configurations réussies	Ce dont votre serveur a besoin	Où cela s'intègre
ZIP Shell avec mysqldump	Environ la moitié	Outils ZIP accessibles, fonctions de commande PHP activées et accès à mysqldump	Serveurs qui autorisent leurs propres outils. C'est généralement la combinaison la plus rapide lorsque le serveur la prend en charge.
ZIP PHP (avec mysqldump ou export PHP)	Un peu moins de 4 sur 10	L'extension PHP ZipArchive	Hébergeurs qui restreignent les outils en ligne de commande mais ont ZipArchive activé
ZIP Shell avec l'export de base de données PHP	Environ 1 sur 20	Support ZIP Shell, sans dépendre de mysqldump	Serveurs qui autorisent les outils ZIP mais où mysqldump n'est pas disponible
DupArchive avec l'une ou l'autre méthode d'export de base de données	Moins de 1 sur 10	Exigences normales du serveur pour Duplicator ; aucun exécutable ZIP externe ni extension ZipArchive requis	Serveurs où les autres moteurs n'ont pas pu terminer. Il crée la sauvegarde en petits morceaux sur plusieurs requêtes.

Chacune de ces options est la bonne réponse quelque part. La question est de savoir laquelle convient à votre serveur.

La configuration la plus rapide représentait environ la moitié des configurations réussies

Shell ZIP avec mysqldump représentait environ la moitié des configurations réussies. En incluant son module d'exportation de base de données PHP, Shell ZIP représentait un peu plus de la moitié.

Shell ZIP utilise les propres outils ZIP du serveur plutôt que de construire l'archive entièrement via PHP. C'est souvent plus rapide que ZIP PHP lorsque le serveur le prend en charge.

L'option Shell ZIP de Duplicator nécessite les outils zip et unzip ainsi que les fonctions PHP popen() et pclose() activées.

Mysqldump est un outil de ligne de commande distinct pour l'exportation de la base de données. Duplicator doit pouvoir y accéder et l'exécuter.

Lorsque ces outils sont disponibles, ils peuvent constituer une combinaison efficace. Lorsqu'ils sont indisponibles ou restreints, une alternative basée sur PHP peut être plus appropriée.

PHP ZIP couvre le reste

Un peu moins de 4 configurations réussies sur 10 ont utilisé PHP ZIP en mode multi-thread.

PHP ZIP ne dépend pas d'exécutables ZIP externes, mais il nécessite que l'extension ZipArchive de PHP soit installée et activée.

Cela en fait une alternative utile lorsqu'un hébergeur restreint les outils en ligne de commande.

Il peut être associé soit à mysqldump, soit à l'exportation de base de données PHP. La création d'archives et l'exportation de bases de données sont des tâches distinctes, votre serveur peut donc prendre en charge un outil en ligne de commande pour l'une mais pas pour l'autre.

DupArchive est le filet de sécurité pour les serveurs les plus difficiles

DupArchive représentait moins d'1 configuration réussie sur 10.

Ce petit nombre est important, car il montre qui en a besoin. Des tailles de morceaux plus petites et une réduction de la charge du serveur n'apparaissent que dans une poignée de configurations réussies, et la plupart d'entre elles utilisaient DupArchive. Ce sont les serveurs les plus contraints dans les données.

DupArchive est le propre format d'archive de Duplicator. Il crée la sauvegarde en petits morceaux sur plusieurs requêtes, ce qui lui permet de dépasser les limites de temps strictes qui arrêtent les autres moteurs en cours de route.

Sur des serveurs comme ceux-ci, c'est ce qui permet à une sauvegarde de se terminer.

Mais ce n'est pas la solution par défaut pour chaque sauvegarde lente. La plupart des serveurs n'en ont jamais eu besoin.

Mysqldump ou PHP : quelle méthode de sauvegarde de base de données fonctionne le plus souvent ?

Mysqldump est apparu dans environ 2 configurations réussies sur 3. L'exportation basée sur PHP représentait environ 1 sur 3.

Si mysqldump n'est pas disponible, l'exportation PHP offre à Duplicator une autre façon d'exporter la base de données. Cela dépend toujours des ressources serveur adéquates, de l'accès à la base de données et des permissions.

Quels correctifs courants étaient généralement inutiles ?

Trois conseils apparaissent dans les fils de discussion des forums concernant les sauvegardes lentes ou échouées. Voici comment chacun d'eux se compare aux configurations réussies dans nos données.

Une chose à garder à l'esprit en lisant ceci. AutoTune s'arrête dès qu'une sauvegarde test se termine, donc la configuration finale montre ce dont une sauvegarde avait besoin pour se terminer sur ce serveur, pas tous les paramètres qui auraient pu fonctionner.

• « Désactiver la compression. » Presque toutes les configurations réussies utilisaient la compression. La désactiver est rarement le changement qui transforme une sauvegarde échouée en une sauvegarde fonctionnelle. Si votre sauvegarde stagne, le moteur d’archivage et les limites de votre hôte sont de meilleurs endroits où chercher.
• « Toujours utiliser DupArchive sur l’hébergement mutualisé. » Moins de 1 configuration réussie sur 10 utilisait DupArchive, et la plupart des serveurs dans nos données se sont terminés sur Shell ZIP ou PHP ZIP. (Nous n’avons pas de ventilation par type d’hôte, donc cela couvre tous les serveurs, pas seulement les mutualisés.) DupArchive est le bon choix sur les hôtes les plus contraints.
• « Réduire la taille de vos blocs. » Presque toutes les configurations réussies utilisaient la taille de bloc de 128 Mo. Des blocs plus petits n’apparaissaient que sur un petit groupe de serveurs, et presque toujours aux côtés de DupArchive.

Chaque correction a fonctionné pour quelqu’un. Sur votre serveur, c’est une supposition. Utilisez AutoTune pour trouver la meilleure configuration pour votre site.

Combien de fois AutoTune a-t-il eu besoin de plus d'une tentative ?

Environ 9 sessions réussies sur 10 ont trouvé une configuration fonctionnelle du premier coup.

Les 1 sur 10 autres ont eu besoin d’au moins une solution de repli avant qu’une sauvegarde ne se termine. Moins de 1 sur 100 ont eu besoin de quatre ou cinq tentatives.

Que se passe-t-il lorsqu'aucun paramètre de sauvegarde ne fonctionne ?

Dans moins de 1 session de réglage sur 20, AutoTune a testé et n’a pas pu trouver de configuration qui s’est terminée sur ce serveur.

Voici ce qui a arrêté le plus de sessions, et les corrections pour chacune.

Le délai d’exécution du serveur a expiré

C’était l’une des raisons les plus courantes pour lesquelles aucun réglage ne pouvait se terminer.

Les hôtes limitent la durée pendant laquelle un seul processus PHP peut s’exécuter. Si la sauvegarde ne peut pas diviser son travail en étapes suffisamment petites pour respecter cette limite, l’hôte l’arrête à mi-chemin, quelles que soient les configurations.

La correction dépend de votre hôte. Demandez-leur d’augmenter la limite d’exécution PHP (max_execution_time), ou de passer à un plan qui ne la limite pas aussi strictement.

L’Aperçu du serveur d’AutoTune affiche la limite de temps PHP de votre serveur, vous pouvez donc la citer dans votre ticket de support.

Le disque s'est rempli

Un disque plein a arrêté certaines sessions avant qu’elles ne puissent se terminer. Nous comptons celles-ci séparément, car aucun réglage de sauvegarde ne corrige un serveur qui manque d’espace.

La solution est le ménage. Supprimez les anciennes sauvegardes dont vous n’avez plus besoin, définissez une limite de rétention pour qu’elles ne s’accumulent pas à nouveau, et gardez des copies hors site au lieu de les conserver sur le même serveur.

Les anciennes sauvegardes qui remplissent silencieusement un serveur est l’un des schémas que nous avons également trouvés dans les tickets de support de Duplicator, que j’aborde dans Ce qui casse les sauvegardes WordPress.

La construction a stagné dans le navigateur

Environ 1 des sessions qui n’ont trouvé aucune configuration fonctionnelle sur 5 s’exécutaient via le navigateur plutôt qu’en arrière-plan.

Cela se produit lorsqu’un hôte empêche un site de s’appeler lui-même (une « requête en boucle »). Duplicator se rabat sur la conduite de la sauvegarde depuis votre navigateur, ce qui signifie qu’elle ne progresse que lorsqu’une page est ouverte. Fermez l’onglet, ou laissez la session expirer, et la construction stagne.

La correction est une question rapide à votre hôte : demandez si les requêtes en boucle sont bloquées, et s’ils peuvent les autoriser pour votre site.

Que faire avec vos propres paramètres de sauvegarde ?

Vous n’avez pas besoin de mémoriser ces données. Utilisez-les comme une raison de tester votre propre environnement.

Voici ce que je ferais ensuite :

• Mettre à jour Duplicator. AutoTune est disponible dans la version 5.0 et plus récentes, en Lite et Pro.
• Exécuter AutoTune. Laissez-le tester les configurations que votre serveur prend en charge.
• Créer une sauvegarde normale par la suite. Les tests de réglage ne sont pas des sauvegardes restaurables.
• Vérifier la récupération. Confirmez que la sauvegarde normale se termine, puis testez une restauration dans un environnement de staging ou de test (pas sur votre site en direct).
• Examiner le stockage et la rétention. Conservez suffisamment d'espace de travail local et une copie de récupération hors site.
• Configurer l'automatisation. Dans Duplicator Pro, définissez un calendrier de sauvegarde et votre destination de stockage choisie.

Apportez le rapport AutoTune à votre hébergeur si rien ne fonctionne. L'aperçu du serveur Server Overview liste les limites PHP de votre serveur, ce qui transforme une plainte vague en une demande spécifique.

Questions fréquemment posées (FAQ)

Avant votre prochaine sauvegarde, laissez votre serveur choisir les paramètres

Une sauvegarde qui s'arrête à mi-chemin ne vous laisse rien à restaurer, et vous pourriez ne le découvrir que lorsque vous en aurez besoin.

AutoTune vous aide à trouver une configuration qui se termine sur votre serveur sans avoir à parcourir chaque paramètre manuellement. Mais le réglage n'est qu'une partie de la planification de la récupération.

Ensuite, créez une sauvegarde, vérifiez une restauration, et configurez un calendrier, une politique de rétention et une destination hors site.

AutoTune est dans Duplicator 5.0, dans les versions gratuite et premium. Mettez à jour votre plugin dès aujourd'hui.

Duplicator Pro maintient cette configuration de travail en cours d'exécution selon un calendrier et envoie automatiquement des copies hors site. Plus de 1,5 million de professionnels WordPress utilisent Duplicator pour maintenir leurs sites récupérables.

Si cet article vous a fait réfléchir à vos paramètres de sauvegarde, ces guides méritent d'être lus ensuite :

• Ce qui casse les sauvegardes WordPress : leçons tirées de plus de 1 400 tickets de support
• Ce que plus de 8 000 tickets de support WordPress révèlent sur les raisons pour lesquelles les migrations échouent
• Comment réparer une sauvegarde WordPress échouée : paramètres vs limites du serveur
• Comment les sauvegardes WordPress affectent les performances du site (et comment y remédier)
• Comment sauvegarder un grand site WordPress