Sauvegardes WordPress 3‑2‑1: plan, tests de restauration et erreurs à éviter

Si ton site te rapporte des leads, des ventes ou des contacts, sa disponibilité n’est pas négociable. C’est là que des sauvegardes WordPress solides entrent en jeu. La stratégie 3-2-1, les tests de restauration réguliers, la sauvegarde incrémentale, l’offsite et le chiffrement ne sont pas de la théorie : ce sont des réflexes d’exploitation. Dans les 200 prochaines lignes, on va bâtir un plan clair pour protéger tes données, réduire le risque et accélérer la reprise. On parlera aussi d’automatisation (cron), de rétention, de WP-CLI backup pour industrialiser le process et de contrôles concrets pour savoir si ta restauration est vraiment réussie. Bref, comment organiser tes sauvegardes WordPress pour qu’un piratage, une erreur 500, une mise à jour ratée ou un crash serveur ne soit plus un drame, mais un simple contretemps.

Tu vas voir comment combiner plusieurs couches : une politique 3-2-1 robuste, des sauvegardes incrémentales quotidiennes, un stockage offsite chiffré, des tests de restauration sur un staging, et un plan de rétention pensé pour ton activité (blog, vitrine, WooCommerce…). Et surtout, tu sauras éviter les erreurs fréquentes qui transforment une sauvegarde « présente » en sauvegarde inutilisable. On y va.

Stratégie de sauvegardes WordPress 3‑2‑1 : le socle de ta résilience

La règle 3‑2‑1 est simple : conserve au moins 3 copies de tes données, sur 2 types de supports différents, dont 1 copie offsite. Concrètement : une archive locale sur le serveur (rapide à restaurer), une copie sur un autre support (disque externe, NAS, autre datacenter) et une copie distante (bucket S3/Backblaze B2) avec versioning et, si possible, immutabilité. Cette approche couvre la majorité des sinistres : panne disque, erreur humaine, rançongiciel, incendie, vol, suppression accidentelle.

Sur WordPress, on distingue deux jeux à sauvegarder : la base de données (contenu, utilisateurs, commandes…) et les fichiers (wp-content/uploads, plugins, thèmes, mu-plugins, wp-config.php si personnalisé). Les sauvegardes doivent être atomiques (cohérentes au même instant) pour éviter les décalages entre fichiers et base.

RPO, RTO : traduire tes objectifs en plan opérationnel

Deux indicateurs pilotent ta stratégie :

• RPO (Recovery Point Objective) : l’âge maximal des données perdues acceptable. Exemple : 1 heure pour un e‑commerce actif.
• RTO (Recovery Time Objective) : le temps de restauration cible. Exemple : 30 minutes pour remettre le site en ligne avec les fonctions essentielles.

Si ton RPO est < 1 heure, une sauvegarde incrémentale fréquente (toutes les 15–30 min sur la base de données) est nécessaire, potentiellement couplée à une réplication de médias ou un offload vers un stockage d’objets. Si ton RTO est de 30 minutes, tu dois documenter une procédure de restauration reproductible, testée, avec un chemin court vers tes archives et des scripts prêts à l’emploi.

Comprendre les types de sauvegardes : complète, incrémentale, différentielle

Tu rencontreras trois familles principales :

• Complète : une image entière du site (base + fichiers). C’est la plus simple à restaurer, mais elle consomme plus d’espace et de bande passante.
• Incrémentale : seule la différence depuis la dernière sauvegarde (complète ou incrémentale) est stockée. C’est idéal pour réduire la fenêtre RPO et les coûts de stockage.
• Différentielle : différence depuis la dernière complète uniquement. Un compromis entre simplicité de restauration et volume.

Dans la pratique, on combine souvent une complète hebdomadaire + des incrémentales quotidiennes (voire horaires sur la base de données). On applique ensuite une politique de rétention comme le schéma GFS (Grand‑Père / Père / Fils) : conservation courte des incrémentales, moyenne des hebdomadaires et longue de quelques mensuelles.

Ce qu’il faut absolument sauvegarder (et ce qu’on peut exclure)

• Indispensable : base de données MySQL/MariaDB, wp-content/uploads, wp-content/plugins, wp-content/themes, wp-config.php (et .env si utilisé), éventuels mu-plugins.
• À exclure : caches (wp-content/cache), sessions temporaires, sauvegardes internes d’extensions, logs massifs, répertoires node_modules ou vendor reconstituables.
• Cas particuliers : fichiers media offloadés vers S3/B2 (vérifier la cohérence avec la base), dossiers de stockage tiers (ex. générateurs de PDF, exports).

Outils et méthodes : plugins, scripts et WP‑CLI

Tu peux t’appuyer sur des plugins réputés (avec alerting, planification et destinations cloud), ou préférer une approche « boîte à outils » avec le serveur, WP‑CLI backup (export de base + archivage fichiers) et des scripts. L’important : l’automatisation, la vérification et la simplicité de restauration.

• WP‑CLI et shell : export de la base (wp db export), archive des fichiers (tar), signature et chiffrement (gpg), transfert (rclone vers S3/B2). Référence : commande WP‑CLI db export.
• Snapshots serveur : très rapides à prendre et restaurer, mais pas toujours portables ni offsite. À compléter avec une copie objet chiffrée.
• Plugins de sauvegarde : pratique pour débuter, vérifie la compatibilité multisite, l’incrémental, l’immutabilité et la restauration partielle.

Stockage offsite, chiffrement et immutabilité : tes filets de sécurité

Une sauvegarde sur le même serveur ne te protège pas contre un incident majeur. Le pilier de la 3‑2‑1, c’est l’offsite : un bucket S3 ou Backblaze B2 avec versioning et, si possible, Object Lock (immutabilité) pour contrer la suppression malveillante. Pour la culture, l’historique et l’intérêt de la règle, lis l’explication claire de Backblaze : stratégie 3‑2‑1 de sauvegarde.

Chiffrement : protéger les archives en transit et au repos

• Au repos : chiffre les archives avant l’envoi (ex. gpg --symmetric --cipher-algo AES256) ou utilise du server‑side encryption (SSE‑S3/SSE‑KMS) avec gestion de clés.
• En transit : impose TLS (HTTPS) pour les transferts. Évite FTP non sécurisé, préfère SFTP/SSH.
• Gestion des clés : stocke la clé de chiffrement hors du serveur (gestionnaire de secrets), avec une procédure de rotation et un accès restreint.

Planification, rétention et supervision qui inspirent confiance

Une sauvegarde qui n’est pas planifiée et surveillée n’existe pas. Mets en place :

• Planification : hebdo complète + incrémentales quotidiennes (voire horaires BD). Préfère un cron système à WP‑Cron pour la fiabilité.
• Rétention : GFS (7 incrémentales quotidiennes, 4 hebdomadaires, 6 mensuelles), à adapter à tes contraintes légales et budgétaires.
• Supervision : réception d’alertes (succès/échec), dashboard de volumétrie, vérification de l’âge de la dernière bonne sauvegarde, tests de checksum (SHA‑256) après transfert.
• Journalisation : logs d’exécution, durée, taille d’archives, taux de compression, code de retour, identifiant d’archive stocké.

Tester la restauration : la seule preuve que tes sauvegardes valent quelque chose

Un plan sans tests, c’est de la chance. Organise un jeu d’essai de restauration chaque mois (ou après un gros changement), sur un staging isolé. Objectifs : valider l’intégrité des données, mesurer le RTO, vérifier les parcours clés (connexion, panier, paiement test, formulaire, SEO de base) et documenter les étapes.

Procédure de test recommandée

1. Crée un sous‑domaine sécurisé (staging.exemple.com) et une base vide.
2. Récupère la dernière complète + les incrémentales nécessaires.
3. Restaure les fichiers (uploads, thèmes, plugins) puis la base.
4. Exécute une recherche/remplacement des URLs (wp search-replace) pour pointer vers le staging.
5. Vide les caches, régénère les permaliens (wp rewrite flush --hard), désactive les intégrations externes sensibles (paiement, emails marketing) pour éviter les envois réels.
6. Contrôle l’admin, les pages critiques et le front. Note les écarts.
7. Chronomètre l’ensemble : tu tiens ton RTO réel. Ajuste le plan si nécessaire.

Restauration d’urgence pas à pas (exemple scriptable)

Voici un canevas basé sur WP‑CLI backup (export/base + archive/fichiers) et des outils standard :

# 1) Stopper le trafic si nécessaire (maintenance)wp maintenance-mode activate# 2) Récupérer l'archive la plus récente (ex. via rclone depuis S3/B2)rclone copy remote:wp-site/backups/2025-02-01_full.tar.gz.gpg /restore/rclone copy remote:wp-site/backups/2025-02-02_inc.sql.gpg /restore/# 3) Déchiffrer et vérifier l'intégritégpg --output /restore/full.tar.gz --decrypt /restore/2025-02-01_full.tar.gz.gpgecho "<sha256 attendu>  /restore/full.tar.gz" | sha256sum -c -# 4) Extraire fichiers et replacer droitsmkdir -p /var/www/htmlsudo tar -xzf /restore/full.tar.gz -C /var/www/htmlsudo chown -R www-data:www-data /var/www/html# 5) Restaurer la base de donnéeswp db reset --yeswp db import /restore/2025-02-02_inc.sql# 6) Corrections d'URL (si domaine temporaire)wp search-replace "https://www.exemple.com" "https://tmp.exemple.com" --all-tables# 7) Finalisationwp cache flushwp maintenance-mode deactivate

Ce squelette doit être adapté à ta structure d’archives, ta politique de chiffrement et ton hébergement. Le but est d’industrialiser : moins d’actions manuelles, moins d’erreurs sous stress.

Erreurs courantes qui ruinent une bonne stratégie

• Stocker toutes les copies au même endroit : un incendie ou une compromission et tu perds tout. Respecte la 3‑2‑1, coûte que coûte.
• Ne pas tester la restauration : une archive corrompue ou incomplète ne se révèle… qu’au pire moment.
• Oublier le chiffrement : une sauvegarde non chiffrée, c’est un fichier plein de données sensibles en clair.
• Ignorer la rétention : sans politique, tu paies trop de stockage ou tu manques d’historique utile.
• Sauvegarder les caches : archives plus lourdes, restauration plus lente, aucun bénéfice.
• Conserver les clés de chiffrement sur le même serveur : un attaquant déchiffre tout.
• Sous‑dimensionner la fenêtre de sauvegarde : tâches qui chevauchent le pic de trafic, timeouts, incrémentales incomplètes.
• Oublier les dépendances externes : DNS, CDN, stockage déporté (offload médias), jobs workers, clés API. Sans elles, la restauration paraît “réussie” mais le site ne fonctionne pas réellement.
• Négliger le multisite : assure‑toi que ton outil gère bien la topologie, les tables wp_*_ multiples et la restauration sélective d’un site.
• Pas de procédure écrite : le jour J, tu perds du temps sur des évidences (accès S3, comptes, mots de passe…).

Cas particuliers et astuces avancées

WooCommerce et sites transactionnels

• RPO serré : vise des sauvegardes BD toutes les 15 minutes (incrémentales) et des points de cohérence avant/après les pics de commandes.
• Binlogs : active les journaux binaires MySQL/MariaDB pour un point‑in‑time recovery fin entre deux sauvegardes.
• Sessions et files d’attente : documente la restauration de Redis/RabbitMQ si utilisé (AOF/snapshots), ou reconfigure la session PHP.

Multisite WordPress

• Vérifie que ton outil prend en charge la topologie de tables et la restauration d’un sous‑site isolé.
• Anticipe la réécriture des URLs par sous‑site et les mappages de domaines.

Volumes médias massifs

• Déporte uploads vers un stockage d’objets (S3/B2) avec CDN. Ta sauvegarde se concentre sur la base et les métadonnées.
• Active le lifecycle pour archiver/expirer les versions anciennes et maîtriser la facture.

Mettre en musique : exemple de politique de sauvegarde prête à adapter

Voici un modèle concis que tu peux intégrer dans ton runbook.

• Périmètre : base MySQL + wp-content + wp-config.php + clés de licences et secrets hors serveur.
• Méthode : complète hebdomadaire (dimanche 02:00 UTC) + incrémentale quotidienne (02:00 UTC) + BD horaire pour e‑commerce.
• Stockage : local chiffré (7 jours), NAS (14 jours), offsite S3/B2 (90 jours) avec versioning + Object Lock 7 jours.
• Chiffrement : GPG AES‑256 côté client, clés en coffre‑fort de secrets.
• Rétention : GFS (7 quotidiennes / 4 hebdo / 6 mensuelles), purge automatisée.
• Tests : restauration mensuelle sur staging, rapport (RTO mesuré, anomalies, actions).
• Supervision : alertes Slack/Email, tableau de bord volumétrie, contrôle checksum post‑upload.
• Rôles : un responsable sauvegardes, un suppléant, accès d’urgence scellé.
• Déclencheur d’urgence : erreurs 500 persistantes, hack confirmé, corruption BD, échec de mises à jour majeures.

Aller plus loin sans complexifier : bonnes pratiques de production

• Automatise les sauvegardes et documente la restauration. Rien ne doit dépendre d’une seule personne.
• Standardise les noms d’archives : YYYY-MM-DD_type_site.tar.gz.gpg.
• Vérifie aussi la restauration partielle : uniquement la base, ou un thème, ou un dossier uploads d’une période.
• Sépare les secrets d’environnement de l’archive (fichiers .env, clés API) et stocke-les à part.
• Mesure et améliore : suis le RTO/RPO réels, ajuste fréquences et rétention.

Pourquoi cette approche « pro » change réellement la donne

Une vraie stratégie 3‑2‑1, chiffrée, avec incrémentales et tests de restauration réels, transforme un incident en aléa gérable. Tu sais quoi restaurer, où le trouver, comment le faire, et en combien de temps. C’est de la sérénité en production.

Et si tu manques de temps pour tout mettre en place, documenter, automatiser et superviser, confie‑nous l’implémentation. Chez WP Builders, on vit au quotidien la maintenance, le support et la reprise après incident WordPress. On standardise, on teste, et on garantit des délais d’intervention clairs. Résultat : un site fiable, des sauvegardes utiles et une restauration maîtrisée, sans t’arracher les cheveux.