Tester une restauration : le rituel trimestriel qui sauve

Le test qui n'apprend rien est facile à reconnaître : c'est celui où l'on restaure un fichier connu, dans un dossier temporaire, sur un serveur allumé, par la personne qui a configuré la sauvegarde. Il réussit toujours. Le test qui apprend quelque chose commence par une phrase désagréable : « ce serveur n'existe plus, remonte-le ».

Quatre familles de restauration, à ne pas confondre

La restauration granulaire remet un fichier ou une boîte aux lettres. Elle est fréquente, rapide, et elle ne prouve à peu près rien sur la capacité de reprise. La restauration de machine complète remonte un système entier, avec son identité et sa configuration. La restauration applicative remet une base à un point dans le temps, ce qui suppose des journaux de transaction cohérents et non seulement une copie de fichiers. La reconstruction complète repart d'un socle vide, sans annuaire, sans résolution de noms, sans hyperviseur préexistant.

Le programme annuel devrait couvrir les quatre, à raison d'une famille par trimestre, avec un périmètre tournant pour ne pas toujours éprouver le même serveur. La quatrième est la plus instructive et la plus rarement menée, parce qu'elle est la seule à révéler les dépendances circulaires.

Un environnement où l'on a le droit d'échouer

Restaurer un contrôleur d'annuaire sur le réseau de production crée un conflit d'identité et peut faire plus de dégâts que l'incident simulé. Le test se mène donc dans un réseau isolé, sans route vers la production, avec sa propre résolution de noms. Ce bac à sable coûte quelques ressources et il change complètement la nature de l'exercice : on peut y aller franchement, y compris jusqu'à l'échec, ce qui est le but.

L'isolement impose une discipline : tout ce qui manque dans le bac à sable manquera aussi le jour de l'incident si l'on repart d'un site vide. Licences liées à un identifiant matériel, certificats internes, secrets stockés uniquement dans un gestionnaire lui-même hébergé sur la production, correspondances d'adresses réseau : ce sont les découvertes classiques du premier exercice.

Chronométrer par étape, pas globalement

Une durée totale ne se corrige pas. Une durée par étape se corrige. Le découpage utile comprend six temps : localiser la sauvegarde et vérifier son intégrité, préparer la cible, transférer les données, remonter le système, redémarrer les dépendances dans l'ordre, et vérifier fonctionnellement.

Dans la plupart des exercices, le transfert n'est pas l'étape la plus longue. Ce sont l'ordre de redémarrage et la vérification fonctionnelle qui dominent, parce qu'elles supposent de savoir ce qui dépend de quoi, information qui vit dans l'inventaire et non dans l'outil de sauvegarde. Nous détaillons cette dépendance dans nos notes sur la tenue d'une CMDB vivante.

Ces mesures alimentent directement les objectifs de reprise annoncés aux métiers. Un objectif de quatre heures démenti par un exercice de onze heures doit être corrigé dans un sens ou dans l'autre, sujet que nous traitons dans notre analyse consacrée à RPO et RTO chiffrés avec les métiers.

Vérifier l'intégrité, pas seulement la présence

Un fichier restauré n'est pas un fichier valide. Trois niveaux de vérification se cumulent. Le niveau technique compare les empreintes calculées à l'écriture et à la lecture. Le niveau applicatif ouvre la base, exécute une vérification de cohérence et consulte les derniers enregistrements. Le niveau métier demande à un utilisateur de retrouver une pièce précise, par exemple la dernière facture émise avant l'incident simulé.

Le troisième niveau est celui qui détecte les corruptions silencieuses sauvegardées fidèlement pendant des semaines. C'est aussi celui qui révèle le point aveugle des attaques : une donnée chiffrée par un rançongiciel est parfaitement sauvegardée et parfaitement inutilisable, mécanique que nous décrivons dans notre chronologie des attaques visant d'abord les sauvegardes.

Le compte rendu, pièce maîtresse

Un test sans trace écrite n'a pas eu lieu. Le compte rendu tient en une page : date, périmètre, personne ayant exécuté, durées par étape, écarts constatés, actions décidées avec un responsable et une échéance. Il sert trois usages. Il alimente la prochaine négociation contractuelle, car il confronte les engagements affichés à la réalité mesurée, selon la méthode exposée dans notre décorticage d'un SLA d'infogérance ligne à ligne. Il constitue la preuve attendue par les régimes de conformité récents. Et il fournit à l'équipe d'astreinte une procédure déjà éprouvée, ce qui change la nuit d'un incident réel, comme nous l'expliquons dans nos notes sur l'organisation d'une astreinte de nuit.

Les cinq causes d'échec les plus fréquentes

1. Une dépendance non documentée : annuaire, résolution de noms, serveur de temps, service de licence.
2. Un secret introuvable, parce qu'il n'existait que dans une console désormais inaccessible.
3. Un ordre de redémarrage inconnu, qui transforme deux heures en une journée.
4. Un débit insuffisant entre le dépôt et la cible, souvent découvert au premier téraoctet.
5. Une fenêtre d'arrêt trop courte, qui oblige à interrompre l'exercice avant la vérification.

Aucune de ces cinq causes n'est un défaut de l'outil de sauvegarde. Toutes sont des défauts de préparation, et toutes se corrigent une fois qu'elles ont été vues. C'est précisément la raison d'être de l'exercice, et c'est ce qui rend le cinquième point de la règle 3-2-1 relue à l'heure de l'immuabilité plus important que les quatre premiers.