Tester ses sauvegardes : la méthode pour être sûr de pouvoir restaurer

Chaque matin, le rapport de sauvegarde affiche des lignes vertes. Pourtant, dans les audits que nous menons, la question « quand avez-vous restauré un serveur pour la dernière fois ? » reste souvent sans réponse. La réponse courte : une sauvegarde n’est fiable que si une restauration a été réellement testée, chronométrée et documentée. Cela passe par quatre niveaux de test, un calendrier fixé à l’avance, une comparaison du temps réel avec votre RTO et une règle simple quand un test échoue. Voici la méthode que nous appliquons dans les entreprises que nous accompagnons au Maroc.

Pourquoi « sauvegarde réussie » ne veut pas dire « restaurable »

Un logiciel de sauvegarde signale qu’il a copié des blocs sans erreur. Il ne vérifie pas, par défaut, que ces blocs forment un système qui redémarre et une application qui fonctionne. Les causes d’échec que nous rencontrons au moment de restaurer sont rarement spectaculaires :

• une base de données incohérente, sauvegardée pendant une écriture, sans traitement applicatif ;
• un volume oublié : le disque de données a été ajouté après la création de la tâche et n’y figure pas ;
• une dépendance absente : le serveur applicatif revient, mais l’annuaire ou le serveur de licences n’ont pas été restaurés ;
• une clé de chiffrement introuvable : la sauvegarde est protégée par un mot de passe que plus personne ne connaît ;
• une restauration beaucoup plus lente que prévu, parce que le lien internet ou le stockage de secours n’ont jamais été mesurés en situation réelle.

Aucune de ces causes n’apparaît dans le rapport quotidien. Seul un test les révèle. C’est le « 0 » de la règle 3-2-1-1-0 : zéro erreur constatée lors d’une restauration réelle.

Les quatre niveaux de test

Tester ses sauvegardes ne se limite pas à récupérer un fichier. Chaque niveau prouve quelque chose de différent, et aucun ne remplace les autres.

Niveau	Ce que l’on fait	Ce que cela prouve	Ce que cela ne prouve pas
Fichier	Restaurer un document ou un dossier précis à une date donnée	Les données sont lisibles et la rétention fonctionne	Qu’un serveur complet peut redémarrer
Machine virtuelle	Démarrer une VM depuis la sauvegarde dans un réseau isolé	Le système démarre, les disques sont complets	Que l’application et ses données sont cohérentes
Application	Restaurer l’ERP, la messagerie ou la base, et faire vérifier les données par un utilisateur clé	L’activité peut réellement reprendre sur ce service	Que l’ensemble tient dans le délai fixé
Site complet	Reconstruire l’ensemble dans l’ordre du PRA, chronomètre en main	Le délai réel de retour à la normale	Rien de plus : c’est le test de référence

Le test de fichier est utile mais trompeur quand il est le seul pratiqué : il rassure sans prouver qu’on sait remonter un serveur. À l’inverse, le test de site complet est lourd ; il ne se fait pas chaque semaine, mais il est le seul à mesurer votre capacité réelle de reprise.

Automatiser ce qui peut l’être : SureBackup et Instant Recovery

Avec Veeam, une partie des tests peut être automatisée. SureBackup démarre les machines sauvegardées dans un laboratoire virtuel isolé de la production, puis vérifie qu’elles répondent : démarrage du système, réponse réseau, et, si on les configure, des scripts de contrôle propres à l’application. Une tâche planifiée signale ainsi une sauvegarde inutilisable bien avant le jour où l’on en a besoin.

Instant Recovery permet de démarrer une machine virtuelle directement depuis le fichier de sauvegarde, pendant que la restauration définitive se poursuit en arrière-plan. C’est un outil de reprise rapide, mais aussi un excellent test : si une VM critique ne démarre pas en Instant Recovery, vous le saurez avant l’incident.

Ces automatismes ne remplacent pas le regard humain. Un laboratoire qui confirme qu’un serveur « répond » ne dit pas si la comptabilité du mois dernier est complète. C’est le rôle du test applicatif, réalisé avec un utilisateur métier. Les réglages Veeam qui rendent ces tests possibles sont détaillés dans notre guide Veeam : les 6 réglages.

Le calendrier de test en entreprise

Le bon rythme dépend de la criticité de chaque système. Voici la trame que nous proposons aux PME, à ajuster lors de l’audit :

• En continu : lecture des alertes de sauvegarde, avec relance dès qu’une tâche échoue ou reste en avertissement.
• Chaque semaine : vérification automatique des machines critiques dans un laboratoire isolé.
• Chaque mois : restauration de fichiers pris au hasard, y compris dans Microsoft 365 (un mail, un fichier OneDrive, un site SharePoint).
• Chaque trimestre : restauration applicative complète d’au moins un système critique, chronométrée, avec validation par un utilisateur clé.
• Chaque année : exercice de sinistre sur l’ensemble du périmètre, dans l’ordre prévu par le plan de reprise.
• Après chaque changement important : nouveau serveur, migration, changement de stockage ou de prestataire.

Faites tourner les systèmes testés d’un trimestre à l’autre pour couvrir tout le périmètre dans l’année.

Ce qu’il faut mesurer : le temps réel face au RTO

Un test sans chronomètre ne sert qu’à moitié. Le plan de reprise d’activité fixe deux objectifs : le RTO, durée d’arrêt acceptable, et le RPO, perte de données acceptable. Le test donne leurs valeurs réelles.

Mesure	Comment l’obtenir	Question à se poser
Temps de restauration réel	Chronomètre, du lancement jusqu’à la validation par l’utilisateur	Est-il inférieur au RTO fixé ?
RPO réel	Date et heure du point restauré par rapport au moment du test	La perte de données serait-elle acceptable ?
Complétude	Vérification par un utilisateur clé : dernières écritures, pièces jointes, droits d’accès	Manque-t-il des données ou des dépendances ?
Étapes manuelles	Liste des actions non documentées improvisées pendant le test	Quelqu’un d’autre aurait-il su les faire ?

Mesurez de bout en bout, pas seulement la durée de copie : la recherche du bon point de restauration, les accès, la reconfiguration réseau et la validation font partie du temps d’arrêt réel.

Documenter chaque test

Un test non consigné est un test qui n’a pas eu lieu, pour un auditeur comme pour votre successeur. Chaque compte rendu tient en une page : date, système testé, point de restauration utilisé, personne qui a restauré, personne qui a validé, temps mesuré, résultat, écarts constatés et actions décidées. Conservez ces comptes rendus ensemble : ils montrent l’évolution de votre capacité de reprise et servent de preuve en cas de contrôle, par exemple sur la protection des données personnelles.

Quand un test échoue

Un test qui échoue est une bonne nouvelle : le problème a été trouvé avant l’incident. La règle est simple : tant que le test n’a pas réussi, la sauvegarde concernée est considérée comme absente.

1. Ouvrir un incident, avec la même priorité qu’une panne.
2. Identifier la cause : configuration, stockage, identifiants, procédure ou dépendance.
3. Corriger, puis relancer le même test jusqu’à réussite.
4. Vérifier si la même cause touche d’autres tâches.
5. Mettre à jour la procédure de restauration et le plan de reprise.

Le scénario ransomware

Le test le plus exigeant est celui qui simule un ransomware. Il ajoute trois contraintes : le réseau de production et l’annuaire sont considérés comme compromis, la restauration part de la copie immuable ou hors site, et le point choisi doit précéder l’intrusion. Vérifiez donc que vous savez accéder aux sauvegardes sans les comptes du domaine, que le temps de restauration depuis la copie distante est compatible avec votre RTO, et que les données restaurées sont analysées avant la remise en service, pour ne pas réintroduire l’attaquant.

Les erreurs les plus fréquentes

• Tester toujours le même petit fichier, qui ne prouve rien sur les serveurs.
• Tester en production, au risque d’écraser des données réelles ou de créer un conflit d’adresses.
• Ne jamais chronométrer, et découvrir pendant l’incident que la restauration dépasse le RTO.
• Oublier les dépendances : annuaire, DNS, licences, certificats.
• Faire tester par une seule personne, qui devient indispensable le jour du sinistre.
• Ne pas valider avec le métier : la machine démarre, mais personne n’a vérifié les données.

Checklist : vos tests de restauration

• Les quatre niveaux de test sont couverts : fichier, VM, application, site complet.
• Un calendrier écrit précise qui teste quoi, et quand.
• Les tests se font dans un réseau isolé de la production.
• Chaque test est chronométré et comparé au RTO et au RPO.
• Un utilisateur métier valide les données restaurées.
• Un compte rendu d’une page est archivé pour chaque test.
• Tout échec est traité comme un incident et le test relancé.
• Un scénario ransomware depuis la copie immuable a été joué au moins une fois.
• Au moins deux personnes savent restaurer les systèmes critiques.

Comment nous procédons

Nous commençons par un état des lieux : tâches de sauvegarde, périmètre couvert, date et résultat du dernier test réel. Nous définissons ensuite avec vous le calendrier de test, les objectifs de RTO et de RPO par système, puis nous mettons en place les vérifications automatiques et le laboratoire isolé. Les restaurations trimestrielles sont réalisées avec vos utilisateurs clés et consignées dans le rapport de service. Les alertes rejoignent notre supervision 24/7, et un incident critique est pris en charge en moins de 15 minutes. Cet accompagnement fait partie de notre offre sauvegarde et continuité d’activité ; nos réalisations présentent des projets comparables.

Vous ne savez pas si vos sauvegardes sont restaurables ? L’audit initial est offert, et nous répondons sous 24 h ouvrées : contactez-nous.