Tester la restauration d’une sauvegarde

Une sauvegarde qui n'a jamais été restaurée reste une hypothèse. Un fichier corrompu pendant la copie, une base de données incomplète, une extension qui s'arrête silencieusement sans générer la sauvegarde attendue : rien de tout cela n'est visible tant qu'on ne tente pas réellement de reconstruire le site à partir de cette copie. Le test de restauration est la seule façon de savoir si la sauvegarde sert vraiment à quelque chose le jour où elle devient nécessaire.

L'ANSSI le dit sans détour dans son guide « Sauvegarde des systèmes d'information » (version 1.1 du 27 novembre 2025) : la recommandation R22 demande que les sauvegardes soient testées régulièrement et qu'une procédure de restauration soit rédigée, puis mise en œuvre régulièrement. Le même guide rappelle qu'en cas de rançongiciel, l'attaquant cherche fréquemment à chiffrer ou effacer aussi l'infrastructure de sauvegarde pour renforcer sa demande. Un site WordPress n'est pas un système d'information d'entreprise, mais le principe s'applique tel quel : une copie jamais éprouvée ne protège de rien.

Pourquoi une sauvegarde non testée n'en est pas vraiment une

Une extension de sauvegarde peut s'exécuter sans erreur visible tout en produisant un fichier incomplet, une base sans certaines tables, ou des médias absents. Seule une restauration effective révèle ce type de problème, bien après que la sauvegarde a été créée.

Sur quel environnement tester

Le test ne se fait jamais directement sur le site en ligne. Un environnement de préproduction, une copie locale ou un sous-domaine dédié à cet usage permettent de vérifier la restauration sans risque pour les visiteurs ni pour le contenu réel du site. Trois précautions évitent les effets de bord : protéger la copie par un mot de passe ou une consigne de non-indexation pour qu'elle n'apparaisse pas dans Google, couper l'envoi d'e-mails pour qu'aucun message de test ne parte vers de vrais clients, et basculer les passerelles de paiement en mode test si le site vend en ligne.

La séquence de restauration, étape par étape

1. Télécharger l'archive sur un poste de travail, au lieu de simplement constater qu'elle existe : un fichier corrompu se révèle au téléchargement.
2. Ouvrir l'archive et chercher le fichier de base de données (extension .sql) ainsi que le dossier des médias. Sans base de données, le reste ne permet pas de reconstruire le site.
3. Préparer la copie : un sous-domaine ou une installation locale, avec une base de données vide.
4. Restaurer les fichiers, puis importer la base de données correspondante.
5. Adapter la configuration : identifiants de base de données dans le fichier wp-config.php, adresse du site, enregistrement des permaliens, vidage des caches.
6. Contrôler le résultat : page d'accueil, une page avec des images, connexion à l'administration, formulaire de contact, et panier si le site vend.
7. Consigner la date du test, sa durée et ce qui a été vérifié.

Notre offre de sauvegarde et restauration intègre cette vérification dans la maintenance courante, et un audit technique en contrôle aussi le résultat.

Chronométrer : le test qui répond à « combien de temps hors ligne ? »

Restaurer une copie ne suffit pas, il faut savoir combien de temps cela prend. L'ANSSI parle de durée maximale d'interruption admissible (DMIA) : la restauration doit tenir dans ce délai, qui dépend du délai de mise à disposition de la sauvegarde, du débit et de la latence du lien Internet quand elle est stockée à l'extérieur. En vocabulaire courant, on parle aussi de RTO pour le temps de reprise et de RPO pour la quantité de données qu'on accepte de perdre entre deux copies.

Un calcul simple donne un plancher. À titre d'illustration, une archive de 10 Go à rapatrier sur un lien de 100 Mbit/s demande au minimum environ 13 minutes de transfert, avant la décompression et l'import de la base. Seul le chronométrage d'une vraie restauration donne la durée complète, et c'est elle qu'on compare à ce que l'activité peut supporter : une boutique en ligne et un site vitrine n'ont pas la même tolérance.

Cas d'une boutique WooCommerce

Sur un site qui vend, la date de la copie compte autant que son contenu. Les commandes passées entre la dernière sauvegarde et la panne ne figurent pas dans la copie : elles disparaissent de la base restaurée, alors que le paiement a bien eu lieu côté banque. Le test doit donc relever la date de la dernière commande présente dans la copie et la comparer à l'activité réelle, pour décider si le rythme de sauvegarde est suffisant ou s'il faut le rapprocher.

À quelle fréquence retester

Un test s'impose après tout changement de méthode de sauvegarde : nouvel hébergeur, nouvelle extension, nouvelle configuration. En dehors de ces changements, un test périodique, par exemple une fois par trimestre, reste une fréquence raisonnable pour un site actif. L'ANSSI écrit « régulièrement » sans fixer de rythme : le trimestre est un repère de bon sens, à resserrer pour un site qui enregistre des commandes. La sauvegarde elle-même doit être stockée ailleurs que sur le site, comme l'explique notre article sur la sauvegarde externalisée.