Tests de restauration en infogérance : organiser les exercices, mesurer RTO/RPO et entretenir le runbook

Pour un programme initial, appliquez ces cadences indicatives : pour les systèmes de tier 1 (impact en quelques heures) exécutez des contrôles d’objet hebdomadaires automatisés, des restaurations applicatives chaque trimestre et au moins un exercice massif par an (ou après tout changement majeur) ; pour les systèmes de tier 2 effectuez des contrôles d’objet mensuels et des restaurations applicatives deux fois par an, en les incluant par rotation dans les exercices massifs. [1]

Le niveau 1 restaure un élément individuel (fichier, message, table ou objet S3) choisi au hasard et le compare à une référence connue ; ce test vise l’intégrité du catalogue, reste peu coûteux, peut être automatisé et doit aussi exercer des points de restauration plus anciens, y compris les copies immuables. [1]

Le niveau 2 restaure une application complète avec ses dépendances dans un segment réseau isolé et demande que le propriétaire de l’application exécute un jeu convenu de requêtes ou de transactions de validation pour confirmer que le service fonctionne réellement, car des problèmes latents (par exemple l’impossibilité de joindre une source d’authentification) peuvent apparaître à ce stade. [1]

Le niveau 3 restaure en parallèle un niveau entier de systèmes dans une clean room isolée, avec identité et réseau séparés ; cet exercice scénarisé mesure le débit agrégé de restauration, révèle les ordonnancements manquants entre systèmes et doit être conduit comme un exercice officiel avec scénario, secrétaire et débriefing. [1]

La vérification automatique confirme que le travail de sauvegarde s’est terminé et que l’image peut booter, tandis que le test de restauration valide qu’un système peut être récupéré en état utilisable dans le RTO convenu et exige une intervention humaine pour lancer la restauration, vérifier le fonctionnement applicatif et documenter le résultat ; les deux preuves sont nécessaires. [2]

Une vérification automatisée, exécutée après chaque job, doit au minimum confirmer l’absence d’erreur, l’intégrité de la chaîne (notamment pour les incréments), la capacité de l’image à démarrer (screenshot) et la réplication hors site ; elle ne détectera pas la corruption applicative, l’intégrité interne d’une base ou si la restauration respecte le RTO cible, ce qui nécessite un test manuel. [2]

Comme base pratique, combinez une surveillance automatisée quotidienne avec des échantillons de restauration hebdomadaires ou mensuels, des restaurations applicatives mensuelles ou trimestrielles, des tests critiques trimestriels et au moins un exercice complet par an, en veillant à varier les points de restauration testés. [3]

Un exercice doit produire des mesures exploitables et comparables aux objectifs : sans chiffres (âge des données, délais, débit) un test décrété « réussi » a peu de valeur pour juger de la conformité au service convenu. [1]

Le débit de restauration pertinent se mesure en téraoctets par heure sur l’ensemble du chemin de restauration et non sur le pic d’un flux isolé ; par exemple, pour 200 To à restaurer en 24 heures il faut viser un débit soutenu supérieur à environ 8,5 To/heure avec marge, faute de quoi le RTO annoncé est irréaliste. [1]

Consignez systématiquement l’âge des données restaurées (RPO observé) et le temps écoulé entre le lancement de la restauration et la disponibilité effective du système (RTO observé), puis comparez ces valeurs aux cibles du contrat; si le RTO observé dépasse l’objectif, analysez le support, les étapes de restauration ou la pertinence de la cible. [2]

Ne testez pas seulement la copie la plus récente : faites tourner des points de restauration variés — le dernier point, un point choisi aléatoirement, un point antérieur à un incident simulé, un point ancien proche de la limite de rétention, une copie off‑site/immutables, et des copies cross‑region ou pré/post‑changement — pour vérifier la fiabilité des sauvegardes à différents âges et contextes. [3]

La vérification de la couverture de restauration exige un inventaire complet des dépendances nécessaires au service : bases de données et logs, binaires et configurations, partages et volumes persistants, systèmes d’identité et comptes privilégiés, DNS/NTP/certificats/clefs, et le catalogue/agents/identifiants de la solution de sauvegarde. [3]

La rétention par verrouillage d’objet (object lock) doit être testée : un opérateur non administrateur tente de supprimer ou d’écraser un point verrouillé et consigne le refus, puis la même tentative est effectuée avec le compte de service de la solution de sauvegarde ; si l’un des essais réussit, l’immutabilité n’est pas effective. [1]

Un runbook est le chemin convenu sous pression : il doit nommer le service, l’on‑call ou le propriétaire principal, la criticité et les RTO/RPO, les déclencheurs qui activent la procédure, les canaux de communication et les étapes de mitigation, basculement, vérification et retour à l’état stable, sans chercher à prédire tous les incidents. [4]

Pour garder le runbook vivant, planifiez des exercices récurrents de types différents : par exemple une table‑top trimestrielle pour vérifier les responsabilités, une bascule de base de données mensuelle en préproduction avec limite de temps et un restore hebdomadaire ou régulier pour prouver le RPO. [4]

Assignez un propriétaire explicite au runbook et reliez sa mise à jour aux changements : lorsque l’on ajoute une dépendance, publie une feature ou fait tourner une rotation de secrets, le runbook doit être modifié dans la même revue (PR) avec une question spécifique demandant si le changement affecte les procédures de reprise. [4]

Choisissez d’abord les tiers de criticité pour vos services, planifiez les trois niveaux d’exercices avec des cadences-test et assignez des responsables pour chaque ticket de test.

Mesurez et consignez RPO, RTO et débit à chaque exécution ; utilisez les écarts pour ajuster la cible RTO ou améliorer l’infrastructure.

Maintenez le runbook connecté aux changements (dépendances, secrets, indicateurs) et programmez des table‑top et des drills réguliers pour valider la procédure.