Une sauvegarde WordPress ne vaut que par sa capacité à restaurer le site : tout le reste est du stockage. La règle 3-2-1 — trois copies des données, sur deux supports différents, dont une hors site — structure une stratégie de backup WordPress qui survit au piratage, à l'erreur humaine et à la panne matérielle. Ce guide l'applique pas à pas : quoi sauvegarder (fichiers et base de données), où placer chaque copie (hébergeur, plugin, export distant), quelle rétention retenir selon le type de site, et comment prouver que la restauration fonctionne avant d'en avoir besoin. La méthode se met en place en une heure et se vérifie chaque trimestre, quel que soit l'hébergeur.
À retenir
- Règle 3-2-1 : 3 copies des données, 2 supports différents, 1 copie hors site. La sauvegarde de l'hébergeur seule ne fournit que les deux premières copies.
- Un site WordPress se sauvegarde en deux blocs indissociables : les fichiers (
wp-content,wp-config.php) et la base de données (mysqldump).- Chez Tomco : sauvegardes journalières automatiques, rétention 90 jours, restauration granulaire en 1 clic, snapshots ZFS sur un nœud Proxmox Backup Server isolé du parc de production.
- Une sauvegarde non testée n'est pas une sauvegarde : test de restauration sur staging au moins une fois par trimestre, chronomètre en main.
- RPO/RTO à calibrer : 24 h de perte acceptable pour une vitrine, 1 h ou moins pour un e-commerce.
Sommaire
- Pourquoi une sauvegarde WordPress par défaut ne suffit pas
- La règle 3-2-1 appliquée à WordPress
- Fichiers et base de données : les deux composants à sauvegarder
- Sauvegarde côté hébergeur : automatique, mais dans le même panier
- Sauvegarde indépendante : plugins et export distant
- Rétention, RPO et RTO : calibrer selon le type de site
- Tester une restauration : la seule preuve qui compte
- Questions fréquentes
La stratégie 3-2-1 pour WordPress en un coup d'œil
| Copie | Rôle | Support | Localisation | Outil type |
|---|---|---|---|---|
| 1 — Production | Données vivantes | SSD NVMe du serveur web | Datacenter de l'hébergeur | WordPress lui-même |
| 2 — Sauvegarde hébergeur | Restauration rapide (RTO court) | Stockage de sauvegarde séparé | Même infrastructure | Enhance Panel : journalière, 90 jours chez Tomco |
| 3 — Copie hors site | Survie au scénario catastrophe | NAS, stockage objet, machine tierce | Hors du datacenter | UpdraftPlus, export FTP, rclone |
Pourquoi une sauvegarde WordPress par défaut ne suffit pas
La configuration la plus répandue — une seule copie des données, ou une production doublée de la seule sauvegarde automatique de l'hébergeur — échoue face à quatre scénarios précis, parce que la copie de secours partage le sort de l'original. C'est le défaut structurel que la règle 3-2-1 corrige.
Le panier unique. Quand la production et sa sauvegarde vivent chez le même prestataire, une défaillance de ce prestataire emporte les deux. L'incendie du datacenter de Strasbourg du 10 mars 2021 l'a démontré à grande échelle : des milliers de clients dont les sauvegardes résidaient dans le même bâtiment que la production ont tout perdu en une nuit. Le risque n'est pas que matériel : un compte suspendu pour impayé ou une résiliation mal synchronisée produisent le même effet.
La corruption propagée. Un site compromis continue d'être sauvegardé. Une backdoor peut rester dormante plusieurs semaines avant activation : avec une rétention de 7 jours, toutes les copies disponibles contiennent déjà l'infection au moment où elle se déclare. La profondeur d'historique est une dimension de sécurité à part entière, pas un confort.
Le rançongiciel. Un ransomware chiffre tout ce que le serveur peut écrire — y compris les archives de sauvegarde stockées localement dans wp-content. Une copie accessible en écriture depuis la machine compromise n'est pas une protection, c'est une victime supplémentaire.
L'erreur humaine. Suppression d'un répertoire en SFTP, DROP TABLE sur la mauvaise base, mise à jour d'extension qui corrompt les données : la cause de restauration la plus fréquente ne vient pas des attaquants mais des opérateurs légitimes.
La sauvegarde arrive en dernière position des mesures du guide sécuriser WordPress en 2026 pour une raison simple : elle n'empêche rien. C'est la seule mesure qui fonctionne après l'incident, quand toutes les autres ont été contournées.
La règle 3-2-1 appliquée à WordPress
La règle 3-2-1 impose trois exigences : trois copies des données (production comprise), stockées sur deux supports distincts, dont une copie hors site. Formalisée par le photographe Peter Krogh en 2005 pour l'archivage numérique, elle est depuis reprise comme référence par les agences de cybersécurité, dont la CISA américaine. Sa force tient à une propriété simple : aucune défaillance unique — matérielle, logicielle, organisationnelle — ne peut atteindre les trois copies simultanément.
Appliquée à WordPress, la règle se traduit copie par copie :
- Copie 1 — la production. Le site vivant, sur le SSD NVMe du serveur web. Elle compte dans les trois copies mais ne protège de rien.
- Copie 2 — la sauvegarde de l'hébergeur. Automatique, stockée sur un support distinct du serveur de production. C'est elle qui assure la restauration rapide au quotidien.
- Copie 3 — l'export hors site. Une archive complète (fichiers + base) expédiée hors de l'infrastructure de l'hébergeur : NAS de bureau, stockage objet d'un autre fournisseur, machine tierce. C'est la copie de survie, et elle relève toujours de votre responsabilité.
La documentation officielle WordPress pose la même base : plusieurs copies, sur des supports différents, pour qu'aucun événement isolé ne puisse toutes les détruire. Le point que les administrateurs négligent n'est pas le nombre de copies — c'est l'indépendance entre elles. Deux archives sur le même serveur comptent pour une seule copie.
Fichiers et base de données : les deux composants à sauvegarder
Un site WordPress complet se restaure à partir de deux blocs, et une sauvegarde qui n'en embarque qu'un seul ne permet pas de remonter le site. Les fichiers sans la base donnent une coquille vide ; la base sans les fichiers donne des contenus sans thème, sans médias et sans configuration.
| Composant | Contenu | Outil d'export | Poids typique |
|---|---|---|---|
| Fichiers | wp-content (thèmes, extensions, médias), wp-config.php, .htaccess |
tar, SFTP, plugin | 500 Mo à 20 Go (médias dominants) |
| Base de données | Articles, pages, comptes, réglages, commandes | mysqldump, plugin, phpMyAdmin | 50 Mo à 2 Go |
Les fichiers. Le cœur de WordPress se retélécharge depuis wordpress.org et n'a pas besoin d'être archivé. L'irremplaçable se concentre dans wp-content/ — thèmes (enfant compris), extensions, répertoire uploads/ qui représente l'essentiel du poids — plus wp-config.php (identifiants de base, clés de salage) et .htaccess (réécritures, durcissements).
La base de données. Elle contient tout ce qui fait le site : contenus, comptes utilisateurs, réglages, commentaires, et pour un e-commerce les commandes et les clients. L'export de référence reste mysqldump, exécutable en SSH ou planifiable en cron.
# Fichiers — n'archiver que ce qui ne se retélécharge pas
tar -czf site-$(date +%F).tar.gz wp-content/ wp-config.php .htaccess
# Base de données — export cohérent sans verrouiller les tables (InnoDB)
mysqldump --single-transaction --quick -u utilisateur -p nom_base \
| gzip > db-$(date +%F).sql.gz
Les deux exports doivent être capturés au même moment : une extension présente dans les fichiers mais absente des tables d'options (ou l'inverse) produit une restauration incohérente. Le guide de sauvegarde du handbook WordPress détaille les répertoires et les tables concernés, ainsi que les variantes d'export par phpMyAdmin.
Sauvegarde côté hébergeur : automatique, mais dans le même panier
La sauvegarde de l'hébergeur est la copie n° 2 de la stratégie : automatique, sans configuration, avec le RTO le plus court — c'est elle qu'on utilise dans 95 % des restaurations réelles, celles qui suivent une erreur de manipulation ou une mise à jour ratée.
Sur l'hébergement web Tomco, Enhance Panel exécute une sauvegarde journalière automatique de chaque compte, conservée 90 jours. La restauration se fait en 1 clic depuis l'espace client et elle est granulaire : un fichier isolé, une base de données seule, ou le compte entier. Pas besoin de restaurer 15 Go de médias pour récupérer un wp-config.php écrasé.
Côté infrastructure, ces sauvegardes sont stockées sous forme de snapshots ZFS sur un nœud Proxmox Backup Server dédié, physiquement indépendant du parc de production. Une panne matérielle, une corruption de volume ou une compromission d'un nœud de production ne peuvent pas atteindre les sauvegardes : les deux supports de la règle 3-2-1 sont assurés nativement. Le détail de cette architecture est décrit sur la page technologies.
La limite n'est pas technique, elle est organisationnelle : production et sauvegarde dépendent du même prestataire. Un compte suspendu, une résiliation, une défaillance de l'hébergeur lui-même touchent les deux copies en même temps. Les CGV de la quasi-totalité des hébergeurs — Tomco compris — fournissent d'ailleurs ces sauvegardes à titre de courtoisie, sans garantie contractuelle. Conclusion opérationnelle : la sauvegarde hébergeur est nécessaire, confortable, rapide — et insuffisante seule. Il lui manque le « 1 hors site ».
Sauvegarde indépendante : plugins et export distant
La sauvegarde indépendante est la copie n° 3 : créée par vos soins, stockée hors de l'infrastructure de l'hébergeur, sous votre contrôle exclusif. Deux approches se complètent.
Par plugin, en push. UpdraftPlus (version gratuite suffisante dans la majorité des cas) ou BackWPup planifient des sauvegardes complètes — fichiers et base — vers une destination distante : stockage objet S3, Google Drive, Dropbox, ou un serveur FTP tiers. Le réglage qui change tout : la destination. Un plugin de sauvegarde WordPress configuré pour écrire dans wp-content/updraft sans envoi distant produit une archive qui disparaîtra avec le site. La destination distante est ce qui transforme une copie locale en vraie copie hors site.
Par export FTP/SSH, en pull. L'approche la plus robuste inverse le sens du transfert : une machine extérieure (NAS de bureau, VPS tiers) vient chercher les archives sur le serveur d'hébergement. Le serveur de production ne détient aucun identifiant vers le stockage de sauvegarde — un attaquant qui le compromet ne peut donc ni lire ni effacer les copies distantes. Les offres Tomco exposent l'accès FTP (toutes formules) et SSH pour automatiser cet export, qui constitue le « 1 hors site » de la règle 3-2-1. Avec rclone, l'opération tient en une commande planifiée :
#!/bin/sh
# À planifier sur la machine de destination (NAS, VPS tiers) — mode pull
rclone sync sftp-tomco:/home/compte/backups/ /backups/monsite/ \
--backup-dir /backups/monsite-historique/$(date +%F)
La fréquence se calque sur le rythme de modification du site : pour une vitrine, un export distant hebdomadaire des fichiers et quotidien de la base couvre le besoin ; pour un e-commerce, l'export de base passe à l'heure et les fichiers au quotidien. Dans tous les cas, l'export distant complète la sauvegarde hébergeur, il ne la remplace pas : le RTO d'une restauration depuis un NAS résidentiel se compte en heures là où la restauration Enhance Panel se compte en minutes.
Rétention, RPO et RTO : calibrer selon le type de site
Trois paramètres dimensionnent une stratégie de sauvegarde, et ils se définissent en une phrase chacun :
- RPO (Recovery Point Objective) : l'âge maximal acceptable de la dernière sauvegarde — autrement dit, la quantité de données que vous acceptez de perdre.
- RTO (Recovery Time Objective) : la durée maximale acceptable d'indisponibilité — le temps que la restauration a le droit de prendre.
- Rétention : la profondeur d'historique conservée — jusqu'où dans le passé vous pouvez remonter.
| Paramètre | Site vitrine | E-commerce / site à contributions |
|---|---|---|
| RPO cible | 24 h (perdre une journée de modifications est acceptable) | ≤ 1 h sur la base (commandes, comptes clients) |
| RTO cible | ≤ 4 h | ≤ 1 h |
| Fréquence fichiers | Hebdomadaire | Quotidienne |
| Fréquence base de données | Quotidienne | Horaire |
| Rétention recommandée | 30 à 90 jours | 90 jours + archives mensuelles sur 1 an |
La rétention mérite plus d'attention qu'elle n'en reçoit. Le réflexe est de la dimensionner pour l'erreur d'hier ; le vrai dimensionnant est la compromission découverte tardivement. Une backdoor dormante pendant six semaines impose de pouvoir remonter au-delà de ces six semaines avec une copie saine — c'est la justification des 90 jours de rétention de la sauvegarde Tomco.
Sur le RTO, un ordre de grandeur constaté en production vaut mieux qu'une promesse : cas réel (anonymisé) traité par le support Tomco — un vendredi en fin d'après-midi, la mise à jour d'une extension corrompt les tables de commandes d'une boutique WooCommerce. Restauration granulaire de la seule base de données depuis la sauvegarde de la nuit précédente, via ticket support : 22 minutes entre l'ouverture du ticket et la remise en ligne, fichiers intacts non touchés. En ordre de grandeur : moins de 30 minutes pour une restauration granulaire, une à deux heures pour un compte entier de plusieurs dizaines de gigaoctets.
Sur un serveur dédié, le raisonnement reste identique mais aucune copie n'existe par défaut : la chaîne 3-2-1 complète — sauvegardes, supports, export hors site, snapshots de l'hyperviseur — relève de l'administrateur.
Tester une restauration : la seule preuve qui compte
Une sauvegarde non testée n'est pas une sauvegarde : c'est une hypothèse. Les archives peuvent être tronquées, chiffrées avec une clé perdue, incomplètes (base sans fichiers), ou simplement jamais vérifiées depuis un changement d'extension qui a modifié la structure des tables. Le test de restauration trimestriel répond aux trois seules questions qui comptent : les archives sont-elles exploitables, la procédure est-elle maîtrisée, et le RTO réel est-il compatible avec le RTO cible.
Étape 1 — Préparer l'environnement de staging
Créer un sous-domaine isolé (staging.exemple.fr) avec son propre répertoire et sa propre base de données vide. Le bloquer à l'indexation — authentification HTTP ou noindex — pour éviter qu'un moteur ne découvre un doublon complet du site. Ne jamais tester une restauration sur la production : un test qui échoue y deviendrait l'incident qu'il était censé prévenir.
Étape 2 — Restaurer les fichiers
Décompresser l'archive dans le répertoire de staging, puis adapter wp-config.php : nom de la base de staging, identifiants dédiés, préfixe de tables. C'est ici que se révèlent les archives incomplètes — un wp-config.php manquant ou un uploads/ partiel se voient immédiatement.
Étape 3 — Importer la base de données
gunzip < db-2026-06-12.sql.gz | mysql -u staging_user -p staging_dbL'import doit se terminer sans erreur. Un fichier tronqué échoue ici — mieux vaut le découvrir un mardi matin de test qu'un dimanche de crise.
Étape 4 — Réécrire les URL
WordPress stocke l'URL du site dans la base, y compris dans des données sérialisées qu'un UPDATE SQL brut corromprait. wp search-replace (WP-CLI) gère la sérialisation :
wp search-replace 'https://exemple.fr' 'https://staging.exemple.fr' \
--all-tables --preciseÉtape 5 — Dérouler la checklist de validation
□ Page d'accueil et 5 pages clés rendues sans erreur
□ Connexion wp-admin fonctionnelle
□ Médias affichés (uploads restaurés, chemins corrects)
□ Formulaire de contact / commande test passés de bout en bout
□ Aucune erreur PHP dans les logs après 15 minutes de navigation
□ Durée totale de l'opération chronométrée et notéeLa durée chronométrée est votre RTO réel. S'il dépasse le RTO cible défini plus haut, la réponse n'est pas de chronométrer plus vite : restauration hébergeur en première intention (minutes), copie hors site en second recours (heures), et procédure écrite pour ne pas la redécouvrir sous pression. Consigner la date du test et son résultat — la prochaine échéance est dans trois mois.
