Sauvegardes : tester la restauration, pas seulement la copie

La confusion entre sauvegarde terminée et restauration possible reste une faiblesse d’exploitation courante. Les équipes surveillent les tâches, corrigent les échecs de copie et suivent l’occupation des espaces de stockage. Ces contrôles sont nécessaires, mais incomplets. Une archive peut être lisible sans permettre de reconstruire un service. Il peut manquer une clé de chiffrement, un compte technique, une configuration réseau, un certificat, une dépendance applicative ou la procédure exacte de redémarrage. Le défaut n’apparaît alors qu’au moment de l’incident, quand chaque décision devient urgente et que l’environnement d’origine est parfois indisponible ou compromis.

Le faux confort des indicateurs verts

Un contrôle d’intégrité confirme généralement que les blocs sauvegardés correspondent à ce qui a été écrit. Il ne valide pas nécessairement la cohérence fonctionnelle de l’ensemble. Une base de données, un annuaire, un service de fichiers et une application métier peuvent avoir été copiés à des instants différents. Chacun de ces composants peut être techniquement restaurable, sans que leur combinaison produise un service exploitable. De même, la déduplication, la réplication ou l’existence de plusieurs copies ne remplacent pas un essai de reprise. Répliquer une corruption, une suppression logique ou une configuration erronée ne crée pas une sauvegarde saine. La bonne unité de mesure n’est donc pas le volume copié, mais le service effectivement remis en état.

Un test qui ressemble à un incident

• Définir le périmètre par service métier. Le test doit identifier les données, machines, conteneurs, configurations, secrets, certificats et dépendances nécessaires. Une liste limitée aux serveurs donne une vision trompeuse : elle ignore souvent les services d’identité, la résolution de noms, les flux réseau et les composants d’administration.
• Choisir un point de restauration sans privilégier le dernier disponible. Tester uniquement la sauvegarde la plus récente évite les cas difficiles. Il faut pouvoir sélectionner un point conforme à l’objectif de perte de données, vérifier sa présence sur les différents supports et documenter les raisons d’un éventuel écart.
• Restaurer dans un environnement isolé. Cette séparation évite les collisions d’adresses, l’envoi de messages réels, la réplication involontaire vers la production ou l’exécution de traitements métier. Elle permet aussi de tester un scénario dans lequel les outils d’administration habituels et certains comptes sont indisponibles.
• Mesurer la chaîne complète. Le chronomètre commence avec la décision de restaurer, pas avec le premier octet relu. Il inclut l’identification du point de reprise, les validations, l’accès aux clés, la reconstruction de l’infrastructure, la restauration, les contrôles applicatifs et l’autorisation de remise en service. C’est cette durée qui peut être comparée à l’objectif de temps de reprise.
• Faire valider le résultat par l’exploitation et le métier. Le démarrage d’un système d’exploitation ou l’ouverture d’une base ne suffisent pas. Des transactions représentatives, des contrôles de cohérence, les droits d’accès et les échanges avec les dépendances doivent être vérifiés. L’acceptation doit produire une preuve datée, attribuée et conservée.
• Transformer chaque écart en action suivie. Un test sans compte rendu exploitable devient une démonstration ponctuelle. Les écarts doivent avoir un responsable, une priorité, une échéance et un nouveau contrôle. La procédure de reprise doit être versionnée avec les configurations auxquelles elle s’applique.

Tester aussi les dépendances humaines

Une restauration qui ne fonctionne qu’avec la présence d’une personne précise n’est pas une capacité d’exploitation robuste. Les procédures doivent pouvoir être exécutées par une équipe autorisée disposant des accès prévus pour la crise. Cela suppose un inventaire maintenu, des rôles clairs, des moyens d’authentification de secours contrôlés et un accès documenté aux clés. Il faut également distinguer le test annoncé, utile pour vérifier une procédure, de l’exercice avec indisponibilités simulées, utile pour révéler les dépendances cachées. Le règlement (UE) 2022/2554, notamment son article 12, inscrit les politiques de sauvegarde ainsi que les procédures et méthodes de restauration et de récupération dans le cadre de gestion du risque lié aux technologies de l’information et de la communication. Pour une organisation régulée, la preuve attendue ne se limite donc pas à une capture d’écran : elle doit relier le scénario, l’exécution, les résultats, les écarts et leur traitement.

Un test de restauration peut lui-même créer un risque : exposition de données, réactivation de comptes, déclenchement d’interfaces ou conservation non maîtrisée des copies restaurées. L’environnement d’essai doit être isolé, journalisé et nettoyé selon une procédure approuvée. La fréquence et le périmètre des exercices dépendent de la criticité, des objectifs de reprise et des obligations applicables ; ils ne se déduisent pas d’un calendrier générique.