La plupart des sites que je reprends ont des sauvegardes. Une extension tourne, un rapport arrive chaque semaine par email, l’hébergeur affiche une liste rassurante de points de restauration. Tout va bien, jusqu’au jour où il faut s’en servir.
Ce jour-là, on découvre des choses. Que l’archive contient les fichiers mais pas la base de données. Qu’elle date d’avant la migration du mois dernier. Qu’elle pèse 40 Mo pour un site qui en fait quatre giga. Ou, le cas le plus vicieux, qu’elle se restaure sans la moindre erreur et donne un site à moitié fonctionnel, dont on ne mesure les manques qu’au fil des jours suivants.
Le problème n’apparaît jamais au moment de la sauvegarde. Il apparaît le jour de la panne, quand plus personne n’a le temps de chercher. Une sauvegarde a donc deux états possibles : testée, ou supposée. Voici comment je fais passer une sauvegarde du second état au premier, sans jamais toucher au site en production.
Les 7 étapes du protocole de test d’une sauvegarde WordPress : inventorier, isoler, fermer la porte, restaurer, adapter les URL, contrôler, consigner.
1. Inventorier ce que contient l’archive
Avant de restaurer quoi que ce soit, ouvrez le fichier et regardez ce qu’il y a dedans. Vous cherchez trois choses :
- wp-content, avec ses thèmes, ses extensions et ses médias
- les fichiers de configuration de la racine
- un export SQL de la base de données
Si l’un des trois manque, vous avez déjà votre réponse et le reste peut attendre : une archive sans base ne restaure ni les articles, ni les pages, ni les réglages, ni les comptes utilisateurs, et une archive sans uploads rend un site sans images.
Le poids total est un bon indicateur. Comparez-le à la taille réelle du site chez l’hébergeur : un écart d’un facteur dix ne s’explique jamais tout seul. Profitez-en pour noter la version de WordPress et celle de PHP au moment de la copie, parce qu’elles décideront de l’environnement dans lequel vous allez travailler.
Notez enfin la date exacte, à l’heure près. Sur un site de commande ou d’inscription, annoncer deux heures de données perdues ou vingt-six heures ne donne pas du tout la même conversation avec le client.
2. Monter un environnement isolé
Ailleurs, cela veut dire hors du site en production, hors d’un sous-dossier du site en production, et sans jamais écraser la base « juste pour voir ». Un environnement local avec Local, DDEV ou Docker fait l’affaire. Un sous-domaine dédié chez le même hébergeur fait mieux, parce qu’il reproduit la version de PHP, les limites mémoire et les extensions du serveur d’origine. C’est souvent là que les problèmes se révèlent : une machine locale généreuse masque volontiers une limite de production.
Vérifiez la place disponible avant de commencer. Restaurer une copie de quatre giga sur un hébergement qui en a cinq de libre, c’est risquer de saturer le disque et de faire tomber le site voisin, celui qui est en ligne pour de vrai.
3. Fermer la porte avant de restaurer
Fermez l’environnement avant d’y mettre quoi que ce soit. Une copie de test laissée ouverte crée trois ennuis assez classiques :
- du contenu dupliqué, indexé par Google
- des emails automatiques partis vers de vrais clients
- des paiements de test passés sur un vrai compte
Une protection par mot de passe au niveau du serveur règle l’essentiel, puisqu’elle s’applique avant même que WordPress démarre ; complétez avec le blocage de l’indexation, la neutralisation des envois d’emails et le mode test de la passerelle de paiement. C’est l’étape qu’on saute quand on est pressé, et c’est celle qui coûte le plus cher quand on la saute.
4. Restaurer les fichiers, puis la base
Les fichiers d’abord, la base ensuite. Créez une base vide, importez le dump, puis reprenez wp-config.php avec les nouveaux identifiants.
Deux détails font échouer la moitié des imports. L’encodage, d’abord : un dump en utf8 importé dans une base en utf8mb4, ou l’inverse, transforme les accents en caractères illisibles, et le problème se voit parfois sur une seule page sur trente. La taille, ensuite : au-delà de quelques dizaines de Mo, phpMyAdmin abandonne en silence ou coupe l’import au milieu, alors qu’un mysql < dump.sql en ligne de commande, ou WP-CLI, passe sans discuter. Regardez aussi les droits sur les fichiers après copie, parce qu’un wp-content au mauvais propriétaire donne un site qui s’affiche très bien mais refuse toute mise à jour et tout envoi de média.
5. Adapter les URL sans casser les réglages
Le site restauré répond sur une autre adresse, il faut donc remplacer l’ancien domaine par le nouveau. C’est l’étape où l’on casse le plus de choses, et rarement de façon visible.
Les réglages de thème, les widgets et les champs personnalisés sont stockés en données sérialisées, un format qui enregistre la longueur de chaque chaîne en même temps que son contenu. Un UPDATE SQL ou un rechercher-remplacer sur le dump change le texte sans toucher à la longueur déclarée. La valeur devient illisible pour PHP, et WordPress la remplace par un réglage vide, sans le moindre message d’erreur. On s’en aperçoit une semaine plus tard, quand quelqu’un demande où sont passés les blocs de la page d’accueil.
Comparaison d’une valeur sérialisée WordPress : longueur correcte à l’origine, longueur fausse après un UPDATE brut, longueur recalculée avec wp search-replace.
La commande wp search-replace ancien.fr nouveau.fr recalcule ces longueurs correctement. Lancez-la d’abord avec –dry-run, qui affiche le nombre d’occurrences concernées sans rien modifier. Les extensions de migration sérieuses font le même travail, à condition d’utiliser leur fonction dédiée et pas un remplacement brut.
6. Vérifier ce qui compte vraiment
Une page d’accueil qui s’affiche ne prouve pas grand-chose. Connectez-vous à l’administration avec un compte réel, ouvrez un article, une page et une page d’archive, puis vérifiez les images à la fois dans la médiathèque et dans les contenus, parce que les deux peuvent diverger. Enregistrez une fois les réglages de permaliens, sinon les URL internes renvoient des 404 qui n’ont rien à voir avec la sauvegarde. Jetez un œil à la console du navigateur : elle signale immédiatement les ressources encore chargées depuis l’ancien domaine.
Checklist des huit contrôles à faire sur un site WordPress restauré : administration, contenus publics, médias, formulaire, tunnel de commande, permaliens, tâches planifiées, console du navigateur.
Les formulaires méritent mieux qu’un coup d’œil. Un formulaire restauré peut s’afficher normalement, accepter la saisie, afficher un message de succès et ne rien envoyer du tout, simplement parce que la configuration SMTP pointe vers des identifiants qui n’existent plus. Envoyez-en un pour de bon et allez vérifier la réception. Même logique pour un site marchand : allez jusqu’à l’écran de paiement, en mode test. Et si le site dépend de tâches planifiées, un wp cron event list dit en trois secondes si elles ont survécu au déménagement.
7. Consigner le résultat, puis supprimer la copie
Le test se termine avec un chronomètre, plus qu’avec un site qui s’affiche. Notez la durée totale, de l’ouverture de l’archive au site fonctionnel : c’est votre vrai délai de remise en service, et c’est la seule chose que votre direction ou votre client vous demandera le jour de l’incident. Notez aussi ce qui a manqué, ce qui a demandé une intervention manuelle, et la date réelle des données récupérées.
Puis supprimez la copie. Un environnement de test oublié devient en quelques mois un WordPress non mis à jour, exposé, avec une vraie base de données dedans. J’en ai retrouvé plusieurs, toujours par hasard, jamais au bon moment.
À quelle fréquence refaire ce test ?
Une fois par an suffit pour un site vitrine stable. Deux à quatre fois par an pour un site qui vend ou qui collecte des données. Et systématiquement après un changement d’hébergeur, un changement de méthode de sauvegarde, une refonte, ou l’ajout d’une extension qui écrit dans la base.
Le reste du temps, une surveillance légère suffit : la sauvegarde la plus récente existe, elle pèse un poids cohérent, elle se télécharge. Beaucoup de sites échouent déjà sur ce dernier point, et c’est en général le moment où l’on découvre que la sauvegarde est introuvable alors que tout le monde la croyait en place.
Une demi-journée par an, c’est le prix pour savoir. C’est aussi la différence entre annoncer « on restaure, comptez deux heures » et annoncer « on va voir ce qu’on peut récupérer ».
Présentation de l’auteur
Andrei Chirtes est développeur web et fondateur de 2Cafés, où il s’occupe de la maintenance, de l’hébergement et de la sécurisation de sites WordPress pour des TPE, des PME et des cabinets professionnels.