0498 70 98 60Sauvegarde WordPress : une stratégie qui permet vraiment de restaurer
Presque tous les sites WordPress ont une sauvegarde. Peu ont une sauvegarde qui fonctionne le jour où il faut s’en servir. Après un piratage, on découvre souvent qu’elle est infectée, incomplète ou stockée sur le serveur compromis.
Une sauvegarde WordPress utile répond à trois questions simples. Où se trouve-t-elle ? Remonte-t-elle assez loin dans le temps ? A-t-elle déjà été restaurée avec succès ? Si vous hésitez sur l’une d’elles, ce guide est pour vous.
Nous y présentons la règle 3-2-1, la rétention adaptée au risque de piratage et la méthode pour tester une restauration. Les recommandations s’appuient sur les publications de la CNIL et de l’ANSSI, références techniques reconnues en Europe. En Suisse, la LPD impose une sécurité adéquate des données (article 8), et l’Office fédéral de la cybersécurité (OFCS) recommande lui aussi des sauvegardes régulières, déconnectées du réseau après usage.
Une bonne stratégie de sauvegarde commence par un site sain. Vérifiez-le en lançant une première analyse de sécurité gratuite ci-dessous.
1. Pourquoi tant de sauvegardes échouent après un piratage
1.1 Elles sont sur le serveur attaqué
Beaucoup d’extensions stockent leurs archives dans wp-content, sur le même hébergement. Un attaquant qui contrôle le serveur peut les lire, les modifier ou les effacer. Une sauvegarde qui partage le sort du site ne protège de rien.
1.2 Elles ne remontent pas assez loin
Une infection peut rester silencieuse pendant des semaines avant de se manifester. Si vous ne gardez que les sept dernières sauvegardes, toutes risquent de contenir le code malveillant. Restaurer revient alors à réinstaller le problème.
1.3 Elles n’ont jamais été testées
Une archive corrompue, une base exportée à moitié ou un mot de passe de chiffrement perdu : ces défauts n’apparaissent qu’à la restauration. La CNIL le rappelle, une sauvegarde jamais testée peut se révéler inexploitable.
2. Ce que coûte une restauration impossible
Sans sauvegarde exploitable, un site piraté doit être nettoyé fichier par fichier, ou reconstruit. Dans les deux cas, le temps d’arrêt se compte en jours plutôt qu’en heures. Les formulaires ne fonctionnent plus et les campagnes publicitaires sont suspendues.
Pour une boutique en ligne, chaque heure perdue efface aussi des commandes. Une restauration trop ancienne fait disparaître les ventes et les comptes clients créés depuis. Il faut alors les ressaisir à la main, quand c’est possible.
La perte de disponibilité peut enfin constituer une violation de la sécurité des données au sens de la LPD. Ce point est développé dans notre article sur les obligations LPD après un piratage.
3. La règle 3-2-1 appliquée à WordPress
La CNIL et l’ANSSI recommandent toutes deux la règle 3-2-1 : trois copies des données, sur deux supports différents, dont une hors ligne. Pour un site WordPress, cela peut se traduire ainsi :
- la copie de production : le site en ligne et sa base de données ;
- une sauvegarde automatique chez un stockage distant, indépendant de l’hébergeur ;
- une copie déconnectée ou protégée contre l’effacement, mise à jour à intervalle régulier.
Le guide de l’ANSSI sur la sauvegarde, dans sa version 1.1, juge la copie hors ligne indispensable. À défaut, il admet une sauvegarde hors site en ligne sous conditions. Pour un site web, un stockage objet avec versionnement et verrouillage des suppressions s’en rapproche.
Les identifiants du stockage distant ne doivent pas permettre d’effacer l’historique. Sinon, un attaquant qui les trouve dans la configuration du site pourra supprimer vos copies.
4. Fréquence, rétention et contenu
4.1 Sauvegarder les fichiers et la base
Un site WordPress se compose de deux éléments : les fichiers, dont wp-content et wp-config.php, et la base de données. Les deux sont nécessaires. Une base sans les médias ou des fichiers sans la base ne permettent pas de restaurer.
Avec WP-CLI, une sauvegarde manuelle se fait en deux commandes. Exécutez-les hors de la racine publique du site :
wp db export ~/sauvegardes/base-$(date +%F).sql
tar -czf ~/sauvegardes/fichiers-$(date +%F).tar.gz -C /chemin/vers/le/site .4.2 Adapter la fréquence à l’activité
Un site vitrine peu modifié peut se contenter d’une sauvegarde quotidienne. Une boutique active justifie des sauvegardes plus rapprochées de la base. La question à poser est simple : combien d’heures de commandes acceptez-vous de perdre ?
4.3 Garder un historique suffisant
La CNIL suggère des sauvegardes incrémentales quotidiennes, complétées par des sauvegardes complètes régulières. L’ANSSI cite comme exemple 15 jours de sauvegardes journalières et un an de mensuelles. Pour un site web, conserver au moins quelques mois de points mensuels aide à remonter avant une infection discrète.
4.4 Chiffrer et séparer les accès
Une sauvegarde contient vos données clients, vos mots de passe hachés et parfois des clés d’API. Chiffrez-la avant l’envoi vers le stockage distant, comme le recommande la CNIL. Le transfert lui-même doit passer par un canal chiffré.
Séparez ensuite les rôles. La personne qui administre le site n’a pas besoin de pouvoir effacer l’historique des sauvegardes. Un compte dédié, protégé par la double authentification, limite les dégâts si un accès est volé.
Documentez enfin la procédure : où sont les copies, qui y a accès, comment restaurer. Ce document doit rester consultable même si le site et la messagerie sont hors service.
5. Situations de restauration : symptôme, cause, action
Ce tableau reprend les échecs de sauvegarde WordPress que nous constatons le plus souvent lors de nos interventions après piratage.
| Symptôme le jour J | Cause probable | Action corrective |
|---|---|---|
| Sauvegardes introuvables ou effacées | Archives stockées sur le serveur piraté | Envoyer automatiquement les copies vers un stockage distant |
| Toutes les sauvegardes sont infectées | Rétention trop courte face à une infection ancienne | Allonger l’historique, garder des points mensuels |
| Archive impossible à ouvrir | Fichier corrompu ou sauvegarde interrompue | Vérifier l’intégrité après chaque sauvegarde |
| Site restauré sans images | Dossier uploads exclu de la sauvegarde | Contrôler le périmètre réellement sauvegardé |
| Commandes récentes perdues | Fréquence trop faible pour la base | Rapprocher les sauvegardes de la base de données |
| Restauration bloquée faute d’accès | Identifiants ou clé de chiffrement perdus | Consigner les accès dans un coffre-fort de mots de passe |
6. Tester une restauration, étape par étape
Le test d’une sauvegarde WordPress se fait sur un environnement séparé, jamais sur le site en production. Beaucoup d’hébergeurs proposent un site de préproduction pour cet usage.
- Choisissez une sauvegarde au hasard, pas forcément la plus récente.
- Téléchargez-la depuis le stockage distant, sans passer par le serveur de production.
- Restaurez les fichiers et importez la base avec
wp db importsur l’environnement de test. - Adaptez l’adresse du site de test avec
wp search-replace, en ajoutant l’option--dry-runpour une simulation préalable. - Vérifiez les pages clés, les médias, les formulaires et, pour une boutique, le tunnel de commande.
- Mesurez le temps total de restauration : c’est votre durée d’arrêt réaliste.
- Consignez le résultat, la date et les anomalies dans un document partagé.
- Recommencez au moins chaque trimestre, et après chaque changement d’hébergement.
Un test réussi donne aussi confiance à la direction. Vous pouvez annoncer un délai de remise en ligne réaliste plutôt qu’une promesse vague.
7. Restaurer après un piratage sans réinfecter le site
Restaurer ne corrige pas la faille qui a permis l’intrusion. Choisissez un point antérieur à l’infection, puis appliquez toutes les mises à jour avant toute remise en ligne. Changez ensuite tous les mots de passe.
Pour dater l’infection, notre article sur la détection d’un malware WordPress présente les indices utiles. Si le site redirigeait vers des pages douteuses, comparez aussi avec notre guide sur les redirections malveillantes.
Les données créées depuis le point de restauration doivent être récupérées à part, avec prudence. Commandes, comptes clients et messages peuvent souvent être extraits de la base infectée, après contrôle. Les autres bonnes pratiques sont réunies dans notre guide pour sécuriser un site WordPress.
8. Questions fréquentes sur les sauvegardes WordPress
9. Faites auditer votre stratégie de sauvegarde
Avant d’organiser vos sauvegardes, assurez-vous que le site à sauvegarder est sain. Lancez une analyse de sécurité gratuite ici :
Nous auditons vos sauvegardes, testons une restauration et mettons en place des copies hors serveur. Après un incident, notre service de remise en état de site WordPress piraté prend le relais. Demandez un diagnostic pour en parler.
