Ressources · 20

Tester une restauration de sauvegarde de bout en bout

Passer de copies supposées disponibles à une reprise réellement exercée et documentée.

Mis à jour le 23 octobre 2026 · 8 min

Ce que ce guide permet

Définir la reprise utile
Vérifier les copies
Exercer la restauration
Corriger les écarts

Contrôle express

Quel service doit revenir en premier et de quoi dépend-il ?
Qui peut accéder à une copie en situation dégradée ?
La copie est-elle isolée et exploitable ?
Le service restauré fonctionne-t-il pour un parcours réel ?
Quel temps et quelle perte de données ont été observés ?

Méthode pas à pas

01
Choisir un scénario
Partir d’un service métier, de ses données, de ses identités, de son réseau et de ses fournisseurs. Décrire la panne simulée et le résultat minimal attendu.
Livrable : fiche de scénario et ordre de reprise.
02
Définir des critères mesurables
Fixer le point de restauration acceptable, le délai visé, les vérifications fonctionnelles et les personnes capables de valider le résultat. Ne pas confondre objectif annoncé et résultat d’essai.
Livrable : grille de réussite approuvée.
03
Vérifier les copies et les accès
Contrôler l’existence, la date, l’intégrité et l’isolement des copies ainsi que les droits nécessaires pour restaurer. Préserver les données de production et les secrets pendant l’exercice.
Livrable : inventaire des copies et prérequis.
04
Restaurer en environnement maîtrisé
Dérouler la procédure avec les opérateurs prévus, horodater les étapes et noter les blocages. Utiliser un environnement isolé ou un mécanisme qui évite d’écraser le service actif.
Livrable : journal d’exercice et service reconstruit.
05
Valider le service
Tester un parcours utilisateur, la cohérence des données, les accès et les dépendances. Mesurer le délai écoulé et l’écart entre dernières données disponibles et point restauré.
Livrable : procès-verbal fonctionnel et mesures observées.
06
Corriger puis rejouer
Attribuer les écarts à un responsable, corriger procédures ou architecture et rejouer les étapes défaillantes. Mettre à jour le plan de continuité selon les preuves.
Livrable : plan d’action et date du prochain exercice.

Cas de recette à reproduire

Exemple fictif : ces données ne décrivent aucun client ni résultat réel.

Voir les données du cas

{
    "date": "2026-10-12",
    "timezone": "UTC",
    "verified_data_through": "09:45",
    "backup_job_finished": "09:53",
    "disruption": "10:00",
    "file_restore_started": "10:10",
    "file_restore_finished": "10:42",
    "business_journey_validated": "11:05",
    "additional_log_replay": false,
    "target_rpo_minutes": 15,
    "target_rto_minutes": 60
}

Décision attendue

Le critère de données est atteint, mais le critère de durée échoue. Documenter les 10 minutes d’attente, les 32 minutes de restauration et les 23 minutes de validation, corriger les blocages puis rejouer le parcours.

Fichiers restaurés ou service réellement repris ?

Exercice fictif, le 12 octobre 2026, toutes les heures en UTC. La copie termine à 09:53, mais contient des données vérifiées seulement jusqu’à 09:45. Incident à 10:00, restauration des fichiers de 10:10 à 10:42, parcours métier validé à 11:05. Aucun journal supplémentaire n’est rejoué. Objectifs de l’exercice : RPO de 15 minutes, RTO de 60 minutes, mesuré ici de l’interruption au parcours validé.

Mesure	Calcul	Lecture du résultat
Fenêtre de données non récupérées	10:00 − 09:45 = 15 min	15 minutes : l’objectif RPO est atteint dans ce scénario. Compter depuis la fin du travail de copie donnerait à tort 7 minutes. Cette durée ne dit pas combien d’enregistrements ont effectivement été perdus.
Restauration des fichiers	10:42 − 10:10 = 32 min	32 minutes pour cette étape technique. Cela exclut 10 minutes avant son lancement et 23 minutes de validation ; ce n’est pas le temps de reprise du service.
Reprise utilisable	11:05 − 10:00 = 65 min	65 minutes, soit 5 minutes au-delà du RTO fixé à 60. Le succès de la copie et l’atteinte du RPO ne suffisent pas à déclarer l’exercice réussi.

NIST — SP 800-34 Rev. 1, Contingency Planning (2010)

Comprendre · essayer · décider

Restauration : séparer temps de reprise et ancienneté des données

Le RTO fixe un objectif de durée de reprise ; le RPO indique jusqu’à quel point antérieur les données doivent pouvoir être récupérées. Ces deux objectifs répondent à des questions différentes. Une restauration rapide peut néanmoins récupérer des données trop anciennes.

Dans cet exercice, mesurez le temps entre l’interruption et la validation du service, puis l’écart entre l’interruption et le dernier point de données récupérable. Définissez à l’avance ce qui marque la validation : ouvrir une session, retrouver un dossier témoin et effectuer une opération attendue.

Si le budget de temps est respecté mais que les données dépassent l’ancienneté tolérée, examinez fréquence, retard et cohérence des copies. Si les données sont récentes mais que le service tarde à revenir, cherchez les dépendances, accès et validations qui rallongent la reprise. Conservez le journal de l’exercice et rejouez après correction.

Scène fictive de techniciens vérifiant un équipement de sauvegarde isolé. — Exercice fictif de restauration, sans entreprise ni incident réel représenté.

Repères et preuves à conserver

Repère	Ce que vous pouvez conclure	Preuve à conserver
Objectif RTO	Durée de reprise visée	Périmètre et point de départ convenus
Durée observée	Temps jusqu’à la validation du service	Horodatages et opération témoin réussie
Objectif RPO	Ancienneté maximale tolérée dans cet exercice	Point de données attendu et décision métier
Écart observé	Ancienneté du point réellement récupéré	Horodatage des données et contrôle de cohérence

Du constat à la décision

Fixer les objectifs
Restaurer en isolation
Valider le service
Comparer les deux écarts

Une reprise réussie se démontre sur le service

La fin de copie des fichiers est une étape. La reprise est validée lorsque le service prévu fonctionne avec des données cohérentes et les droits attendus. Le RTO et le RPO sont des objectifs à définir avec les responsables métier ; le NIST ne fixe pas les valeurs de cet exemple.

Durée observée: 95 minDe 09:00 à 10:35
Ancienneté récupérée: 45 minDernier point cohérent à 08:15
Marge sur le RPO: −15 minObjectif 30 min : dépassement

Chronologie fictive : même horloge, même service
Heure	Événement	Ce que cela établit
08:15	Dernier point récupérable cohérent	Les données perdues peuvent couvrir 45 minutes avant l’interruption.
09:00	Interruption constatée	Début de la durée de reprise retenue dans cet exercice.
10:10	Copie des fichiers terminée	70 minutes écoulées ; le fonctionnement n’est pas encore validé.
10:35	Connexion, dossier témoin et opération validés	95 minutes écoulées ; comparer cette durée au RTO de 120 minutes.

Les horodatages sont fictifs et utilisent le même fuseau. Le point récupérable doit être cohérent entre les composants, pas seulement récent dans un fichier.

Lire les deux objectifs ensemble
RTO	RPO	Décision dans l’exercice
Respecté	Respecté	Valider aussi intégrité, droits et dépendances avant de conclure.
Respecté	Dépassé	Corriger la fraîcheur ou la cohérence des copies, puis rejouer.
Dépassé	Respecté	Réduire les délais de dépendances, d’accès et de validation.
Dépassé	Dépassé	Revoir la chaîne de reprise et les objectifs métier avant un nouvel essai.

Un calcul conforme ne remplace pas les preuves fonctionnelles.

Contrôles avant de conclure

Restaurer dans un environnement isolé et vérifier que les connexions sortantes ne déclenchent pas de messages, paiements ou tâches réelles.
Vérifier ensemble application, base, clés, configuration, identité et dépendances. Un composant absent peut empêcher une reprise pourtant annoncée comme terminée.
Comparer un dossier témoin, les volumes attendus et une opération de bout en bout. Une empreinte identique vérifie une copie, sans garantir à elle seule la cohérence métier.

Décision : conserver les deux écarts, les contrôles fonctionnels et les exceptions. Rejouer après correction ; le succès d’un ancien exercice ne prouve pas celui de la version actuelle.

Règle de calcul

Marge de reprise = objectif RTO − durée observée. Marge de données = objectif RPO − ancienneté observée. Une marge négative indique un dépassement.

Changer une hypothèse

La restauration démarre vite, mais quand le service revient-il ?

Dans ce second exercice, indépendant du précédent, le chronomètre suit le point de départ et la fin convenus. Les heures sont fictives et dans un même fuseau.

09 h 00
Interruption du service ; départ de l’objectif de reprise retenu ici.
09 h 25
L’équipe commence la restauration technique.
10 h 10
Le parcours essentiel fonctionne et ses données sont vérifiées : 70 minutes après l’interruption.

Exercice de lecture : les variantes décrivent des situations fictives.

Peut-on annoncer une reprise en 45 minutes ?

Nouvel élément: La phase technique dure 45 minutes, mais la cible convenue est de 60 minutes depuis l’interruption.
Ce que cela change: Le temps de reprise du cas est de 70 minutes, soit un dépassement de 10 minutes. Garder les 25 minutes de mobilisation dans le calcul.

Et si la sauvegarde date de 08 h 30 ?

Nouvel élément: L’interruption de référence se produit à 09 h 00 et aucune donnée ultérieure n’est récupérée.
Ce que cela change: L’écart illustratif est de 30 minutes. Vérifier quelles écritures métier manquent réellement ; la seule heure du fichier ne démontre pas la cohérence des données restaurées.

Indicateurs de pilotage

Indicateur	Ce qu’il mesure	Première action
Couverture	Services prioritaires avec exercice récent	Exercer le service sans preuve
Restaurabilité	Copies effectivement lues et validées	Corriger les copies inutilisables
Délai observé	Temps entre déclenchement et parcours fonctionnel	Traiter le goulot réel
Perte observée	Écart entre données attendues et point restauré	Adapter fréquence ou méthode

Erreurs fréquentes

Confondre succès de sauvegarde et capacité de restauration
Tester uniquement un fichier sans ses dépendances
Écraser ou exposer des données de production pendant un essai
Déclarer un objectif de reprise atteint sans mesure réelle

Questions fréquentes

Une sauvegarde vérifiée suffit-elle ?

Elle prouve qu’une copie existe ou passe un contrôle donné, pas que le service complet peut reprendre. Un test fonctionnel reste nécessaire.

Faut-il couper la production ?

Non pour un premier exercice : un environnement isolé peut révéler les principaux blocages sans interrompre le service actif.

Que documenter ?

Le scénario, les copies utilisées, les droits, la chronologie, le résultat fonctionnel, les écarts et les responsables des corrections.

Incident cyber : décisions et preuves de reprise

Deux contrôles d’intégrité, avant et après restauration

RC.RP-03 concerne les moyens utilisés pour restaurer ; RC.RP-05 concerne les actifs et services restaurés. Le statut d’un travail de copie et la présence des fichiers ne suffisent pas à répondre à ces deux questions.

Avant usage, vérifier le candidat selon les contrôles prévus et conserver l’origine ainsi que la décision d’acceptation.
Après restauration, vérifier les actifs, les causes traitées dans le périmètre et un parcours métier avec ses dépendances.
Faire décider la fin de la reprise selon les critères locaux, sans confondre ce jalon avec la clôture de toutes les actions correctives.

Explorer les repères NIST et la chronologie →

Références relues le 2026-10-22 · NIST SP 800-61r3 · pp. 27–29, 34–35 · CSF 2.0 · Appendix A

Supports : assainissement et preuves

La copie de secours a aussi une fin de vie

Un test de restauration démontre un chemin de reprise dans un périmètre donné. Il ne prouve pas que les supports retirés, copies de clés ou données hors périmètre ont été assainis. Prévoir la fin de vie sans compromettre les besoins de conservation validés.

Relier copies de secours, supports et clés à leur propriétaire et à leur périmètre.
Séparer réussite de restauration, expiration de conservation et preuve d’assainissement.
En cas de CE envisagé, examiner les copies ou séquestres de clés hors du support.

Lire les méthodes, les repères de preuve et les situations commentées →

NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23

Références officielles

Date de consultation des références : 23/10/2026. La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.