Comment les sauvegardes WordPress affectent les performances du site (et comment y remédier)

L'année dernière, j'ai cherché à identifier la cause du ralentissement d'un site, mais je n'ai rien trouvé de flagrant. Pas de nouveaux plugins, pas de pic de trafic, rien de particulier dans les journaux d'erreurs.

J'ai ensuite vérifié le calendrier des sauvegardes. Il était configuré pour s'exécuter tous les jours à midi, sur un compte d'hébergement mutualisé. C'était tout.

La plupart des utilisateurs de WordPress installent un plugin de sauvegarde, définissent un calendrier, puis ne s'en occupent plus jamais. C'est le genre de tâche dont on a l'impression qu'elle est réglée dès que le plugin est activé.

Mais les paramètres par défaut de la plupart des plugins de sauvegarde ne sont pas optimisés pour les performances. Ils sont optimisés pour la simplicité.

Effectuer une sauvegarde complète quotidienne stockée sur Dropbox semble être une bonne idée. Sur un petit site bénéficiant d'un hébergement performant, c'est effectivement le cas. Sur un site plus important ou avec un hébergement mutualisé à petit budget, cela entraîne une perte de performances récurrente qui pourrait même vous empêcher de vous connecter aux sauvegardes.

Dans cet article, je vais vous expliquer ce qui se passe lors d'une sauvegarde, pourquoi certaines configurations sollicitent davantage le serveur que d'autres, et quelles modifications spécifiques permettent de réduire cet impact à presque zéro.

En voici les principaux enseignements :

• Les sauvegardes sont très gourmandes en ressources: la compression des fichiers, l'exportation des bases de données et le téléchargement vers le cloud mobilisent simultanément d'importantes ressources en termes de CPU, d'E/S disque et de bande passante.
• Les limitations de l'hébergement mutualisé peuvent entraîner des échecs silencieux: les délais d'expiration PHP cachés et les quotas CPU/E/S sur les hébergeurs bon marché interrompent souvent les sauvegardes de longue durée en cours d'exécution, ce qui vous laisse avec des fichiers corrompus ou incomplets.
• Le format de sauvegarde a son importance: les archives ZIP standard s'exécutent en un seul passage continu, ce qui les rend très vulnérables aux délais d'attente du serveur. Les formats par blocs, comme le format DupArchive personnalisé de Duplicator, contournent totalement ces contraintes.
• L'optimisation est simple: vous pouvez pratiquement éliminer toute perte de performances en effectuant les sauvegardes pendant les heures creuses, en excluant les fichiers de cache, en utilisant le cron du serveur et en planifiant des sauvegardes de la base de données plus fréquemment que des sauvegardes complètes du site.

Table des matières

Que se passe-t-il sur votre serveur lorsqu'une sauvegarde est en cours d'exécution ?

Une sauvegarde ne consiste pas simplement à copier vos fichiers vers un autre emplacement. Il s'agit d'un processus en plusieurs étapes qui s'exécute entièrement sur votre serveur, entrant ainsi en concurrence avec les ressources qui permettent à votre site d'être accessible aux visiteurs.

Pendant la sauvegarde, votre serveur effectue deux tâches simultanément. Dans le cadre d'un hébergement mutualisé, où ces ressources sont déjà réparties entre des dizaines d'autres sites, cela a son importance.

Compression de fichiers et charge du processeur

Lors d'une sauvegarde, chaque fichier de votre installation WordPress est lu et compressé dans une archive. Ce processus sollicite fortement le processeur.

Avec l'hébergement mutualisé, votre compte dispose d'une part limitée de la puissance de traitement du serveur, et une sauvegarde comprenant des centaines de mégaoctets de fichiers va en grignoter une partie.

Les sites plus volumineux aggravent encore la situation. Un nombre plus important de fichiers implique une durée de compression plus longue, ce qui signifie que votre processeur est sollicité plus longtemps.

Un petit blog contenant peu de fichiers multimédias peut se compresser en moins d'une minute. Un site sur lequel des images ont été téléchargées pendant des années peut prendre beaucoup plus de temps.

Vous voulez réduire de moitié la taille de votre bibliothèque multimédia en un clin d'œil ? Supprimez les variantes d'images inutilisées avec WP Media Cleanup!

Exportation de bases de données et verrouillage des tables

L'exportation de la base de données est souvent le coupable caché. La plupart des utilisateurs pensent à leurs fichiers lorsqu'ils envisagent une sauvegarde, mais WordPress stocke vos articles, vos paramètres, vos utilisateurs et tout le reste dans une base de données MySQL, ce qui nécessite un processus d'exportation distinct.

La plupart des plugins de sauvegarde exportent la base de données en utilisant une méthode qui verrouille temporairement les tables qu'ils consultent. Tant que ces tables sont verrouillées, les requêtes WordPress entrantes doivent patienter.

Même quelques secondes de blocage d'une table peuvent entraîner des délais d'expiration sur un serveur lent ou surchargé.

Les E/S disque : le goulot d'étranglement que la plupart des gens ignorent

La lecture de milliers de fichiers lors d'une sauvegarde génère une activité disque importante. L'espace de stockage de votre serveur a une capacité limitée en termes d'opérations de lecture et d'écriture par seconde, et une sauvegarde portant sur l'ensemble de votre installation WordPress atteint cette limite.

Les hébergements économiques et mutualisés utilisent encore souvent des disques durs traditionnels plutôt que des SSD. Sur ces serveurs, une activité disque intense pendant une sauvegarde ralentit toutes les opérations liées au stockage, y compris les requêtes de base de données et les lectures de fichiers qui génèrent vos pages.

Téléchargement vers le cloud et bande passante

L'impact sur les performances ne s'arrête pas une fois l'archivage terminé. La plupart des solutions de sauvegarde transfèrent ensuite cette archive vers un espace de stockage dans le cloud : Dropbox, Google Drive ou S3. Ce transfert s'effectue via la même connexion serveur que celle utilisée pour servir vos visiteurs.

Le téléchargement d'une sauvegarde de 2 Go vers Dropbox, à la vitesse de téléchargement habituelle d'un hébergement mutualisé, prend plusieurs minutes. Pendant ce laps de temps, votre bande passante disponible peut être sollicitée par d'autres utilisateurs.

Pourquoi les performances des sauvegardes sont-elles moins bonnes chez les hébergeurs bon marché ?

Les hébergements économiques et mutualisés imposent des limites au niveau du serveur dont la plupart des utilisateurs ne trouvent aucune trace dans la documentation.

Il ne s'agit ni de bugs ni d'erreurs de configuration. Ce sont des limites imposées délibérément afin d'empêcher un compte de consommer des ressources qui pourraient affecter tous les autres sites hébergés sur le même serveur.

Le problème, c'est que ces mêmes limites entravent les processus de sauvegarde, et que les dysfonctionnements qu'elles provoquent ne sont pas toujours évidents.

Délais d'expiration PHP

PHP dispose d'un paramètre de durée d'exécution maximale. Sur les hébergements mutualisés bon marché, celle-ci est souvent fixée entre 30 et 60 secondes. Le processus de sauvegarde d'un site de grande envergure peut prendre bien plus de temps, et lorsqu'il atteint cette limite, l'hébergeur interrompt le processus en cours d'exécution.

Il en résulte un fichier d'archive incomplet. Il semblerait qu'une sauvegarde existe. Le fichier est bien présent, mais il a été interrompu avant d'être terminé, ce qui signifie qu'il est impossible de le restaurer.

Le site a subi toutes les répercussions d'une sauvegarde en cours d'exécution sans en tirer aucun résultat fiable. Un fichier de sauvegarde corrompu est pire que l'absence totale de sauvegarde, car il donne le faux sentiment d'être protégé alors que ce n'est pas le cas.

Quotas CPU et E/S

La plupart des hébergeurs mutualisés limitent l'utilisation du processeur par compte. Une fois cette limite atteinte, l'hébergeur n'interrompt pas purement et simplement vos processus. Il les ralentit. Tout ce qui s'exécute sous votre compte ralentit, y compris les requêtes de pages émanant des visiteurs.

Les limites d'E/S fonctionnent de la même manière. Votre compte est soumis à un plafond d'opérations de lecture et d'écriture par seconde. Une sauvegarde visant à compresser une vaste bibliothèque multimédia atteindra souvent ce plafond.

C'est pourquoi certaines sauvegardes aboutissent à 3 heures du matin mais échouent à midi, alors que les paramètres sont identiques. Les heures creuses se traduisent par une charge de base moindre sur le serveur, ce qui laisse une plus grande marge avant que le quota ne soit atteint.

Le format des fichiers de sauvegarde a-t-il de l'importance ?

La plupart des plugins de sauvegarde utilisent par défaut des archives ZIP. Ce n'est pas un mauvais choix pour un petit site hébergé sur un serveur disposant de ressources suffisantes. Cependant, le format ZIP traite les fichiers de manière séquentielle, un par un, en un seul passage ininterrompu.

Dans un environnement d'hébergement mutualisé aux ressources limitées, c'est précisément ce type d'exécution ininterrompue que les délais d'expiration PHP sont censés interrompre.

Le format d'archivage utilisé par votre plugin de sauvegarde détermine la charge qu'il impose au serveur et sa capacité à s'adapter aux contraintes d'un hébergement économique. Cet aspect est rarement abordé dans les discussions sur les performances de sauvegarde, alors qu'il fait souvent la différence entre une sauvegarde qui s'effectue de manière fiable et une autre qui échoue sans le signaler.

Comment DupArchive gère les contraintes liées au serveur

Duplicator est un plugin WordPress de sauvegarde qui utilise son propre format de sauvegarde, appelé DupArchive. Il a été spécialement conçu pour les sauvegardes et les migrations WordPress, en tenant compte dès le départ des contraintes liées aux hébergements économiques.

Alors qu'un processus ZIP standard s'exécute en une seule opération continue, DupArchive fonctionne par petits blocs. Chaque bloc est traité dans les limites de temps d'exécution du serveur, puis le processus reprend là où il s'était arrêté.

Les délais d'expiration PHP qui interrompraient une sauvegarde au format ZIP en cours d'exécution n'ont pas le même effet, car chaque bloc est suffisamment court pour être traité avant que la limite ne soit atteinte.

Il prend également en charge les sites plus volumineux sans la limite de taille de fichier qui provoque des échecs avec ZIP. Des migrations réelles réalisées avec DupArchive ont été menées à bien pour des volumes dépassant les 400 Go!

Pour la plupart des utilisateurs d'hébergement mutualisé, cette marge de manœuvre signifie que le format fonctionne tout simplement là où une approche basée sur le format ZIP entraînerait un délai d'expiration ou une corruption des données.

Consultez ici la liste complète des paramètres permettant d'accélérer une sauvegarde lente.

Shell Zip ou ZipArchive

Duplicator vous permet de choisir votre moteur d'archivage de sauvegarde.

Shell Zip confie la compression au système d'exploitation plutôt que de l'exécuter via PHP. Cette méthode est nettement plus rapide lorsqu'elle est disponible, car le système d'exploitation gère la compression de manière plus directe qu'un processus PHP.

Les hébergeurs Budget désactivent parfois Shell Zip. Si c'est le cas chez vous, vous pouvez leur demander de l'activer ou considérer cela comme un signe que le traitement par blocs de DupArchive, proposé par Duplicator, constitue la solution de secours appropriée.

Ces deux options couvrent à elles deux la plupart des environnements d'hébergement : Shell Zip pour la rapidité lorsque l'hébergeur le permet, et DupArchive pour la fiabilité lorsque ce n'est pas le cas.

Comment effectuer des sauvegardes sans ralentir votre site

L'objectif est de rendre les sauvegardes invisibles pour vos visiteurs. Elles s'exécutent, s'achèvent et sont téléchargées sans que personne ne remarque de différence dans la vitesse du site.

C'est possible sur la plupart des configurations en modifiant quelques paramètres. Aucune de ces modifications ne nécessite de changer d'hébergeur ni de faire appel à un développeur.

Les méthodes les plus efficaces pour effectuer des sauvegardes sans ralentir votre site :

• Planifiez vos sauvegardes aux heures de faible affluence: le timing est essentiel. En identifiant les heures les moins chargées de votre site, vous vous assurez que les sauvegardes ne se disputent pas les ressources du serveur avec les visiteurs réels.
• Exclure les fichiers qui n'ont pas besoin d'être sauvegardés: la suppression des répertoires de cache, des fichiers journaux et des fichiers temporaires réduit considérablement la taille de la sauvegarde, ce qui permet d'économiser de la puissance CPU et de réduire les opérations d'E/S disque.
• Effectuez des sauvegardes de base de données plus fréquemment que des sauvegardes complètes: comme votre base de données évolue constamment, contrairement à vos fichiers, le fait d'effectuer quotidiennement des sauvegardes rapides de la base de données vous permet de limiter les sauvegardes complètes du site, plus lourdes, à une seule fois par semaine.
• Utilisez le cron du serveur plutôt que WP-Cron: en passant de la planification de WordPress, qui dépend du trafic, à une tâche cron dédiée sur le serveur, vous vous assurez que les sauvegardes s'exécutent exactement au moment prévu.

Planifiez vos sauvegardes aux heures de faible affluence

L'optimisation de la planification est la mesure la plus efficace qui soit, quel que soit votre niveau d'hébergement. Une sauvegarde effectuée à 3 heures du matin sur un serveur peu sollicité bénéficie d'une marge de manœuvre bien plus importante que la même sauvegarde effectuée à midi, qui doit alors composer avec le trafic réel des visiteurs.

En règle générale, il est recommandé de publier entre 2 h et 5 h du matin, heure locale. Cela vaut pour la plupart des sites, mais il est préférable de vérifier vos propres statistiques.

Ouvrez MonsterInsights, examinez le trafic par heure et identifiez votre véritable creux. Certains sites destinés à un public international ne présentent pas de période de faible trafic clairement définie. D'autres enregistrent leur pic de baisse en début de soirée plutôt que pendant la nuit. Organisez-vous en fonction de vos données, et non d'une règle générale.

Évitez de programmer des sauvegardes aux heures de forte affluence. Si vous envoyez une newsletter tous les mardis à 9 h, ne lancez pas de sauvegarde à cette heure-là. C'est justement lors des pics de trafic générés par les campagnes que vous ne voulez pas alourdir la charge du serveur.

Exclure les fichiers qui n'ont pas besoin d'être sauvegardés

Le moyen le plus rapide de réduire la charge liée aux sauvegardes consiste à réduire le volume des données sauvegardées. Les archives plus petites se compressent plus rapidement, se téléchargent plus vite et sollicitent moins les E/S disque tout au long du processus.

Les répertoires de cache constituent le principal avantage. Votre plugin de mise en cache les régénère automatiquement au chargement du site ; il n'y a donc aucun intérêt à les sauvegarder.

Il convient également d'exclure :

• Fichiers journaux
• Dossiers temporaires de téléchargement
• Les fichiers d'archive laissés sur le serveur par d'autres plugins de sauvegarde

Dans Duplicator, utilisez les filtres de fichiers et de bases de données pour exclure les données inutiles. Je vous recommande le filtre « Cache » intégré.

Le rapport d'analyse préalable à la sauvegarde met en évidence les fichiers volumineux avant le lancement de la sauvegarde. Il est utile de le consulter avant de définir une planification récurrente. Quelques minutes consacrées à ce rapport peuvent réduire considérablement la taille de votre sauvegarde.

Effectuez des sauvegardes partielles de la base de données plus fréquemment que des sauvegardes complètes

Votre médiathèque évolue très peu. Votre base de données, en revanche, change constamment.

Chaque nouvelle publication, chaque commentaire, chaque commande et chaque formulaire envoyé est enregistré dans la base de données. C'est précisément ce dont vous devez effectuer des sauvegardes régulières.

Les sauvegardes quotidiennes portant uniquement sur la base de données sont rapides (elles s'effectuent souvent en moins de 30 secondes) et n'imposent qu'une charge minimale au serveur. Réservez les sauvegardes complètes du site (fichiers et base de données) pour des exécutions hebdomadaires aux heures creuses.

Cette approche vous permet de disposer de points de restauration fréquents pour les données les plus importantes, tout en limitant la fréquence du processus fastidieux de sauvegarde complète du site.

Utilisez le Cron du serveur à la place de WP-Cron

WordPress dispose d'un système de planification intégré appelé WP-Cron. Le problème, c'est qu'il ne se déclenche que lorsqu'un utilisateur consulte le site.

Si personne ne se connecte à 3 heures du matin, la sauvegarde ne s'exécute pas. Pire encore, un visiteur à midi pourrait déclencher par inadvertance une sauvegarde différée qui était censée s'exécuter pendant la nuit.

Une tâche cron sur un serveur physique s'exécute selon un calendrier fixe, quel que soit le trafic. La plupart des panneaux de contrôle d'hébergement permettent d'accéder à la configuration des tâches cron.

La configuration d'un cron côté serveur pour votre plugin de sauvegarde ne prend que quelques minutes et élimine complètement les aléas liés à WP-Cron. La documentation de Duplicator explique la procédure de configuration d'un cron côté serveur si vous ne l'avez jamais fait auparavant.

Signes indiquant que vos sauvegardes nuisent aux performances de votre site

Vous ne faites peut-être pas le lien entre les ralentissements de votre site et les sauvegardes, car le lien n'est pas évident. Une sauvegarde qui s'exécute à une heure inhabituelle ne s'annonce pas. Mais il existe des schémas à surveiller si votre site semble lent et que vous n'avez pas réussi à en identifier la cause.

Voici les signes qui indiquent que les sauvegardes ralentissent votre site :

• Les ralentissements du site se produisent à la même heure chaque jour ou chaque semaine, ce qui correspond à votre calendrier de sauvegarde
• Les journaux de sauvegarde indiquent des exécutions ayant échoué, incomplètes ou manquantes
• Votre panneau de contrôle d'hébergement affiche des pics de charge du processeur ou des E/S selon un calendrier prévisible
• Les visiteurs signalent des ralentissements qui ne correspondent pas à vos heures de pointe habituelles

Si deux ou plusieurs de ces éléments correspondent à ce que vous constatez, vérifiez d'abord votre calendrier de sauvegarde avant de vous pencher sur quoi que ce soit d'autre.

Protégez votre site avant d'y apporter la moindre modification

Avant de modifier les plannings de sauvegarde, de changer de format d'archivage ou de modifier les paramètres du serveur, effectuez d'abord une sauvegarde complète.

Cela semble évident, mais on a tendance à l'oublier quand on est en plein dépannage et qu'on a hâte de régler le problème. C'est exactement ce que j'ai fait, et j'ai créé une lacune dans mon historique de sauvegardes juste avant d'apporter des modifications qui n'ont pas donné les résultats escomptés.

Des erreurs de configuration lors de la mise en place de la sauvegarde peuvent vous priver de toute sauvegarde opérationnelle. Le risque de compromettre votre filet de sécurité en essayant d'améliorer votre système de sauvegarde est bien réel.

Si vous souhaitez tester de nouveaux paramètres de planification ou de sauvegarde avant de les appliquer à votre site en production, l'environnement de test vous offre un cadre isolé pour vérifier au préalable que tout fonctionne correctement.

Duplicator Pro vous permet de créer un site de test à partir de n'importe quelle sauvegarde existante en quelques clics. Aucun compte d'hébergement distinct n'est nécessaire.

Une fois que vous avez mis en place l'environnement de test, vous pouvez procéder au dépannage en toute sécurité.

Foire aux questions (FAQ)

Votre site mérite une solution de sauvegarde adaptée à ses besoins

Les sauvegardes sont censées protéger votre site, pas le ralentir. La baisse de performances causée par une sauvegarde mal configurée est bien réelle, mais elle peut presque toujours être corrigée sans avoir à changer d'hébergeur ni à tout reconstruire.

Les trois éléments les plus importants sont le moment où les sauvegardes sont effectuées, ce qu'elles contiennent et le format utilisé. La plupart des sites peuvent réduire l'impact sur les performances à un niveau quasi nul en tenant compte de ces trois aspects.

Votre plugin de sauvegarde doit protéger votre site sans entrer en concurrence avec lui pour les ressources du serveur. Cet équilibre est plus difficile à trouver qu'il n'y paraît, en particulier sur les hébergements mutualisés et économiques, où les contraintes sont bien réelles et ne sont pas toujours documentées.

Plus d'1,5 million de professionnels de WordPress utilisent Duplicator Pro pour gérer leurs sauvegardes, leurs migrations et la reprise après sinistre. Le format DupArchive a été spécialement conçu pour les environnements d'hébergement où les sauvegardes standard au format ZIP échouent le plus souvent : les serveurs aux ressources limitées soumis à des délais d'expiration PHP, des quotas CPU et des limites d'E/S.

Et si vous souhaitez tester des modifications de configuration avant de les appliquer à votre site en production, la fonctionnalité de mise en production en un clic vous permet de créer une copie de votre site à partir de n'importe quelle sauvegarde existante, sans avoir besoin d'un compte d'hébergement distinct.

Si cet article vous a amené à réfléchir aux performances des sauvegardes et à l'état de santé de votre site, nous vous recommandons de lire ensuite ces guides.

• Votre site WordPress perd de l'argent à chaque seconde de lenteur (voici la solution)
• Comment crypter les fichiers de sauvegarde d'un site web pour une sécurité maximale des données ?
• Votre site vient de tomber en panne ? Voici un plan complet de récupération de votre site web
• Politiques de conservation des sauvegardes de sites web : Combien de temps conserver les sauvegardes ?
• Pourquoi votre site WordPress a besoin d'une surveillance des sauvegardes (et pas seulement des sauvegardes)