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

L'année dernière, je dépannais un site lent et je n'ai rien trouvé d'évident. Pas de nouveaux plugins, pas de pic de trafic, rien dans les journaux d'erreurs qui ressortait.

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

La plupart des utilisateurs de WordPress installent un plugin de sauvegarde, choisissent un calendrier et ne le touchent plus jamais. C'est l'une de ces tâches qui semblent terminées une fois le plugin actif.

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

Une sauvegarde complète quotidienne stockée sur Dropbox semble responsable. Sur un petit site avec un hébergement généreux, ça l'est. Sur un site plus grand ou un hébergement mutualisé économique, c'est un ralentissement récurrent de la performance auquel vous ne penserez peut-être même pas lié aux sauvegardes.

Dans cet article, je vais vous montrer ce qui se passe lorsqu'une sauvegarde s'exécute, pourquoi certaines configurations sollicitent le serveur plus que d'autres, et les changements spécifiques qui réduisent l'impact à presque zéro.

Voici les points clés à retenir :

• Les sauvegardes consomment beaucoup de ressources : La compression des fichiers, l'exportation des bases de données et le téléchargement vers le cloud consomment simultanément une quantité importante de CPU, d'E/S disque et de bande passante.
• Les limites de l'hébergement mutualisé peuvent entraîner des échecs silencieux : Les timeouts PHP cachés et les quotas de CPU/E/S sur les hébergements économiques tuent souvent les sauvegardes de longue durée en cours de processus, vous laissant avec des fichiers corrompus ou incomplets.
• Le format de sauvegarde est important : Les archives ZIP standard s'exécutent en une seule passe continue, ce qui les rend très vulnérables aux timeouts du serveur. Les formats segmentés comme le DupArchive personnalisé de Duplicator contournent entièrement ces contraintes.
• L'optimisation est facile : Vous pouvez presque éliminer l'impact sur les performances en exécutant les sauvegardes pendant les heures creuses, en excluant les fichiers de cache, en utilisant le cron du serveur et en planifiant des sauvegardes de base de données uniquement plus fréquemment que les sauvegardes complètes du site.

Table des matières

Que se passe-t-il sur votre serveur lorsqu'une sauvegarde s'exécute ?

Une sauvegarde n'est pas juste une copie de vos fichiers vers un autre emplacement. C'est un processus en plusieurs étapes qui s'exécute entièrement sur votre serveur, en concurrence pour les mêmes ressources qui servent votre site aux visiteurs.

Pendant que la sauvegarde s'exécute, votre serveur effectue deux tâches à la fois. Sur un hébergement mutualisé, où ces ressources sont déjà partagées entre des dizaines d'autres sites, cela a de l'importance.

Compression de fichiers et charge CPU

Chaque fichier de votre installation WordPress est lu et compressé dans une archive lors d'une sauvegarde. Ce processus est gourmand en CPU.

Sur un hébergement mutualisé, votre compte dispose d'une part limitée de la puissance de traitement du serveur, et une sauvegarde compressant des centaines de mégaoctets de fichiers va la consommer.

Les sites plus grands aggravent ce problème. Plus de fichiers signifient une fenêtre de compression plus longue, ce qui signifie plus de temps pendant lequel votre CPU est sous pression.

Un petit blog avec un minimum de médias peut se compresser en moins d'une minute. Un site avec des années d'images téléchargées peut prendre beaucoup plus de temps.

Vous voulez réduire instantanément la taille de votre médiathèque de moitié ? Supprimez les variations d'images inutilisées avec WP Media Cleanup !

Exportation de base de données et verrouillage de table

L'exportation de la base de données est souvent le coupable caché. La plupart des utilisateurs pensent à leurs fichiers lorsqu'ils imaginent une sauvegarde, mais WordPress stocke vos articles, paramètres, 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'elle lit. Pendant que ces tables sont verrouillées, les requêtes WordPress entrantes doivent attendre.

Même quelques secondes de verrouillage de table peuvent provoquer des erreurs d'expiration sur un serveur lent ou occupé.

E/S disque : Le goulot d'étranglement que la plupart ignorent

La lecture de milliers de fichiers pour une sauvegarde crée une activité disque substantielle. Le stockage de votre serveur a une limite quant au nombre d'opérations de lecture et d'écriture qu'il peut gérer par seconde, et une sauvegarde exécutant l'ensemble de votre installation WordPress atteint cette limite.

Les hébergements économiques et partagés utilisent souvent encore des disques durs traditionnels plutôt que des SSD. Sur ces serveurs, une activité disque élevée pendant une sauvegarde ralentit tout ce qui touche 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'archive terminée. La plupart des configurations de sauvegarde téléchargent ensuite cette archive vers un stockage cloud : Dropbox, Google Drive ou S3. Ce téléchargement s'exécute sur la même connexion serveur qui dessert vos visiteurs.

Une sauvegarde de 2 Go téléversée sur Dropbox à une vitesse de téléversement typique d'un hébergement partagé prend plusieurs minutes. Pendant cette période, votre bande passante disponible peut être sollicitée.

Pourquoi les performances de sauvegarde sur les hébergements économiques sont-elles moins bonnes ?

Les hébergements économiques et partagés imposent des limites au niveau du serveur que la plupart des utilisateurs ne voient jamais documentées.

Ce ne sont pas des bugs ou des mauvaises configurations. Ce sont des plafonds intentionnels qui empêchent un compte de consommer des ressources qui affectent tous les autres sites sur le même serveur.

Le problème est que ces mêmes plafonds interfèrent avec les processus de sauvegarde, et les échecs qu'ils provoquent ne sont pas toujours évidents.

Erreurs d'expiration PHP

PHP a un paramètre de temps d'exécution maximum. Sur les hébergements partagés économiques, il est souvent réglé entre 30 et 60 secondes. Un processus de sauvegarde sur un site plus grand peut prendre beaucoup plus de temps, et lorsqu'il atteint la limite, l'hébergeur tue le processus en cours d'exécution.

Le résultat est un fichier d'archive incomplet. Il semble qu'une sauvegarde existe. Le fichier est là, mais il a été interrompu avant d'être terminé, ce qui signifie qu'il ne peut pas être restauré.

Le site a subi l'intégralité de l'impact de performance d'une sauvegarde en cours et n'en a rien obtenu de fiable. Un fichier de sauvegarde corrompu est pire qu'aucune sauvegarde car il crée une fausse confiance que vous êtes protégé alors que vous ne l'êtes pas.

Quotas CPU et I/O

La plupart des hébergements partagés limitent l'utilisation du CPU par compte. Une fois le plafond atteint, l'hébergeur n'arrête pas vos processus immédiatement. Il les ralentit. Tout ce qui s'exécute sous votre compte ralentit, y compris les requêtes de page entrantes des visiteurs.

Les limites d'E/S fonctionnent de la même manière. Votre compte obtient un plafond pour les opérations de lecture et d'écriture par seconde. Une sauvegarde compressant une grande bibliothèque multimédia atteindra fréquemment ce plafond.

C'est pourquoi certaines sauvegardes réussissent à 3 heures du matin mais échouent à midi avec des paramètres identiques. Les heures creuses signifient une charge de serveur de base plus faible, ce qui signifie plus de marge avant que le quota ne s'applique.

Le format de fichier de sauvegarde est-il important ?

La plupart des plugins de sauvegarde utilisent par défaut des archives ZIP. Ce n'est pas un mauvais choix pour un petit site sur un serveur bien approvisionné. Mais ZIP traite les fichiers séquentiellement, un par un, en une seule passe ininterrompue.

Dans un environnement d'hébergement partagé limité, cette passe unique et ininterrompue est exactement ce que les timeouts PHP sont conçus pour tuer.

Le format d'archive utilisé par votre plugin de sauvegarde détermine la pression qu'il exerce sur le serveur et s'il peut survivre aux contraintes de l'hébergement économique. Cela n'apparaît presque jamais dans les conversations sur les performances de sauvegarde, et c'est souvent la différence entre une sauvegarde qui se termine de manière fiable et une qui échoue silencieusement.

Comment DupArchive gère les contraintes du serveur

Duplicator est un plugin de sauvegarde WordPress avec son propre format de sauvegarde appelé DupArchive. Il a été spécialement conçu pour les sauvegardes et les migrations WordPress, en tenant compte des contraintes de l'hébergement économique comme considération de conception principale.

Là où un processus ZIP standard s'exécute comme une opération continue, DupArchive fonctionne par petits morceaux. Chaque morceau se termine dans les limites de temps d'exécution du serveur, puis le processus reprend là où il s'était arrêté.

Les timeouts PHP qui tueraient une sauvegarde basée sur ZIP en cours d'exécution n'ont pas le même effet, car chaque morceau est suffisamment court pour se terminer avant que la limite ne se déclenche.

Il gère également les sites plus volumineux sans le plafond de taille de fichier qui provoque des échecs ZIP. Des migrations réelles utilisant DupArchive se sont terminées à plus de 400 Go !

Pour la plupart des utilisateurs d'hébergement partagé, cette marge signifie que le format fonctionne simplement là où une approche basée sur ZIP expirerait ou corromprait.

Obtenez la liste complète des paramètres qui accélèrent une sauvegarde lente ici.

Shell Zip vs. ZipArchive

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

Shell Zip délègue la compression au système d'exploitation plutôt que de l'exécuter via PHP. Il est beaucoup plus rapide lorsqu'il est disponible car le système d'exploitation gère la compression plus directement qu'un processus PHP ne le peut.

Les hébergeurs économiques désactivent parfois Shell Zip. Si le vôtre le fait, vous pouvez leur demander de l'activer ou le considérer comme un signal que le traitement par morceaux de DupArchive de Duplicator est le bon recours.

Ces deux options couvrent la plupart des environnements d'hébergement : Shell Zip pour la vitesse lorsque l'hôte le permet et DupArchive pour la fiabilité lorsqu'il ne le permet pas.

Comment exécuter des sauvegardes sans ralentir votre site

L'objectif est de rendre les sauvegardes invisibles pour vos visiteurs. Elles s'exécutent, se terminent et se téléchargent sans que personne ne remarque de différence de vitesse sur le site.

C'est réalisable sur la plupart des configurations avec une poignée de changements de paramètres. Aucun d'entre eux ne nécessite de changer d'hébergeur ou d'engager un développeur.

Les moyens les plus efficaces de sauvegarder sans ralentir votre site :

• Planifiez les sauvegardes pendant les heures creuses : Le timing est essentiel. Identifier les heures les plus calmes de votre site garantit que les sauvegardes ne rivalisent pas avec les visiteurs réels pour les ressources du serveur.
• Excluez les fichiers qui n’ont pas besoin d’être sauvegardés : La suppression des répertoires de cache, des journaux et des fichiers temporaires réduit considérablement la taille de la sauvegarde, économisant ainsi la puissance du processeur et les opérations d’entrée/sortie disque.
• Exécutez les sauvegardes de base de données plus souvent que les sauvegardes complètes : Étant donné que votre base de données change constamment, mais que vos fichiers ne changent pas, l’exécution de sauvegardes rapides quotidiennes de la base de données vous permet de réduire les sauvegardes complètes du site à une seule fois par semaine.
• Utilisez Cron du serveur au lieu de WP-Cron : Passer de la planification de WordPress dépendant du trafic à une tâche cron dédiée du serveur garantit que les sauvegardes s’exécutent exactement quand elles sont censées le faire.

Planifier les sauvegardes pendant les heures de faible trafic

Le timing est la correction à plus fort effet de levier disponible, quel que soit votre niveau d’hébergement. Une sauvegarde exécutée à 3 heures du matin sur un serveur calme a beaucoup plus de marge de manœuvre que la même sauvegarde exécutée à midi, en concurrence avec le trafic réel des visiteurs.

La recommandation standard est de 2 à 5 heures du matin, heure locale. Cela vaut pour la plupart des sites, mais il est utile de vérifier vos analyses réelles.

Ouvrez MonsterInsights, examinez le trafic par heure et trouvez votre véritable creux. Certains sites desservant des audiences internationales n’ont pas de fenêtre claire de faible trafic. D’autres voient leur point le plus bas en début de soirée plutôt que pendant la nuit. Planifiez en fonction de vos données, pas d’une règle générique.

Ne planifiez pas les sauvegardes pendant les moments de forte affluence. Si vous envoyez une newsletter le mardi à 9 heures du matin, n’exécutez pas de sauvegarde le mardi à 9 heures du matin. Les pics de trafic dus aux campagnes sont précisément le moment où vous ne voulez pas de charge supplémentaire sur le serveur.

Excluez les fichiers qui n’ont pas besoin d’être sauvegardés

Le moyen le plus rapide de réduire la charge de sauvegarde est de réduire ce qui est sauvegardé. Les archives plus petites se compressent plus rapidement, se téléchargent plus rapidement et exercent moins de pression sur les opérations d’entrée/sortie disque tout au long du processus.

Les répertoires de cache sont le plus grand avantage. Votre plugin de cache les régénère automatiquement lorsque le site se charge, il n’y a donc aucune valeur de récupération à les sauvegarder.

Il est également utile d’exclure :

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

Dans Duplicator, utilisez les filtres de fichiers et de base de données pour exclure les données inutiles. Je recommanderais le filtre intégré Cache.

Le rapport d’analyse avant la sauvegarde met en évidence les fichiers volumineux avant l’exécution de la construction. Il vaut la peine de l’examiner avant de définir un calendrier récurrent. Quelques minutes avec ce rapport peuvent réduire considérablement la taille de votre sauvegarde.

Exécuter les sauvegardes de base de données plus souvent que les sauvegardes complètes

Votre médiathèque change à peine. Votre base de données change constamment.

Chaque nouvel article, commentaire, commande et soumission de formulaire va dans la base de données. C’est ce que vous devez réellement sauvegarder fréquemment.

Les sauvegardes quotidiennes de la base de données seule sont rapides, s’achevant souvent en moins de 30 secondes, et exercent une charge minimale sur le serveur. Réservez les sauvegardes complètes du site (fichiers plus base de données) pour des exécutions hebdomadaires pendant les heures creuses.

Cette approche vous donne des points de récupération fréquents pour les données les plus importantes tout en maintenant le processus complet du site peu fréquent.

Utiliser le cron du serveur au lieu de WP-Cron

WordPress dispose d'un système de planification intégré appelé WP-Cron. Le hic, c'est qu'il ne s'active que lorsque quelqu'un visite le site.

Si personne ne visite à 3 heures du matin, la sauvegarde ne s'exécute pas. Pire encore, un visiteur à midi pourrait déclencher involontairement une sauvegarde retardée qui était censée s'exécuter pendant la nuit.

Une vraie tâche cron côté serveur s'exécute selon un calendrier fixe, indépendamment du trafic. La plupart des panneaux de contrôle d'hébergement donnent accès à la configuration cron.

La mise en place pour votre plugin de sauvegarde prend quelques minutes et élimine entièrement l'imprévisibilité de WP-Cron. La documentation de Duplicator couvre le processus de configuration de cron côté serveur si vous ne l'avez jamais fait auparavant.

Signes que vos sauvegardes affectent les performances du site

Vous ne connecterez peut-être pas les ralentissements du site aux sauvegardes car le moment n'est pas évident. Une sauvegarde qui s'exécute à une heure inhabituelle ne s'annonce pas. Mais il existe des schémas à rechercher si votre site vous a semblé lent et que vous n'avez pas pu en identifier la cause.

Ce sont les signaux qui indiquent que les sauvegardes ralentissent votre site :

• Les ralentissements du site augmentent à la même heure chaque jour ou chaque semaine, correspondant à votre calendrier de sauvegarde
• Les journaux de sauvegarde montrent des exécutions échouées, incomplètes ou manquantes
• Votre panneau de contrôle d'hébergement montre des pics de CPU ou d'E/S selon un calendrier prévisible
• Les visiteurs signalent une lenteur qui ne correspond pas à vos heures de pointe normales

Si deux de ces éléments correspondent à ce que vous observez, vérifiez d'abord votre calendrier de sauvegarde avant de vous pencher sur autre chose.

Protégez votre site avant de changer quoi que ce soit

Avant d'ajuster les calendriers de sauvegarde, de changer les formats d'archive ou de modifier les paramètres du serveur : effectuez d'abord une sauvegarde complète.

Cela semble évident, mais il est facile de l'oublier lorsque vous êtes en plein dépannage et impatient de résoudre un problème. Je l'ai fait exactement et j'ai créé une lacune dans mon historique de sauvegarde juste avant d'apporter des modifications qui ne se sont pas déroulées comme prévu.

Les erreurs de configuration lors de la mise en place de la sauvegarde peuvent vous laisser sans aucune sauvegarde fonctionnelle. L'ironie de casser votre filet de sécurité de sauvegarde tout en essayant d'améliorer votre configuration de sauvegarde est bien réelle.

Si vous souhaitez tester de nouveaux paramètres de planification ou de fichiers de sauvegarde avant de les appliquer à votre site en production, la pré-production vous offre un environnement isolé pour confirmer que tout fonctionne d'abord.

Duplicator Pro vous permet de créer un site de pré-production à partir de n'importe quelle sauvegarde existante en quelques clics. Aucun compte d'hébergement séparé requis.

Une fois que vous avez créé la zone de pré-production, vous êtes libre de dépanner sans risque.

Questions fréquemment posées (FAQ)

Votre site mérite une sauvegarde qui fonctionne avec lui

Les sauvegardes sont censées protéger votre site, pas le taxer. L'impact sur les performances d'une sauvegarde mal configurée est réel, mais il est presque toujours réparable sans changer d'hébergeur ni reconstruire quoi que ce soit.

Les trois leviers qui comptent le plus sont le moment où les sauvegardes s'exécutent, ce qu'elles incluent et le format qu'elles utilisent. La plupart des sites peuvent atteindre un impact quasi nul sur les performances en abordant ces trois points.

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

Plus d'1,5 million de professionnels WordPress utilisent Duplicator Pro pour gérer les sauvegardes, les migrations et la reprise après sinistre. Le format DupArchive a été conçu spécifiquement pour les environnements d'hébergement où les sauvegardes standard basées sur ZIP échouent le plus souvent : serveurs contraints avec des délais d'attente 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 direct, la mise en scène en un clic vous permet de lancer une copie de votre site à partir de toute sauvegarde existante sans avoir besoin d'un compte d'hébergement séparé.

Si cet article vous a fait réfléchir aux performances de sauvegarde et à la santé de votre site, ces guides méritent d'être lus ensuite.

• Votre site WordPress perd de l'argent à chaque seconde où il est lent (Voici la solution)
• Comment chiffrer les fichiers de sauvegarde de site Web pour une sécurité maximale des données
• Le site vient de planter ? Voici votre plan complet de récupération de site web
• Politiques de rétention des sauvegardes de sites web : combien de temps conserver les sauvegardes ?
• Pourquoi votre site WordPress a besoin d'une surveillance des sauvegardes (pas seulement de sauvegardes)