Test de restauration : vérifier la reprise d'un service

Le rapport de sauvegarde est vert. La direction vous demande combien de temps prendrait la remise en service de la gestion commerciale. Vous connaissez la durée de copie des données, mais personne n’a vérifié le démarrage de l’application ailleurs que sur son infrastructure habituelle. La réponse manque précisément là où elle devient utile.

Je commencerais par un exercice limité à ce service. L’objectif est de produire une preuve exploitable : ce qui a été restauré, ce qu’un utilisateur a pu faire et ce qui dépendait encore de la production. Un test réussi sans ces précisions rassure davantage qu’il ne renseigne.

Choisir un service et une opération à retrouver

Je pars d’une tâche métier, par exemple consulter une commande et retrouver ses pièces jointes. Ce scénario est un choix d’exercice, pas le récit d’un incident client. Il permet de nommer les éléments nécessaires : application, base de données, stockage documentaire et authentification. Restaurer seulement la base ne suffira pas à vérifier cette tâche.

Avec le responsable métier, je fais préciser l’interruption supportable et les données qu’il accepterait de ressaisir. Les fondamentaux de la sauvegarde de l’ANSSI rattachent la stratégie de sauvegarde à la perte de données et à la durée d’interruption admissibles. Ces objectifs donnent un sens au résultat technique.

Je consigne ensuite le scénario retenu : perte du serveur applicatif, données endommagées ou indisponibilité du stockage. Il faut choisir. Un essai qui conserve l’annuaire et le réseau de production ne démontre pas une reconstruction après perte de tout le SI.

Le périmètre tient dans une fiche : service concerné, opération attendue, copie à utiliser, composants inclus, dépendances conservées et personne chargée de constater le résultat. Je fais relire cette fiche avant de réserver le créneau. Cela évite de découvrir après l’essai que le métier attendait aussi la reprise des échanges avec son prestataire logistique.

Préparer une destination qui ne peut pas agir sur la production

Je demande un environnement de restauration distinct et un contrôle de ses communications avant tout démarrage. Une machine clonée peut conserver des tâches planifiées, des destinataires de courriels et des connexions vers des applications réelles. Le nom donné au réseau de test ne prouve pas son isolation.

L’administrateur vérifie la destination des écritures, les flux autorisés et les automatismes à neutraliser. Pour notre exemple, la consultation d’une commande ne doit ni envoyer une confirmation au client ni transmettre un ordre à l’entrepôt. Les interfaces nécessaires à l’essai sont remplacées par des destinations de test explicitement prévues.

La copie contient potentiellement les mêmes informations sensibles que la production. La fiche de la CNIL sur les sauvegardes recommande une protection équivalente des données sauvegardées et le contrôle de leur capacité de restauration. Je limite donc les accès au test, prévois la suppression des copies et conserve les preuves utiles sans multiplier les exports de données métier.

Je fixe aussi une condition d’arrêt : destination ambiguë, flux inattendu ou charge qui menace le service réel. L’opérateur doit pouvoir interrompre l’exercice immédiatement. Si l’isolation ne peut pas être établie, je reporte le démarrage et traite ce manque comme un résultat de préparation, avec un responsable et une action à terminer.

Restaurer depuis les moyens réellement disponibles

Je fais commencer l’exercice à la demande de restauration, avec la procédure et les accès prévus. Le chronomètre doit inclure la recherche de la bonne copie, sa mise à disposition et la récupération des moyens de déchiffrement. Démarrer la mesure quand les fichiers sont déjà sur le serveur d’essai retire une partie du problème.

L’équipe relève les prérequis qu’elle utilise : console de sauvegarde, catalogue, espace de stockage, logiciels d’installation, configuration et secrets nécessaires. Pour chaque élément, je demande s’il resterait disponible dans le scénario choisi. Si l’exercice suppose un serveur perdu mais utilise un fichier stocké uniquement dessus, la procédure doit être corrigée.

Je vérifie particulièrement les accès sans développer ici leur dispositif de secours, traité dans l’article sur les comptes d’accès d’urgence. Pendant le test, l’accès doit fonctionner avec les moyens autorisés et documentés. Une session déjà ouverte par habitude mérite d’être signalée dans les limites de l’essai.

L’opérateur note les interventions manuelles et les appels au prestataire. Je veux distinguer une étape prévue d’une aide improvisée. Une restauration obtenue grâce à une personne disponible ce jour-là peut être techniquement réussie tout en laissant une dépendance non résolue. Le compte rendu doit garder les deux informations.

Contrôler les données et l’usage après le redémarrage

Le démarrage de la machine est une étape. J’attends ensuite un contrôle applicatif, puis l’exécution du parcours métier convenu. Le test doit notamment établir à quel état des données on est revenu et si les éléments liés restent cohérents.

Pour l’exemple de la gestion commerciale, je demanderais au référent métier de retrouver une commande connue, ses lignes et ses documents associés. Il compare le résultat à un état de référence préparé avant l’exercice. Une page qui s’affiche ne permet pas, à elle seule, de vérifier la complétude des informations.

Je fais inscrire les écarts dans le compte rendu : document absent, traitement bloqué, droit incorrect ou donnée plus ancienne qu’attendu. La correction doit être suivie d’un nouvel essai ciblé. Une explication plausible ne remplace pas cette vérification.

La preuve de restauration s’arrête au dernier usage effectivement vérifié.

Mesurer le délai complet et qualifier les limites

Je sépare les étapes dans le relevé : mobilisation, accès à la copie, transfert, reconstruction, contrôles et validation de l’usage. Cette décomposition permet de choisir une correction utile. Acheter du stockage plus rapide ne résout pas un délai passé à chercher qui possède la clé de déchiffrement.

Je relève aussi le point de restauration réellement obtenu. La date du fichier de sauvegarde ne remplace pas le contrôle des dernières opérations présentes dans l’application. Le métier doit pouvoir comprendre quelles données seraient à reprendre et si une ressaisie serait possible.

Le résultat reste attaché aux conditions d’essai. Une restauration sur une infrastructure disponible, avec l’équipe prévenue et sans concurrence pour les ressources, ne donne pas une garantie de délai en crise. Je présente une durée mesurée dans ces conditions, puis les étapes qui restent à éprouver.

La CNIL recommande de tester la continuité et la reprise d’activité, en permettant des essais ciblés pour limiter leur impact sur la production. Je retiens cette progression : réussir un exercice limité, puis élargir le périmètre. Un test ordinaire ne valide pas non plus l’absence de compromission d’une copie après une attaque ; cette question relève d’un scénario de reconstruction distinct.

Transformer l’exercice en travail planifié

Je termine par un compte rendu court, compréhensible sans ouvrir la console de sauvegarde. Il indique le scénario, la copie utilisée, les opérations réussies, le délai observé et les dépendances conservées. Les preuves détaillées restent accessibles à l’équipe technique dans un emplacement protégé.

Chaque écart devient une action attribuée : retrouver une configuration, rendre une clé accessible dans les conditions prévues, compléter la procédure ou préparer un contrôle métier. J’inscris le prochain essai au moment d’attribuer la correction. Sans cette réservation, le constat risque de rester dans le compte rendu jusqu’au prochain incident.

Je ne fixe pas une fréquence identique pour toutes les applications. Je propose un calendrier fondé sur leur criticité, les changements de la chaîne de sauvegarde et les échecs précédents. Une modification importante du stockage, de l’application ou de l’authentification doit conduire à réexaminer les essais concernés.

Pour démarrer la semaine prochaine, choisissez le service, faites valider le parcours à retrouver et préparez l’environnement isolé avec son opérateur. Réservez le référent métier pour le contrôle final. La première séance peut révéler que la restauration n’est pas encore possible : c’est précisément l’information dont le DSI a besoin pour organiser la suite.