Un site WordPress auto-hébergé ne tient pas dans un seul dossier. Son contenu est réparti entre une base de données, des fichiers, des réglages de serveur et parfois des services externes. Une archive téléchargée une fois, puis laissée sur le même hébergement, peut rassurer sans protéger contre une suppression, une panne matérielle ou un compte compromis.
La règle 3-2-1 donne un cadre simple : trois copies des données importantes, sur deux types de supports ou emplacements distincts, avec une copie hors site. Ce n’est pas une garantie magique. Elle devient utile lorsqu’on sait précisément ce que chaque copie contient, qui peut la lire et comment la restaurer sans toucher au site public.
La réponse courte
Pour restaurer un WordPress classique, il faut au minimum les fichiers du site et la base de données issus d’un même moment. La documentation officielle de WordPress rappelle que les thèmes, extensions, téléversements, wp-config.php et les fichiers du serveur ne vivent généralement pas dans MySQL ou MariaDB ; inversement, télécharger le répertoire du site ne sauvegarde pas la base.
Une stratégie 3-2-1 adaptée à un blog peut être la suivante :
- le site de production constitue la première copie ;
- une sauvegarde complète chiffrée est déposée sur un stockage distinct du serveur ;
- une autre copie est conservée hors site, dans un compte ou un lieu séparé ;
- un test de restauration isolé vérifie le jeu de sauvegarde à intervalles décidés.
Le fichier WXR exporté par WordPress reste précieux pour porter ou archiver les contenus, mais il ne remplace ni le dump SQL ni les fichiers. Le guide BlackFury consacré au WXR détaille cette frontière ; ici, l’objectif est de construire le système complet autour de cette pièce.
Ce que signifie 3-2-1, sans le transformer en slogan
La formulation courante est simple : trois copies, deux supports ou emplacements, une copie hors site. La CISA la décrit comme une manière d’augmenter les chances de récupérer des données perdues ou corrompues.
Pour un WordPress auto-hébergé, les chiffres ne disent pas qu’il faut acheter exactement deux disques externes. Ils imposent surtout d’éviter un point de défaillance commun. Une archive dans /home, une seconde dans public_html/archives et une troisième dans le compte du même hébergeur sont trois fichiers, mais pas forcément trois protections indépendantes.
| Élément de la règle | Exemple cohérent | Erreur fréquente |
|---|---|---|
| Copie 1 | site et base en production | confondre production et sauvegarde |
| Copie 2 | archive chiffrée sur un support local ou un stockage séparé | laisser l’archive sur le même serveur |
| Copie 3 | stockage hors site, protégé par un compte distinct | synchroniser toutes les copies avec la même suppression |
| Deux emplacements | serveur et support local, ou serveur et stockage distant | multiplier les dossiers sous le même compte |
| Une restauration testée | clone isolé et compte rendu daté | vérifier seulement que le ZIP s’ouvre |
La séparation doit être proportionnée au risque. Un blog personnel ne requiert pas l’infrastructure d’une banque, mais il mérite mieux qu’une unique archive automatique dont personne ne connaît le mot de passe.
Procédure : définir le périmètre avant l’outil
Le bon outil dépend de ce qu’il doit protéger. Avant d’installer une extension de sauvegarde ou de programmer une tâche, dresser l’inventaire évite les angles morts.
1. Lister les données qui font réellement le site
La documentation WordPress Backups distingue explicitement fichiers et base. La base conserve notamment publications, commentaires, réglages et métadonnées. Les fichiers comprennent le cœur, les thèmes, les extensions, les médias, le code personnalisé, wp-config.php et, selon l’installation, .htaccess ou des pages statiques.
Une sauvegarde de base peut contenir des commentaires, des comptes et d’autres informations personnelles. La politique de confidentialité de BlackFury permet d’identifier ces données avant de choisir leur durée de conservation, leur chiffrement et les personnes autorisées à restaurer une copie.
Ajoutez à la fiche de sauvegarde ce qui ne se trouve pas forcément dans WordPress : configuration du serveur web, version de PHP, tâche planifiée, règles DNS, certificats, boîtes de réception utilisées par les formulaires, clés d’API, accès à un CDN et compte de stockage. Il ne s’agit pas de placer des secrets en clair dans une note : il s’agit de savoir où les retrouver lors d’une reprise.
| Famille | À sauvegarder ou documenter | Contrôle de restauration |
|---|---|---|
| Base | export SQL complet, avec les tables nécessaires | articles, réglages, commentaires et comptes présents |
| Fichiers | wp-content, configuration et code nécessaire |
thème, extensions et médias chargent |
| Contenu portable | WXR de tout le contenu, en complément | import d’essai et pièces jointes représentatives |
| Infrastructure | versions, DNS, tâches et accès | fiche disponible hors du serveur |
| Services tiers | fournisseurs, rôle et procédure de récupération | aucun appel involontaire depuis le clone |
2. Former des jeux cohérents et identifiables
Un dump de base de lundi associé à des fichiers de jeudi peut restaurer un site incohérent. Attribuez le même identifiant à la base et aux fichiers créés dans une fenêtre courte, par exemple blackfury-2026-08-24T0200Z. WordPress recommande généralement de sauvegarder d’abord la base, puis les fichiers ; la restauration suit normalement l’ordre inverse, fichiers puis import de la base.
Un manifeste associé au jeu suffit : date et fuseau, URL canonique, taille des fichiers, version de WordPress et de PHP, méthode de chiffrement, emplacement des copies et résultat du dernier test. Une somme de contrôle aide à détecter qu’un transfert a altéré un fichier ; elle ne prouve pas que la restauration fonctionnera.
3. Préserver une copie qui ne dépend pas du serveur à sauver
Le stockage de production ne peut pas être l’unique refuge. Une panne de volume, une facture d’hébergement impayée, une erreur de droits ou un ransomware peuvent rendre le site et ses sauvegardes locales indisponibles ensemble.
Une copie hors site doit être accessible avec une procédure documentée, mais elle ne doit pas devenir publiquement téléchargeable. Les exports SQL peuvent contenir des adresses e-mail, des réglages et des secrets. Chiffrez les archives contenant des données sensibles, protégez le compte distant avec une authentification forte et conservez la clé ou la phrase de récupération selon une méthode indépendante du serveur.
Le hors site ne veut pas nécessairement dire « cloud ». Un support conservé dans un autre lieu peut remplir le rôle. Le point important est l’indépendance face à l’incident envisagé : si le compte distant et le serveur partagent les mêmes identifiants, une compromission peut atteindre les deux.
4. Régler la fréquence selon la perte acceptable
La fréquence répond à une question concrète : combien de modifications peut-on perdre ? Un site mis à jour quotidiennement peut nécessiter une base quotidienne, tandis qu’un blog publié une fois par mois acceptera peut-être une autre cadence. Avant une mise à jour, une migration, une modification de thème ou une opération de base, créez un jeu supplémentaire identifié comme « avant changement ».
Les tâches automatiques sont utiles, mais WordPress conseille de les recouper ponctuellement par une sauvegarde manuelle afin de vérifier que le mécanisme fonctionne toujours. Contrôlez date, taille, journal d’exécution et présence des deux composants. Une notification « succès » ne garantit pas que le mauvais dossier n’a pas été archivé.
5. Ne pas accorder au WXR le rôle qu’il n’a pas
L’écran Outils → Exporter produit un XML WXR qui décrit du contenu et de nombreuses relations éditoriales : articles, pages, commentaires, catégories, étiquettes, champs personnalisés et auteurs selon la sélection. C’est une excellente troisième vue du patrimoine éditorial.
Mais un WXR ne contient pas de copie autonome du thème, des extensions, de la configuration du serveur ou de toutes les données de la base. Les médias y sont souvent référencés, et l’import peut dépendre de leur accessibilité au moment de l’essai. Conservez donc le WXR avec le jeu complet, sans le présenter comme la seule sauvegarde.
6. Isoler le test de restauration
Le test ne s’effectue pas sur le site public. Préparez une machine locale, une machine virtuelle, un conteneur ou une recette protégée. Utilisez une URL distincte et bloquez les e-mails, formulaires sortants, newsletters, paiements, webhooks, statistiques et indexation avant de remettre des données de production.
Sur cette cible :
- notez l’état initial et les versions employées ;
- restaurez les fichiers du jeu choisi ;
- importez la base associée dans une base dédiée ;
- adaptez la configuration du clone sans modifier l’original ;
- si l’URL change, utilisez une méthode qui respecte les données sérialisées ;
- contrôlez une page, un article, un média récent, un média ancien, un menu, la connexion et le formulaire seulement si son envoi est neutralisé ;
- consignez les erreurs et le temps nécessaire.
Un clone ne doit pas se connecter par inadvertance aux services de production. Si une extension synchronise des données, désactivez-la ou isolez ses identifiants sur la recette avant de parcourir le site.
7. Vérifier la récupération, pas seulement l’archive
Une restauration pertinente répond à trois questions : le contenu attendu est-il là, les fonctions essentielles répondent-elles et le délai est-il acceptable ? Ouvrir l’accueil ne suffit pas. Vérifiez au moins un contenu ancien et récent, une image mise en avant, un PDF ou un autre fichier, une taxonomie, un brouillon, une recherche et l’administration.
Le résultat doit être écrit, même en quelques lignes : jeu utilisé, environnement, durée, éléments validés, défauts trouvés et décision. Sans ce journal, le prochain test recommence à zéro et une erreur déjà observée peut être oubliée.
Limites et décisions à ne pas masquer
La règle 3-2-1 protège surtout contre les pertes de données ; elle ne corrige pas seule un thème vulnérable, une licence expirée, un mot de passe perdu ou une incompatibilité entre anciennes et nouvelles versions de PHP. Elle n’empêche pas non plus une archive récente de contenir une corruption déjà présente. Garder plusieurs générations répond à ce dernier risque.
Une restauration complète peut faire disparaître les commentaires, formulaires ou changements éditoriaux créés après le point de sauvegarde. Avant de restaurer une production active, il faut décider comment capturer et réconcilier cet intervalle. C’est une raison supplémentaire de tester en amont plutôt qu’au milieu d’un incident.
Enfin, aucun article ne peut deviner l’architecture précise d’un hébergeur. La procédure locale doit être complétée par les chemins, contacts, accès d’urgence et temps mesurés propres au site concerné.
Verdict
Une sauvegarde WordPress 3-2-1 crédible associe base, fichiers et documentation, les réplique dans des emplacements réellement distincts et prouve périodiquement sa restauration en environnement isolé. Le WXR complète utilement ce dispositif en préservant une lecture portable du contenu ; il ne le remplace pas.
Le test est le point qui transforme des fichiers en solution de reprise. Tant qu’aucune copie n’a recréé le site attendu sans affecter la production, on possède des archives, pas encore une sauvegarde démontrée.
Sources officielles consultées
- WordPress Developer Resources — Backups
- WordPress Developer Resources — Backing Up Your Database
- WordPress.org — écran Outils → Exporter
- WordPress Developer Resources — importer du contenu WordPress
- CISA — Data Backup Options et règle 3-2-1
