Vitesse de sauvegarde du site Web : pourquoi vos sauvegardes sont lentes et comment les corriger

Votre sauvegarde s'exécute depuis 45 minutes. Rien n'est cassé, mais une barre de progression continue de bouger.

Ou peut-être que votre site ralentit considérablement tous les soirs à 3 heures du matin, et vous n'arrivez pas à comprendre pourquoi. Vous vérifiez les paramètres de vos plugins, effectuez un test de vitesse, et rien d'évident n'apparaît. Puis quelqu'un mentionne les sauvegardes, et vous comprenez.

Les sauvegardes lentes de sites web sont un vrai problème. Le processus de sauvegarde lui-même peut prendre trop de temps ou échouer silencieusement avant de se terminer. D'un autre côté, votre sauvegarde peut se terminer correctement, mais les ressources qu'elle consomme pendant son exécution ralentissent votre site en direct.

La solution diffère selon le problème que vous rencontrez. Ce tutoriel aborde les deux.

À la fin, vous aurez résolu les problèmes de lenteur des sauvegardes de sites web, exploré les paramètres de Duplicator Pro qui y remédient, et configuré un calendrier de sauvegarde qui ne concurrence pas votre trafic réel.

Voici les points clés à retenir :

• Il existe deux problèmes distincts de vitesse de sauvegarde : un processus de sauvegarde lent ou défectueux, et une sauvegarde qui ralentit votre site en direct pendant la fenêtre de sauvegarde. La solution est différente pour chacun, et cet article couvre les deux.
• Une sauvegarde qui semble complète mais qui échoue à la restauration est un problème de délai d'expiration PHP, pas un problème de corruption. Le format DupArchive de Duplicator Pro évite cela en traitant les fichiers par morceaux au lieu d'une opération continue.
• Réduire la taille de votre archive est le levier le plus rapide. Les répertoires de cache, les fichiers journaux et les archives de sauvegarde restantes d'autres plugins peuvent être exclus en toute sécurité et représentent souvent la majorité du poids inutile de la sauvegarde.
• Les sauvegardes complètes quotidiennes du site sont généralement excessives. Une sauvegarde quotidienne de la base de données seule (moins de 30 secondes) associée à une sauvegarde complète hebdomadaire du site réduit le temps de construction et la charge du serveur sans sacrifier la couverture de restauration.
• Le cron de WordPress ne s'exécute pas selon un calendrier réel. Les sauvegardes planifiées pour 3 heures du matin peuvent être silencieusement décalées vers les heures de pointe de trafic. Remplacer WP-Cron par une vraie tâche cron du serveur est ce qui rend les sauvegardes planifiées réellement fiables.
• Testez une restauration avant d'en avoir besoin. La plupart des gens découvrent une sauvegarde défectueuse lors d'une véritable catastrophe. Vérifier une restauration sur un site de staging prend 20 minutes et est l'étape qui sépare une récupération rapide d'une récupération pénible.

Table des matières

Combien de temps devrait prendre une sauvegarde WordPress ?

Sur un site bien configuré avec un hébergement décent, une sauvegarde complète devrait s'achever en deux à dix minutes. Les grands sites sur un hébergement mutualisé pourraient prendre 30 à 45 minutes, parfois plus. Et le temps varie non seulement en fonction de la taille du site, mais aussi de la manière dont la sauvegarde s'exécute, de ce que votre hébergeur autorise, et si votre serveur est sous charge lorsque le processus démarre.

Quatre facteurs expliquent la majeure partie de la variation.

• Limites d'E/S de l'hôte

L'hébergement mutualisé limite le nombre d'opérations de lecture et d'écriture que votre compte peut effectuer par seconde. Une sauvegarde lit chaque fichier de votre site et les écrit dans une archive. Sur un serveur limité, ce processus ralentit considérablement et peut affecter le temps de réponse de votre site pendant son exécution.

• Taille du site

Une grande médiathèque, une base de données volumineuse ou des années de fichiers de plugins accumulés prolongent tous le temps de construction. Un site de 500 Mo et un site de 5 Go ne seront pas sauvegardés de la même manière.

• Méthode de sauvegarde

Les sauvegardes complètes compressent tout à partir de zéro à chaque fois. Les sauvegardes incrémentielles ne sauvegardent que ce qui a changé depuis la dernière exécution, ce qui les rend beaucoup plus rapides une fois la première sauvegarde terminée. Duplicator Pro prend en charge les deux approches, et la stratégie de deux planifications de ce tutoriel vous offre la plupart des avantages de vitesse des sauvegardes incrémentielles sans la complexité.

• Délais d'attente PHP

La plupart des hébergeurs mutualisés définissent des limites de temps d'exécution PHP entre 30 et 60 secondes. Une sauvegarde qui dépasse cette limite est interrompue en cours de processus. Le fichier semble complet. Il ne l'est pas. C'est l'une des causes les plus fréquentes de sauvegardes qui semblent réussir mais échouent lors d'une restauration.

Ce dont vous avez besoin avant de commencer

Avant de modifier des paramètres, assurez-vous d'avoir les éléments suivants en place.

• Un plugin de sauvegarde WordPress installé et actif. Ce tutoriel utilise Duplicator Pro pour toutes les étapes spécifiques et les références d'interface utilisateur. Duplicator Pro est un plugin de sauvegarde, de migration et de reprise après sinistre pour WordPress utilisé par plus de 1,5 million de professionnels WordPress. Il gère les sauvegardes, les migrations de sites, le staging et les restaurations — y compris un format d'archive par morceaux conçu spécifiquement pour survivre aux limites de délai d'attente PHP courantes sur l'hébergement mutualisé.
• Accès administrateur WordPress (vous en aurez besoin pour accéder aux paramètres de votre plugin de sauvegarde)
• Accès au panneau de contrôle d'hébergement (cPanel ou l'équivalent de votre hébergeur — nécessaire pour la configuration des cron du serveur et les modifications des limites PHP)
• La taille actuelle de votre sauvegarde (trouvez-la dans l'écran de package ou d'historique des sauvegardes de votre plugin)
• Votre type d'hébergement : mutualisé, VPS, WordPress géré ou dédié. Cela est important car certaines corrections de ce tutoriel nécessitent la coopération de votre hébergeur. Sur l'hébergement mutualisé, vous ne pouvez pas toujours modifier vous-même les paramètres PHP.
• Accès au support d'hébergement (chat en direct ou système de tickets de support — vous pourriez en avoir besoin pour les étapes 3 et 8)

Connaître votre type d'hébergement avant de commencer vous fera gagner du temps. Les augmentations de Shell Exec et de la limite de mémoire PHP sont contrôlées au niveau du serveur. Ce que vous pouvez modifier vous-même dépend entièrement de votre plan.

Comment accélérer les sauvegardes de votre site Web

En suivant ces étapes, vous obtiendrez les résultats les plus rapides. La première étape est un diagnostic, afin que vous sachiez quelles corrections s'appliquent réellement à votre situation avant de commencer à modifier les paramètres.

Voici ce que vous allez faire :

• Étape 1 : Identifiez le problème de performance de votre sauvegarde : diagnostiquez si votre processus de sauvegarde est lent ou défectueux, ou si les sauvegardes terminées ralentissent votre site en direct, car la solution est différente pour chacun
• Étape 2 : Réduisez ce qui est sauvegardé : excluez les répertoires de cache, les fichiers journaux et les archives de plugins restantes pour réduire la taille de votre archive, ce qui est le moyen le plus rapide de réduire le temps de construction.
• Étape 3 : Passez à un moteur d'archivage plus rapide : remplacez ZipArchive basé sur PHP par Shell Exec pour la vitesse ou DupArchive pour la résilience sur les hôtes avec des limites d'exécution PHP strictes.
• Étape 4 : Corrigez les sauvegardes lentes de bases de données : changez le mode SQL en Code PHP et exécutez un nettoyage de base de données pour réduire le temps d'exportation sur les bases de données de plus de 20 Mo.
• Étape 5 : Remplacez le cron de WordPress par une vraie tâche cron du serveur : faites en sorte que les sauvegardes planifiées s'exécutent à l'heure exacte que vous définissez au lieu de se déclencher dès qu'un premier visiteur arrive.
• Étape 6 : Mettez en place une stratégie de sauvegarde à deux plannings : exécutez séparément des sauvegardes quotidiennes de la base de données uniquement et des sauvegardes hebdomadaires du site complet afin que les constructions lourdes se produisent aussi rarement que possible.
• Étape 7 : Demandez des limites de ressources serveur plus élevées : augmentez les limites de mémoire et de temps d'exécution PHP en dernier recours lorsque tous les autres paramètres sont déjà optimisés.

Étape 1 : Identifiez votre problème de performance de sauvegarde

Il y a deux problèmes distincts cachés derrière « ma sauvegarde est lente ».

• Problème A : Le processus de sauvegarde lui-même est lent ou défectueux. Les signes incluent des constructions qui prennent plus de 20 minutes, une barre de progression qui se bloque à un pourcentage spécifique, ou une sauvegarde qui semble se terminer mais échoue lors d'une restauration.
• Problème B : Vos sauvegardes ralentissent votre site en direct. Les signes incluent des visiteurs ou des administrateurs signalant une lenteur pendant une fenêtre de temps récurrente ou un outil de surveillance montrant un pic de temps de réponse qui se produit selon un calendrier prévisible.

Pour les distinguer, commencez par le journal de construction de votre plugin de sauvegarde. Pour Duplicator, allez dans Duplicator Pro » Outils » Journaux Duplicator. Trouvez le journal de votre sauvegarde la plus récente.

D'autres plugins ont des journaux similaires — vérifiez les paramètres avancés de votre plugin.

Faites défiler jusqu'en bas. Si vous voyez une erreur de délai d'attente, une erreur de mémoire, ou une ligne qui s'interrompt en cours de processus, c'est le Problème A. Si le journal indique qu'il s'est terminé, mais que votre site est toujours ralenti, c'est le Problème B.

Un autre scénario qui mérite d'être mentionné avant de passer à autre chose : si votre journal de construction indique que la sauvegarde s'est terminée mais que la sauvegarde échoue lors d'une restauration, une limite de temps d'exécution PHP a probablement coupé la construction silencieusement avant qu'elle ne soit terminée.

Le fichier existe, mais il a été tronqué. Cela ressemble au Problème A, mais la cause première est une limite de ressources d'hébergement. L'étape 3 couvre cela directement.

Si vous avez besoin d'aide pour lire les journaux de sauvegarde de Duplicator, lisez ce guide.

Étape 2 : Réduisez ce qui est sauvegardé

Chaque mégaoctet supplémentaire dans votre sauvegarde prolonge le temps de construction. Sur l'hébergement mutualisé, où le CPU et les E/S disque sont déjà limités, une archive gonflée rend les sauvegardes plus lentes et vous rapproche du seuil de délai d'attente où les sauvegardes commencent à échouer.

Le moyen le plus rapide de réduire votre sauvegarde est d'arrêter d'inclure les fichiers qui n'ont pas besoin d'être là.

Les coupables les plus courants :

• Répertoires de cache
• Fichiers journaux
• Fichiers temporaires
• Archives de sauvegarde laissées par d'autres plugins
• Fichiers multimédias volumineux comme des vidéos que vous stockez également sur un CDN ou un service externe

Aucun de ces éléments n’affecte votre capacité à restaurer un site fonctionnel. Les caches se régénèrent automatiquement lorsque les visiteurs chargent des pages. Les journaux ne font pas partie de votre site. Les anciennes archives de sauvegarde d’autres plugins ajoutent simplement du poids.

Voici comment personnaliser les sauvegardes dans Duplicator Pro. Créez une nouvelle sauvegarde en allant dans Duplicator Pro » Sauvegardes » Ajouter.

Dans la section Sauvegarde, vous verrez des préréglages et des filtres.

Activez les filtres de fichiers. Excluez d’abord votre répertoire de cache en sélectionnant le filtre de cache.

Si vous utilisez un plugin de mise en cache comme WP Rocket ou W3 Total Cache, il peut y avoir un sous-dossier spécifique au plugin à l’intérieur de wp-content. Ajoutez le chemin complet pour chacun d’eux.

Ajoutez ensuite tous les répertoires de journaux. Les emplacements courants incluent wp-content/debug.log et les dossiers de journaux spécifiques aux plugins.

N’excluez pas wp-content/uploads à moins que vous ne stockiez tous vos médias sur un CDN séparé et que vous ayez une copie confirmée et actuelle de chaque fichier. Excluez uniquement les extensions de fichiers spécifiques dont vous êtes certain qu’elles sont sauvegardées ailleurs. Une mauvaise gestion de vos médias ici signifie une restauration réussie mais avec la moitié de vos images manquantes.

Une fois que vous avez ajouté vos filtres, continuez avec la sauvegarde. Duplicator Pro analysera votre site et signalera toute autre taille de fichier volumineuse.

Étape 3 : Passez à un moteur de sauvegarde plus rapide

Une fois que votre fichier de sauvegarde est aussi léger que possible, la variable suivante est la manière dont la sauvegarde est créée. Par défaut, il utilise ZipArchive intégré de PHP. Cela fonctionne, mais cela s’exécute entièrement dans PHP, ce qui signifie qu’il est soumis à toutes les limites de ressources que votre hébergeur définit : temps d’exécution, mémoire et limitation du processeur.

Sur un serveur performant, c’est probablement suffisant. Sur un hébergement mutualisé, cela pourrait créer des goulots d’étranglement.

Vous avez deux alternatives, et celle que vous utiliserez dépend de votre hébergeur.

Option A : Shell Zip

Cela remplace le moteur d’archivage de sauvegarde de PHP par le binaire zip natif de votre système d’exploitation. L’outil zip du système d’exploitation est plus rapide que PHP pour la plupart des tâches de compression et ne compte pas dans votre limite de temps d’exécution PHP de la même manière.

Pour changer, allez dans Duplicator Pro » Paramètres » Sauvegardes » Archive et sélectionnez Shell Zip.

Avant de faire le changement, sachez ceci : certains hébergeurs mutualisés économiques désactivent shell_exec au niveau du serveur. Si vous modifiez le paramètre et que votre prochaine construction échoue immédiatement à 0 %, c’est ce qui s’est passé.

Revenez à ZipArchive dans le même écran de paramètres, puis contactez votre hébergeur et demandez-lui d’activer shell_exec pour votre compte. S’ils ne peuvent pas vous aider, passez à l’Option B.

Option B : DupArchive

C’est le propre format d’archive de Duplicator, et il fonctionne différemment du ZIP standard. Au lieu d’une opération de compression continue, DupArchive traite vos fichiers par petits morceaux. Chaque morceau se termine avant le début du suivant.

Sur les plans d’hébergement mutualisé avec des limites de temps d’exécution PHP de 30 à 60 secondes, une sauvegarde ZIP standard qui prend plus de temps que cette limite est interrompue en cours de construction. Le processus s’arrête, mais le fichier est déjà écrit sur le disque.

Votre sauvegarde semble complète. Ensuite, lorsque vous essayez de la restaurer, elle échoue. Le fichier a été coupé avant d’être terminé.

DupArchive évite cela entièrement. Comme chaque bloc réinitialise l'horloge d'exécution de PHP, la sauvegarde survit aux limites qui tueraient une construction ZIP standard. J'ai vu cette solution résoudre des problèmes sur l'hébergement mutualisé plus d'une fois.

Pour changer, allez dans Duplicator Pro » Paramètres » Sauvegardes » Archive et choisissez DupArchive.

Après avoir choisi l'une ou l'autre option, effectuez une sauvegarde de test. Créez une petite sauvegarde, puis vérifiez le journal une fois qu'elle est terminée. Faites défiler jusqu'en bas du journal et confirmez qu'elle s'est terminée avec succès.

Étape 4 : Corriger les sauvegardes lentes de la base de données

Une base de données volumineuse ralentit l'ensemble de la construction de la sauvegarde, pas seulement la partie où la base de données est exportée. Si votre base de données est gonflée, vous le ressentirez sur l'ensemble du processus.

Pour connaître la taille de votre base de données, lancez une nouvelle sauvegarde dans Duplicator Pro et laissez l'assistant de configuration exécuter l'analyse. Il indiquera la taille de votre base de données avant que vous ne vous engagiez à construire la sauvegarde.

Si elle dépasse 20 Mo, ces correctifs peuvent faire une différence notable.

Correction 1 : Changer le mode SQL en code PHP

Allez dans Duplicator Pro » Paramètres » Sauvegardes » Mode SQL et changez le paramètre de MySQL dump à Code PHP. Cela modifie la méthode que Duplicator utilise pour exporter vos tables de base de données.

La méthode du code PHP est généralement plus fiable sur l'hébergement mutualisé car elle est moins susceptible de déclencher des délais d'attente de verrouillage de table qui bloquent l'exportation. C'est un petit changement avec un effet significatif sur les bases de données plus volumineuses.

Correction 2 : Nettoyer la base de données avant votre prochaine sauvegarde

Cela prend quelques minutes, mais cela vaut la peine de le faire avant toute sauvegarde majeure.

Installez WP-Optimize ou un plugin de nettoyage de base de données similaire et exécutez-le pour supprimer les révisions de publication, les commentaires de spam, les transients expirés et les métadonnées orphelines. Ceux-ci s'accumulent discrètement sur les sites actifs et peuvent représenter 30 à 50 % du volume de la base de données sans contenir quoi que ce soit que vous ayez réellement besoin de restaurer.

Sur mon site personnel, j'ai effectué une sauvegarde avant et après un nettoyage rapide de la base de données avec WP-Optimize. Cela a réduit mon temps de sauvegarde de 30 secondes et diminué la taille du fichier.

Cependant, ne nettoyez pas votre base de données et n'exécutez pas immédiatement une sauvegarde critique pour la première fois. Effectuez le nettoyage, puis naviguez sur votre site et vérifiez que tout fonctionne normalement, puis sauvegardez. Les nettoyages sont sûrs lorsqu'ils sont effectués avec un outil réputé, mais vous voulez confirmer que votre site est sain avant de verrouiller cet état dans une sauvegarde.

Après avoir apporté les deux modifications, effectuez une nouvelle sauvegarde et comparez le temps de construction à votre référence précédente. Sur les bases de données de plus de 20 Mo, la différence est généralement visible.

Étape 5 : Remplacez le Cron WordPress par un vrai Cron du serveur

Si vos sauvegardes sont planifiées mais continuent de s'exécuter au mauvais moment, ou si votre site ralentit pendant les heures ouvrables au lieu de la fenêtre de calme que vous avez définie, le cron de WordPress en est probablement la raison.

WP-Cron ne s'exécute pas selon un calendrier réel. Il ne se déclenche que lorsque quelqu'un visite votre site.

Lorsque le trafic arrive, WordPress vérifie si des tâches planifiées sont en retard et les exécute à ce moment-là. Une sauvegarde que vous avez planifiée pour 3 heures du matin s'exécute lorsque le premier visiteur se présente, ce qui peut se produire en plein milieu de votre fenêtre de trafic de pointe.

Remplacer WP-Cron par une tâche cron du serveur garantit que vos sauvegardes s'exécutent à l'heure exacte que vous définissez, à chaque fois, quel que soit le trafic.

Commencez par créer un compte sur https://cron-job.org/. Ensuite, créez une nouvelle tâche cron.

Nommez la nouvelle tâche cron. Définissez ceci comme l'URL, en la remplaçant par le domaine de votre site : https://example.com/wp-admin/admin-ajax.php?action=duplicator_process_worker

Définissez la Planification d'exécution sur Toutes les 1 minute.

Une fois la tâche cron du serveur active et enregistrée, ajoutez cette ligne à votre fichier wp-config.php, au-dessus de la ligne qui dit "C'est tout, ne modifiez pas !" :

define('DISABLE_WP_CRON', true);

Cela indique à WordPress d'arrêter d'exécuter son propre système cron.

Ajoutez la ligne define à wp-config.php uniquement après que la tâche cron du serveur soit confirmée et enregistrée. Si vous désactivez WP-Cron en premier, toutes les tâches planifiées sur votre site s'arrêtent immédiatement. Les sauvegardes planifiées, les publications planifiées, tout ce qui dépend de WP-Cron s'arrête jusqu'à ce que le cron du serveur soit actif.

Si vous êtes sur un hébergement WordPress géré comme WP Engine, Kinsta ou Flywheel, consultez la documentation de votre hébergeur avant de modifier wp-config.php. Certains hébergeurs gérés gèrent le cron du serveur différemment ou s'en chargent pour vous.

Après la configuration, retournez à Duplicator Pro » Paramètres » Planification des sauvegardes et vérifiez que l'heure de la prochaine exécution planifiée reflète exactement ce que vous avez configuré. Cette confirmation est votre signal que le transfert a fonctionné.

Étape 6 : Configurez une stratégie de sauvegarde à deux calendriers

Les sauvegardes complètes quotidiennes du site sont l'une des causes les plus fréquentes de sauvegardes lentes et de sites lents sur l'hébergement mutualisé. Elles sont également, pour la plupart des sites WordPress, plus que ce dont vous avez réellement besoin.

Votre base de données change constamment, avec de nouvelles publications, commandes, soumissions de formulaires, commentaires et activité des plugins. En revanche, vos fichiers, thèmes, plugins et téléchargements sont mis à jour occasionnellement.

Exécuter une sauvegarde complète chaque jour signifie compresser et archiver des gigaoctets de fichiers qui n'ont pas été modifiés récemment.

La solution consiste en deux planifications de sauvegarde distinctes.

• Planification A : sauvegarde quotidienne de la base de données uniquement. Une sauvegarde de la base de données uniquement capture chaque modification de votre contenu, de vos commandes et de vos paramètres sans toucher à vos fichiers. Sur la plupart des sites, elle se termine en moins de 30 secondes. Exécutez-la quotidiennement.
• Planification B : sauvegarde hebdomadaire complète du site. Fichiers inclus, exécutez-la une fois par semaine pendant votre période de trafic le plus faible. C'est la sauvegarde que vous restaurez si quelque chose tourne très mal.

Avant de définir la planification, trouvez votre véritable période de faible trafic. Recherchez le bloc de deux heures avec le moins de sessions sur une semaine typique.

Pour la plupart des sites, cela se situe entre 2h et 5h du matin, mais vérifiez avec vos propres données. Votre schéma de trafic n'est pas le même que celui de quelqu'un d'autre.

Ensuite, allez à Duplicator Pro » Planification des sauvegardes » Ajouter une nouvelle. Nommez la planification quelque chose comme Sauvegarde de la base de données. Ajoutez un nouveau modèle de sauvegarde.

Nommez le modèle. Choisissez le préréglage de sauvegarde Base de données uniquement et enregistrez-le.

Retournez à la nouvelle planification et choisissez le modèle de sauvegarde de base de données que vous venez de créer. Choisissez un emplacement de stockage et définissez-le pour qu'il s'exécute quotidiennement.

Enregistrez-le. Créez ensuite un deuxième plan et répétez le processus, mais avec un modèle de sauvegarde complète du site. Laissez-le s'exécuter chaque semaine.

Les deux plans apparaîtront dans Duplicator Pro » Plans de sauvegarde avec leurs prochaines heures d'exécution indiquées.

Étape 7 : Ajoutez des sauvegardes incrémentielles

Les sauvegardes complètes compressent l'intégralité de votre site à partir de zéro à chaque exécution. C'est bien pour les sauvegardes complètes hebdomadaires du site, mais c'est plus que ce dont la plupart des sites ont besoin pour une protection quotidienne.

Les sauvegardes incrémentielles adoptent une approche différente : après la première sauvegarde complète, elles ne sauvegardent que ce qui a changé depuis la dernière exécution. La sauvegarde se termine plus rapidement car elle ne retraiter pas les fichiers qui n'ont pas changé.

Duplicator Pro n'exécute pas de véritables sauvegardes incrémentielles, mais la stratégie à deux plans de l'étape 6 vous apporte la plupart des mêmes avantages. Les sauvegardes quotidiennes de la base de données seule capturent tout ce qui change sur un site WordPress typique, se terminant en moins de 30 secondes. La sauvegarde complète hebdomadaire du site s'occupe du reste.

Pour la plupart des sites, cette division couvre le besoin pratique que les sauvegardes incrémentielles sont conçues pour résoudre.

Si votre site est suffisamment volumineux pour que même les sauvegardes complètes hebdomadaires du site soient constamment lentes ou échouent, les sauvegardes incrémentielles de fichiers peuvent valoir la peine d'être mises en œuvre. Des outils comme BlogVault traitent les sauvegardes sur leurs serveurs plutôt que sur les vôtres, ce qui élimine le problème de charge du serveur.

Étape 8 : Demandez des limites de ressources serveur plus élevées

Les limites de mémoire et de temps d'exécution PHP sont de véritables contraintes, mais les modifier nécessite la coopération de votre hébergeur et ne résout pas les problèmes sous-jacents comme une archive volumineuse ou un plan mal synchronisé.

Traitez d'abord les étapes précédentes. Si les sauvegardes échouent toujours, le plafond pourrait être les limites de ressources de votre plan d'hébergement.

Deux paramètres sont les plus importants pour la vitesse de sauvegarde : memory_limit et max_execution_time.

memory_limit contrôle la quantité de RAM que PHP peut utiliser pendant un seul processus. Les sauvegardes sont gourmandes en mémoire. Si votre limite est définie sur 64 Mo ou 128 Mo, les constructions volumineuses manquent d'espace et échouent avant de se terminer.

Demandez au moins 256 Mo. Si votre hébergeur propose 512 Mo, demandez cela à la place.

max_execution_time contrôle combien de temps un processus PHP peut s'exécuter avant que le serveur ne le termine. La valeur par défaut sur de nombreux hébergements mutualisés est de 30 à 60 secondes. Une sauvegarde volumineuse nécessite beaucoup plus que cela. Demandez 300 secondes.

Contactez l'équipe de support de votre hébergeur et soyez précis dans votre demande. Demandez une memory_limit de 512 Mo et une max_execution_time de 300 secondes.

Si votre hébergeur ne peut pas ou ne veut pas augmenter ces limites, DupArchive de l'étape 3 est votre voie pratique à suivre. Il est spécialement conçu pour fonctionner dans des limites PHP serrées en divisant le processus. Il est plus lent que Shell Exec sur un serveur capable, mais il se termine là où une construction ZIP standard n'y parviendrait pas.

Après tout changement de limite, exécutez une sauvegarde de test et ouvrez le journal de construction. Confirmez que la sauvegarde s'est terminée sans erreur de délai d'attente ou de mémoire.

Dépannage : lorsque les sauvegardes sont toujours lentes ou cassées

Traiter les étapes ci-dessus résout la plupart des problèmes de vitesse de sauvegarde de site Web. Si quelque chose ne va toujours pas, voici ce que vous rencontrez le plus probablement et comment le surmonter.

La sauvegarde se termine mais échoue à la restauration

Vous voyez une sauvegarde, le journal de compilation n'affiche aucune erreur évidente, mais lorsque vous exécutez l'installateur, il échoue ou restaure un site vierge.

Cela se produit parce qu'une limite de temps d'exécution PHP a interrompu la compilation avant qu'elle ne soit réellement terminée. Le fichier a été écrit sur le disque jusqu'à ce point, puis s'est arrêté.

Passez à DupArchive (couvert à l'étape 3), puis supprimez la sauvegarde échouée et créez-en une nouvelle. Exécutez l'installateur et vérifiez que la restauration se termine avant de vous y fier.

La sauvegarde est bloquée à un pourcentage spécifique

La barre de progression se bloque à un point particulier et y reste pendant plus de dix minutes sans bouger.

Un fichier volumineux ou une table de base de données verrouillée bloque le processus à ce point exact de la compilation. Allez dans le journal de sauvegarde et faites défiler pour trouver le dernier fichier ou la dernière table répertoriée avant que le journal ne s'arrête. C'est votre coupable.

S'il s'agit d'un fichier, ajoutez-le à vos filtres d'exclusion (étape 2) et reconstruisez. S'il s'agit d'une table de base de données, passez le mode SQL à Code PHP (étape 4) et réessayez.

Le site ralentit tous les soirs à la même heure

Les visiteurs ou votre outil de surveillance signalent une lenteur pendant une fenêtre spécifique. Le moment correspond à votre sauvegarde planifiée.

Votre sauvegarde s'exécute pendant une période de trafic actif et entre en compétition pour les mêmes ressources CPU et disque qui servent vos visiteurs. Vérifiez votre fenêtre de faible trafic réelle dans Google Analytics et reprogrammez la sauvegarde à ce moment-là.

Si vous effectuez des sauvegardes complètes quotidiennes du site, passez à la stratégie de deux planifications de l'étape 6. Les sauvegardes de base de données uniquement se terminent assez rapidement pour que l'impact sur les performances soit minime, même pendant un trafic modéré.

Shell Exec provoque un échec de construction immédiat

Vous avez changé le moteur d'archivage pour Shell Exec, et la compilation suivante échoue à 0 % avec une erreur immédiate.

Votre hébergeur a désactivé shell_exec au niveau du serveur. Revenez à ZipArchive ou DupArchive. Contactez ensuite votre hébergeur et demandez spécifiquement si shell_exec peut être activé pour votre compte.

S'ils disent non, DupArchive est votre moteur d'archivage à long terme. Il gère les mêmes problèmes de délai d'attente que Shell Exec aurait résolus, mais par une méthode différente.

Les sauvegardes fonctionnent en staging mais échouent sur le serveur live

Vos sauvegardes réussissent sur les sites de staging ou locaux, mais expirent ou produisent des fichiers corrompus sur la production.

Votre serveur en direct a des limites PHP plus strictes ou est soumis à une limitation CPU active que votre environnement de staging n'a pas. Comparez les paramètres PHP entre les environnements : vérifiez memory_limit et max_execution_time dans les deux. Demandez des limites plus élevées à votre hébergeur en direct (étape 7), ou passez à DupArchive pour travailler dans les limites existantes.

Si rien de tout cela ne résout votre problème, l'équipe de support de Duplicator Pro est la prochaine étape logique. Allez sur duplicator.com et ouvrez un ticket de support. Incluez votre journal de compilation, vos paramètres PHP et votre environnement d'hébergement. Ces trois informations vous permettront d'arriver à une résolution plus rapidement qu'une description générique du problème.

Questions fréquemment posées (FAQ)

Une construction ZIP standard qui prend plus de temps que la limite de votre hébergeur est interrompue en cours de processus et produit un paquet corrompu. DupArchive survit à ces limites car chaque morceau réinitialise l'horloge.

Il n'est pas toujours plus rapide que ZIP sur des serveurs performants, mais il est considérablement plus fiable sur les environnements d'hébergement mutualisé contraints.

La question la plus importante est de savoir si vous avez testé une restauration récemment. Une sauvegarde que vous n'avez jamais testée est une sauvegarde dont vous ne savez pas réellement si elle fonctionne. Choisissez un environnement de staging, restaurez votre sauvegarde la plus récente et vérifiez que le site se charge correctement.

Exécutez votre prochaine sauvegarde sans vous demander si elle fonctionnera

Une sauvegarde lente est un inconvénient. Une sauvegarde qui semble complète mais qui ne peut pas être restaurée est un problème différent, et c'est un problème plus courant que la plupart des gens ne le pensent.

Les paramètres de ce tutoriel existent parce que l'hébergement mutualisé n'a pas été conçu pour les sauvegardes WordPress. Duplicator Pro, si.

Plus de 1,5 million de professionnels WordPress utilisent Duplicator Pro pour gérer les sauvegardes, les migrations, le staging et la reprise après sinistre sur des sites de toutes tailles. Le format DupArchive, la stratégie de deux planifications et les filtres d'exclusion de fichiers vous aident à éviter les sauvegardes lentes ou gourmandes en ressources.

Si ce tutoriel vous a aidé, ces guides méritent également d'être mis en favoris.

• Comment les sauvegardes WordPress affectent les performances du site (et comment y remédier)
• Arrêtez de deviner pourquoi les sauvegardes échouent (Vérifiez ces journaux à la place)
• Le site vient de planter ? Voici votre plan complet de récupération de site web
• Pourquoi votre site WordPress a besoin d'une surveillance des sauvegardes (pas seulement de sauvegardes)
• Comment visualiser votre sauvegarde WordPress comme un site web fonctionnel