Sauvegardes WordPress qui se restaurent vraiment

La sauvegarde WordPress type échoue au moment précis où on en a besoin. Un plugin écrit une archive zip dans wp-content, dans le même compte d'hébergement que le site. Si un attaquant, un rançongiciel ou une suspension de compte emporte le site, cette copie disparaît avec lui.

Une sauvegarde n'a de valeur que si vous pouvez restaurer à partir d'elle. Ce guide explique quoi inclure, où conserver les copies, à quelle fréquence les réaliser, comment tester une restauration et comment choisir un point de restauration sain après un piratage.

Ce que doit contenir une sauvegarde WordPress : fichiers et base de données

Un site WordPress a deux moitiés, et il vous faut les deux. La base de données contient les articles, les pages, les utilisateurs et leurs empreintes de mots de passe, les réglages, les commandes WooCommerce et les entrées de formulaires. Prenez un plugin de formulaire de contact qui enregistre les messages en base : une sauvegarde limitée aux fichiers perd toutes les demandes reçues, et une sauvegarde limitée à la base restitue les messages sans plugin pour les lire.

Côté fichiers, il faut wp-content (médias, plugins, thèmes), wp-config.php et .htaccess ou la configuration de votre serveur. Le noyau de WordPress peut être retéléchargé, à condition de savoir quelle version vous utilisiez.

Depuis la racine de WordPress, avec WP-CLI :

# Export de la base, écrit en dehors de la racine web
mkdir -p ~/backups
wp db export ~/backups/db-$(date +%F).sql

# Fichiers : wp-content, wp-config.php et .htaccess (sans les caches ni les anciens dossiers de sauvegarde)
tar --exclude='wp-content/cache' \
    --exclude='wp-content/backups' \
    -czf ~/backups/files-$(date +%F).tar.gz \
    wp-content wp-config.php .htaccess

# Noter les versions pour pouvoir réinstaller le noyau, les plugins et les thèmes depuis les sources officielles
wp core version > ~/backups/versions-$(date +%F).txt
wp plugin list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt
wp theme list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt

Remplacez wp-content/backups par le dossier qu'utilise votre plugin de sauvegarde. Sous nginx, il n'y a pas de .htaccess : retirez-le de la commande et sauvegardez plutôt la configuration du serveur. Des sauvegardes enfouies dans les sauvegardes font gonfler chaque archive. Les commandes WP-CLI db sont documentées sur WordPress.org.

La règle 3-2-1 : pourquoi une copie dans votre compte d'hébergement ne compte pas

La règle : trois copies de vos données, sur deux types de supports différents, dont une hors site. Votre site en ligne compte pour une copie. Une sauvegarde dans le même compte d'hébergement fait la deuxième, mais elle partage les mêmes identifiants, le même serveur et le même prestataire que le site.

Quiconque peut écrire sur votre site peut généralement supprimer cette copie. Un rançongiciel qui chiffre la racine web chiffre aussi l'archive zip posée à côté. Un compte suspendu ou une panne de l'hébergeur emporte les deux d'un coup. Les instantanés de l'hébergeur sont utiles et rapides à restaurer, mais ils restent une copie unique que vous ne maîtrisez pas.

C'est la troisième copie qui compte. Elle doit partir vers un stockage chez un autre prestataire, avec des identifiants distincts qui ne sont pas conservés sur le serveur web sous une forme permettant la suppression. Deux réglages font une grande différence :

• Versionnage ou immuabilité. De nombreux services de stockage objet proposent le versionnage, le verrouillage d'objets (object lock) ou un verrou de rétention côté prestataire. Le versionnage conserve les anciennes copies, mais quiconque dispose des droits de suppression peut encore les effacer. Un verrou en mode le plus strict (mode « compliance ») empêche tout le monde, vous compris, de supprimer ou d'écraser une sauvegarde avant la fin de la période.
• Identifiants en écriture seule pour la tâche de sauvegarde. Si la clé présente sur le serveur ne permet que d'envoyer des fichiers, et que le versionnage ou un verrou conserve les anciennes copies, un attaquant qui la vole ne peut ni effacer ni écraser votre historique.

Fréquence des sauvegardes et durée de conservation

Calez la fréquence sur la vitesse à laquelle vos données changent. Un site vitrine modifié une fois par mois s'accommode de sauvegardes hebdomadaires. Une boutique qui reçoit des commandes tous les jours a besoin de sauvegardes de la base au moins quotidiennes, souvent plus fréquentes. Les fichiers changent en général moins souvent que la base : ils peuvent suivre un calendrier distinct.

La durée de conservation est un compromis. Les compromissions sont souvent découvertes des semaines après leur début. Si vous ne gardez que sept jours de copies, chacune peut déjà contenir la porte dérobée. À l'inverse, les anciennes sauvegardes font survivre des données personnelles, y compris celles de comptes que des utilisateurs vous ont demandé de supprimer.

Fixez une fenêtre de conservation et une rotation, par exemple des copies quotidiennes pendant quelques semaines, plus des copies mensuelles pendant une durée limitée. Mettez-la par écrit. Ce calendrier documenté aide aussi pour les demandes d'effacement : les données disparaissent des sauvegardes à l'expiration des copies, et d'ici là vous veillez à ce qu'elles ne soient ni restaurées ni utilisées. Réécrire les archives à chaque demande est rarement réaliste ; consultez les recommandations de votre autorité de contrôle (la CNIL en France) sur les sauvegardes.

Les sauvegardes contiennent des données personnelles : chiffrement, accès et contrats

Une sauvegarde WordPress contient des comptes utilisateurs, des empreintes de mots de passe, des données de clients et de commandes, ainsi que des entrées de formulaires. La perdre est aussi grave que perdre la base en production.

• Chiffrez en transit et au repos. Le chiffrement fait partie des mesures citées à l'art. 32, paragraphe 1, point a), du RGPD. Conservez la clé ailleurs que sur le stockage qu'elle protège.
• Limitez les accès. Seules les personnes qui restaurent les sites doivent pouvoir télécharger les sauvegardes. Supprimez les anciens liens de téléchargement partagés et les comptes utilisateurs périmés sur le stockage.
• Signez des contrats. Un prestataire de stockage de sauvegardes, ou une agence qui conserve des copies, est un sous-traitant au sens de l'art. 28 et exige un contrat de sous-traitance (accord sur le traitement des données).

Une sauvegarde non chiffrée, perdue ou accessible publiquement, peut constituer à elle seule une violation de données à caractère personnel. Dans ce cas, consultez le guide sur la notification sous 72 heures.

Testez une restauration avant d'en avoir besoin

Restaurez sur un site de préproduction ou une copie locale, jamais par-dessus le site en ligne. Utilisez la copie externe, pas la copie locale pratique, car c'est la copie externe qui vous restera après un véritable incident.

# Dans une racine web vide sur la préproduction ; WP_VERSION provient de votre fichier de versions
wp core download --version="$WP_VERSION" --skip-content
tar -xzf files-2026-10-23.tar.gz
# Modifier wp-config.php : identifiants de la base de préproduction, puis :
wp db import db-2026-10-23.sql
wp search-replace 'https://www.example.com' 'https://staging.example.com' --skip-columns=guid
wp option update blog_public 0

blog_public 0 demande seulement aux moteurs de recherche de ne pas passer. Placez aussi la préproduction derrière une authentification HTTP. Empêchez-la d'envoyer des e-mails à de vrais clients ou d'appeler des webhooks de paiement, et pensez à define( 'DISABLE_WP_CRON', true ); pendant vos tests.

Vérifiez ensuite :

• La connexion à l'administration fonctionne
• L'envoi d'un formulaire aboutit
• La commande ou l'article le plus récent est présent
• Les images et les téléchargements se chargent
• La liste des plugins et leurs versions correspondent à votre relevé
• Le temps total entre le départ et le site opérationnel est noté

Ce temps est votre délai de reprise réel, souvent plus long qu'on ne le croit. Consignez la date, la sauvegarde utilisée, le résultat et les problèmes rencontrés. Une sauvegarde jamais restaurée ne prouve rien, ni à vous, ni à quiconque vous demande comment vous satisfaites à l'art. 32, paragraphe 1, points c) et d), ou à l'obligation de responsabilité de l'art. 5, paragraphe 2.

Restaurer après un piratage : retrouver le dernier point sain

Ne restaurez pas aveuglément la sauvegarde la plus récente : elle contient probablement la porte dérobée. La plus ancienne est peut-être saine, mais il lui manque des semaines de commandes. Avant de modifier quoi que ce soit, conservez une copie de l'état infecté pour pouvoir enquêter plus tard.

Estimez ensuite la date du début de la compromission. Examinez les journaux du serveur et d'accès, les dates de modification des fichiers, les administrateurs que vous ne reconnaissez pas, ainsi que les fichiers qui diffèrent d'une sauvegarde plus ancienne. Choisissez alors une sauvegarde antérieure à cette date. Une référence d'intégrité des fichiers aide ici : le plugin Security Audit & Compliance en enregistre une et signale les fichiers modifiés et les indicateurs de compromission, ce qui permet de cerner le moment des changements. Il ne réalise ni ne restaure de sauvegardes.

Plutôt qu'une restauration complète, mieux vaut procéder ainsi :

1. Réinstallez le noyau, les plugins et les thèmes depuis les sources officielles, dans des versions connues.
2. Ne reprenez que les médias et la base du point sain. Vérifiez qu'il n'y a pas de fichiers PHP dans les médias (comment trouver des web shells dans uploads).
3. Contrôlez la base : administrateurs injectés (wp user list --role=administrator) et contenu de spam.
4. Ressaisissez ou migrez les commandes et données créées depuis ce point.

Une restauration ne referme pas la faille. Avant la remise en ligne, mettez à jour ou supprimez le composant vulnérable, et changez tous les mots de passe, clés et salts. Sinon, vous serez piraté à nouveau par le même chemin. La procédure complète figure dans notre plan de nettoyage d'un site infecté, et la vérification des sommes de contrôle du noyau confirme que le noyau est sain.

Ce que le RGPD et NIS 2 attendent de vos sauvegardes

L'art. 5, paragraphe 1, point f), du RGPD exige une sécurité appropriée, y compris l'intégrité et la confidentialité. L'art. 32, paragraphe 1, point c), demande la capacité de rétablir la disponibilité des données à caractère personnel et l'accès à celles-ci dans des délais appropriés en cas d'incident, et le point d) demande de tester régulièrement vos mesures. Perdre des données clients sans moyen de les restaurer peut constituer une violation de la disponibilité.

Pour les entités relevant du droit national, la directive NIS 2 cite à l'art. 21, paragraphe 2, point c), la continuité des activités, notamment la gestion des sauvegardes et la reprise après sinistre. Même si NIS 2 ne vous concerne pas, vos clients soumis à NIS 2 peuvent vous demander, en tant que fournisseur ou agence, des preuves. Notre aperçu de l'article 32 du RGPD donne le tableau d'ensemble.

Tenez une fiche d'une page sur vos sauvegardes : ce qui est sauvegardé, où, à quelle fréquence, la fenêtre de conservation, le chiffrement, qui a accès, ainsi que la date et le résultat du dernier test de restauration. Votre prochaine étape : planifier cette semaine un premier test de restauration, à partir de la copie externe.

FAQ

La sauvegarde quotidienne de mon hébergeur suffit-elle ?

En général non, pas à elle seule. C'est une copie unique, stockée chez le même prestataire, souvent conservée peu de temps. Vérifiez la durée de conservation et ajoutez une copie externe que vous contrôlez.

Dois-je sauvegarder le noyau de WordPress ?

Ce n'est pas nécessaire si vous consignez les versions du noyau, des plugins et des thèmes. Une réinstallation depuis WordPress.org vous donne en plus des fichiers de noyau réputés sains.

Comment traiter une demande d'effacement quand les données de la personne figurent dans des sauvegardes ?

Supprimez les données du site en ligne et appuyez-vous sur votre fenêtre de conservation documentée pour les sauvegardes. Si vous devez restaurer un jour, veillez à ne pas remettre les données de cette personne sur le site en ligne.

À quelle fréquence tester une restauration ?

Régulièrement, et toujours après un changement important d'hébergement, de site ou d'outil de sauvegarde. Choisissez un intervalle que vous tiendrez réellement et consignez chaque test.

Cet article est une information générale et ne constitue pas un conseil juridique.