Une archive ZIP rangée sur un disque donne une impression de sécurité. Le problème arrive le jour où il faut l’ouvrir : base de données absente, fichiers incomplets, mot de passe oublié, sauvegarde chiffrée dont personne ne retrouve la clé, ou copie tellement ancienne qu’elle ne contient plus les derniers articles.
Une sauvegarde n’est donc pas seulement un fichier produit sans erreur. C’est un ensemble que l’on sait restaurer dans un délai acceptable, avec une procédure comprise et des contrôles précis.
Ce guide propose une méthode de répétition sur un environnement isolé. Il ne demande pas de casser le site public pour prouver que la sauvegarde fonctionne.
La réponse courte
Pour restaurer un WordPress classique, il faut au minimum réunir deux familles de données créées au même moment :
- la base MySQL ou MariaDB, qui contient notamment les articles, pages, commentaires, réglages et comptes ;
- les fichiers du site, dont les extensions, le thème, les médias envoyés, la configuration et les éventuels développements personnalisés.
L’export XML proposé par WordPress peut servir à transférer du contenu. Il ne remplace pas une sauvegarde complète du site.
Le test fiable consiste à reconstruire une copie privée, sans trafic réel, sans indexation et sans envoi de courriels, puis à vérifier que les contenus, médias, connexions et fonctions essentielles reviennent correctement.
Commencer par définir ce que l’on refuse de perdre
La bonne fréquence ne se choisit pas avec une formule universelle. Elle dépend du rythme de publication et de l’activité du site.
Deux questions simples permettent de cadrer le besoin :
- combien d’heures ou de jours de modifications peut-on accepter de perdre ?
- combien de temps le site peut-il rester indisponible ?
Un blog mis à jour deux fois par mois n’a pas la même urgence qu’une boutique recevant des commandes toute la journée. En revanche, un petit site peut contenir dix ans d’archives irremplaçables. Son trafic ne mesure pas la valeur de ce qu’il faudrait reconstruire.
Il faut aussi décider ce qui entre dans le périmètre : contenu, commentaires, images originales, code du thème enfant, fichiers de configuration, tâches planifiées, règles du serveur, certificats, comptes techniques, zone DNS et instructions de reprise. Tout n’est pas stocké au même endroit.
Base et fichiers doivent former un même jeu
WordPress rappelle que la base et les fichiers sont deux parties distinctes d’une sauvegarde complète. Télécharger le répertoire du site ne copie généralement pas la base de données, qui vit dans MySQL ou MariaDB. À l’inverse, un export SQL ne contient pas les images de wp-content/uploads, le thème ou les extensions.
Le plus simple est d’associer chaque export SQL à sa copie de fichiers avec :
- une date et une heure en UTC ou dans un fuseau clairement indiqué ;
- l’identifiant du site et de l’environnement ;
- les versions principales connues ;
- une somme de contrôle pour détecter un fichier tronqué ou modifié ;
- une durée de conservation ;
- l’emplacement de la procédure de restauration.
Le fichier SQL ne doit pas traîner dans un répertoire public du serveur. Il peut contenir des adresses électroniques, des jetons, des réglages internes et d’autres données sensibles. La copie hors site doit être chiffrée, et la clé conservée séparément selon une méthode réellement récupérable.
Ne pas confondre automatisation et preuve
Une tâche automatique peut écrire chaque nuit « succès » tout en sauvegardant la mauvaise base, un répertoire vide ou un volume arrivé à saturation. Il faut contrôler au minimum :
- la présence du nouveau jeu de sauvegarde ;
- sa taille par rapport aux précédents ;
- l’absence d’erreur dans le journal ;
- la possibilité de lire l’archive ;
- la présence d’un export SQL non vide ;
- la présence des médias récents ;
- la réplication vers un autre emplacement.
Conserver plusieurs générations protège aussi contre une compromission découverte tardivement. La dernière copie peut déjà contenir le fichier malveillant ou la corruption que l’on cherche à éliminer.
Préparer un terrain de restauration isolé
Le test ne doit pas remplacer la base publique « pour voir si ça passe ». Il faut utiliser une machine locale, un conteneur, une machine virtuelle ou un sous-domaine de recette protégé.
Avant l’import :
- créer une base et un utilisateur dédiés ;
- empêcher l’accès public ou imposer une authentification ;
- bloquer l’indexation par les moteurs, sans considérer ce seul blocage comme une protection d’accès ;
- désactiver les courriels sortants, webhooks, paiements, newsletters et publications automatiques ;
- ne pas réutiliser les secrets de production lorsque cela peut être évité ;
- prévoir une URL de recette distincte ;
- noter la version de PHP, de la base et du serveur web utilisée pour le test.
Le but est de reproduire assez fidèlement le site pour révéler les problèmes, sans déclencher d’action vers de vrais utilisateurs ou services.
Restaurer les fichiers, puis la base
La documentation WordPress recommande de traiter les fichiers et la base comme un même ensemble. Sur la cible isolée, on remet d’abord les fichiers nécessaires, puis on importe la base et on adapte la configuration à l’environnement de recette.
Avec WP-CLI, un export ou un import peut ressembler à ceci :
wp db export sauvegarde-site.sql
wp db import sauvegarde-site.sql
Ces commandes utilisent la configuration de la base indiquée dans wp-config.php. Elles ne doivent pas être copiées à l’aveugle : le chemin courant et la cible doivent être vérifiés avant toute importation. Une importation sur la mauvaise base peut écraser des données.
Si le nom de domaine change, les URL enregistrées doivent être adaptées en respectant les données sérialisées de WordPress. WP-CLI fournit wp search-replace et une option de simulation :
wp search-replace 'https://www.exemple.test' 'https://recette.exemple.test' --all-tables-with-prefix --dry-run
La simulation permet de voir ce qui serait modifié. Elle ne dispense pas de vérifier la liste des tables et la cible. Une recherche-remplacement SQL brute peut casser des valeurs sérialisées.
La liste de contrôle après restauration
Un écran d’accueil visible ne prouve pas que le site est revenu. Il faut vérifier plusieurs parcours.
Contenu et médias
- ouvrir des articles anciens et récents ;
- afficher une image, un PDF et un média dont le nom contient des caractères particuliers ;
- contrôler les catégories, étiquettes, menus et permaliens ;
- vérifier les commentaires et les pièces jointes attendues ;
- comparer quelques totaux avec le site source.
Administration
- se connecter avec un compte de test prévu pour la recette ;
- ouvrir l’éditeur sans modifier la production ;
- vérifier les rôles et les comptes administrateurs ;
- contrôler l’état du thème, des extensions et des tâches planifiées ;
- relever les erreurs PHP et serveur sans les afficher aux visiteurs.
Fonctions sensibles
- soumettre un formulaire vers une boîte de test ;
- confirmer que les vrais courriels et webhooks restent bloqués ;
- tester la recherche, les flux, le plan de site et les redirections utiles ;
- vérifier les pages protégées et les téléchargements ;
- contrôler les intégrations externes sans réutiliser de transaction réelle.
Rendu
- regarder l’accueil, un article, une archive, une page et une erreur 404 ;
- tester ordinateur et mobile ;
- vérifier que les styles, polices et scripts ne dépendent pas d’un fichier absent ;
- contrôler les ressources qui retournent une erreur.
Mesurer le résultat du test
Le compte rendu tient sur une page si les informations sont bien choisies :
- date du jeu restauré ;
- date de la répétition ;
- durée entre le début et le retour d’un site utilisable ;
- quantité de contenu perdue par rapport à la production ;
- anomalies rencontrées ;
- étapes manuelles non documentées ;
- personne capable de refaire la procédure ;
- prochaine date de répétition.
Une restauration réussie mais longue peut révéler un objectif irréaliste. Une restauration rapide mais amputée des médias récents est également un échec partiel. L’intérêt du test est précisément de rendre ces limites visibles avant l’incident.
Les pièges les plus fréquents
Tout garder sur le même serveur
Une copie présente sur le disque de production peut disparaître avec la panne, le chiffrement malveillant ou l’erreur d’administration qui touche ce serveur. Il faut au moins une copie indépendante.
Ne sauvegarder que la base
Les textes reviennent, mais pas les médias, le thème ou le code personnalisé. Le site peut être lisible tout en étant inutilisable ou méconnaissable.
Ne sauvegarder que les fichiers
Les images sont là, mais les articles, réglages et utilisateurs manquent parce que la base n’était pas dans le lot.
Garder une seule génération
La dernière sauvegarde peut déjà intégrer la corruption. Plusieurs points de reprise permettent de remonter avant l’incident.
Tester avec les services réels actifs
Une copie de recette peut renvoyer une ancienne newsletter, appeler un webhook ou réexécuter une tâche. Les sorties doivent être neutralisées avant l’ouverture du site restauré.
Écrire une procédure que personne n’a exécutée
Une suite de commandes théoriques n’est pas encore un plan de reprise. La première répétition sert autant à corriger la documentation qu’à vérifier les fichiers.
Une cadence réaliste
La sauvegarde suit l’activité du site ; la répétition suit son risque. Un exemple raisonnable pour un blog régulièrement alimenté peut être :
- sauvegarde automatique quotidienne de la base ;
- sauvegarde régulière des fichiers et après ajout massif de médias ;
- copie vers un emplacement indépendant ;
- contrôle hebdomadaire des journaux et tailles ;
- restauration d’essai trimestrielle ou avant une migration importante ;
- test supplémentaire après un changement d’architecture ou d’outil de sauvegarde.
Ce calendrier reste à adapter. La question utile n’est pas « quelle fréquence paraît professionnelle ? », mais « quelle perte réelle et quel délai de reprise sommes-nous capables d’assumer ? ».
Le verdict BlackFury
La sauvegarde parfaite n’existe pas. Il existe en revanche une différence nette entre un fichier que l’on espère utilisable et une procédure déjà exécutée.
Le bon résultat n’est pas une coche verte dans une extension. C’est un site reconstruit sur une cible isolée, des contenus et médias vérifiés, des sorties maîtrisées, un temps de reprise mesuré et une documentation assez claire pour recommencer.
Une sauvegarde devient crédible le jour où sa restauration cesse d’être une hypothèse.
Les autres contenus consacrés à l’administration du site sont regroupés dans la rubrique WordPress de BlackFury. La manière dont le site distingue faits, corrections et limites est expliquée dans sa méthode éditoriale.
Sources officielles
- WordPress Developer Resources — Backups
- WordPress Developer Resources — Backing Up Your Database
- WP-CLI —
wp db exportetwp db import - WP-CLI —
wp search-replace - WordPress Developer Resources — Hardening WordPress
