Une console de sauvegarde affichant une longue série de coches vertes prouve que des données ont été écrites quelque part. Elle ne prouve pas que ces données peuvent être relues, qu’une application peut démarrer à partir d’elles, ni que l’ensemble de l’opération tient dans la fenêtre de reprise promise aux métiers.
Le ransomware a changé la nature du problème. Une reprise consistait autrefois à restaurer un serveur ou un dossier supprimé. Elle signifie désormais souvent restaurer d’un coup un niveau entier de systèmes, dans un environnement auquel on ne peut pas faire confiance, alors que les personnes qui connaissent le mieux l’infrastructure sont privées de leurs outils habituels.
Cet article décrit un programme pratique de tests de restauration : trois niveaux de test, une cadence de départ pour chacun, les mesures qui prédisent réellement le temps de reprise, la manière de consigner les résultats par rapport au RTO et au RPO, et les raisons pour lesquelles les exercices échouent le plus souvent.
Le test de restauration est l’acte délibéré de restaurer des données ou des systèmes depuis une sauvegarde vers un emplacement contrôlé et de confirmer que le résultat est complet, cohérent et utilisable. Il se distingue de la supervision des travaux de sauvegarde, qui indique seulement que la phase d’écriture s’est achevée, et des fonctions de vérification automatisée qui démarrent un snapshot ou comparent des sommes de contrôle. Ce sont des contrôles de confiance sur une copie, pas une répétition du processus qu’une équipe suivrait sous pression.
Le temps de reprise est dominé par des éléments qu’un travail de sauvegarde n’exerce jamais : le débit du chemin de restauration, l’ordre dans lequel les systèmes dépendants doivent revenir, la disponibilité des identifiants et du DNS, et le temps qu’il faut aux personnes pour prendre des décisions. Un exercice de restauration mesure tout cela.
Un programme viable teste souvent les petites choses, régulièrement les choses moyennes et rarement mais sérieusement les grandes.
Le test le plus léger restaure un fichier individuel, un élément de boîte de messagerie, une table de base de données ou un objet S3 depuis un point de sauvegarde choisi au hasard et le compare à une référence connue. L’objectif est l’intégrité du catalogue : l’application de sauvegarde sait-elle où se trouvent les données, peut-elle les récupérer, et le contenu correspond-il. Ces contrôles sont peu coûteux et peuvent être automatisés. Ils doivent tourner entre les charges de travail et les âges de sauvegarde afin que les points de restauration plus anciens, y compris ceux d’un niveau immuable, soient exercés.
Le niveau intermédiaire restaure une application complète, typiquement une base de données, un serveur de fichiers ou un système métier avec ses dépendances, dans un segment réseau isolé. Le succès n’est pas que les machines virtuelles démarrent. Le succès est que le propriétaire de l’application se connecte, exécute un jeu convenu de requêtes ou de transactions de validation et donne son accord. C’est là que les problèmes latents apparaissent, comme une base de données restaurée qui démarre mais ne peut pas joindre sa source d’authentification.
Le test le plus lourd restaure un niveau entier de systèmes en parallèle dans une clean room (environnement de restauration isolé) : un environnement fraîchement construit et isolé, avec sa propre identité, son propre réseau et ses propres outils de gestion, supposé exempt de toute présence d’attaquant. C’est le seul test qui mesure le débit de restauration agrégé sous une charge réaliste, révèle les problèmes d’ordonnancement entre systèmes et répète le plan de réponse à incident. Il doit être mené comme un exercice avec un scénario, un secrétaire de séance et un débriefing.
La cadence doit suivre la criticité de la charge de travail et le coût du test, et elle doit être ajustée sur la base des constats. Si une répétition de niveau 3 révèle une dépendance que personne n’avait documentée, la suivante doit venir plus tôt.
Les organisations réglementées peuvent avoir des minimums prescrits. Les cadences ci-dessus ne sont pas une norme, seulement un point de départ défendable.
Un exercice qui se termine par « ça a fonctionné » a gaspillé l’essentiel de sa valeur. Cinq mesures transforment un test en données comparables aux objectifs de reprise convenus.
Mesuré en téraoctets par heure sur l’ensemble du chemin de restauration, pas le pic d’un seul flux. Supposons qu’une organisation dispose de 200 To dans ses systèmes de tier 1 et d’un RTO déclaré de 24 heures. Elle a besoin d’un débit soutenu supérieur à environ 8,5 To par heure, avec de la marge, sans quoi le RTO est une fiction, quelle que soit la qualité des sauvegardes.
Temps écoulé entre la décision de restaurer et la validation du premier système de tier 1. Cela capture la charge fixe de mise en place de la clean room et de récupération de l’identité, qu’aucun chiffre de débit ne révèle.
Temps écoulé jusqu’à ce que le dernier système du niveau passe la validation. C’est le résultat principal d’un exercice de niveau 3.
Le pourcentage d’éléments restaurés ayant passé la validation à la première tentative. Tout ce qui est inférieur à 100 pour cent est un constat.
La rétention par object lock doit être testée, pas supposée. Un opérateur utilisant une identité standard, non administrative, tente de supprimer ou d’écraser un point de restauration verrouillé et consigne le refus. La même tentative doit être faite avec le compte de service de l’application de sauvegarde elle-même, puisque c’est l’identifiant qu’un attaquant a le plus de chances d’obtenir. Si l’une ou l’autre réussit, les sauvegardes ne sont pas protégées.
| Niveau de test | Périmètre | Cadence de départ | Métriques clés | Responsable |
|---|---|---|---|---|
| Niveau 1 : contrôle ponctuel | Fichier, objet ou table unique depuis des points et âges de sauvegarde en rotation | Hebdomadaire (tier 1), mensuelle (tier 2), trimestrielle (tier 3) ; automatisée | Taux de réussite ; temps de récupération ; refus d’immutabilité consigné | Administrateur de sauvegarde |
| Niveau 2 : restauration applicative | Une application avec ses dépendances, segment isolé, validation par le propriétaire | Trimestrielle (tier 1), semestrielle (tier 2), annuelle (tier 3) | Délai jusqu’à l’application validée ; taux de réussite ; dépendances manquantes | Administrateur de sauvegarde avec validation du propriétaire de l’application |
| Niveau 3 : répétition de restauration massive | Niveau entier en parallèle dans une clean room, mené comme un scénario avec débriefing | Annuelle et après tout changement majeur d’infrastructure | Débit soutenu ; délai jusqu’au premier système utilisable ; délai jusqu’au niveau complet | Responsable infrastructure avec la sécurité et la continuité d’activité |
Chaque exercice doit produire un compte rendu court qu’un non-spécialiste peut lire six mois plus tard : date, scénario, systèmes dans le périmètre, point de restauration sélectionné et son âge (le RPO atteint pour ce test), les temps écoulés ci-dessus (le RTO atteint), le taux de réussite, le résultat du contrôle d’immutabilité, et chaque constat avec un responsable et une échéance.
La comparaison utile est celle de l’atteint par rapport au convenu. Une application de tier 1 avec un RTO de 4 heures dont la validation a pris 7 heures est un écart documenté : soit le RTO change, soit l’infrastructure change, soit les métiers acceptent le risque par écrit. Le suivi des résultats d’un exercice à l’autre montre aussi si le débit de restauration suit la croissance des données ; l’article précédent sur le dimensionnement du dépôt de sauvegarde couvre l’aspect capacité.
La restauration technique des données est rarement la partie qui casse. Les causes récurrentes sont :
Scality ARTESCA est un stockage objet S3 conçu comme cible de sauvegarde, avec une immutabilité S3 Object Lock appliquée par le stockage plutôt que par l’application de sauvegarde. Les copies immuables étant en ligne plutôt que sur des supports amovibles ou dans un coffre hors ligne, elles peuvent être sélectionnées comme points de restauration et relues directement via l’application de sauvegarde, ce qui fait des tests de niveau 1 et de niveau 2 sur des copies protégées une opération de routine.
ARTESCA est validé avec les principales applications de sauvegarde, de sorte que les exercices utilisent la même console, le même catalogue et les mêmes flux de travail que les opérateurs connaissent déjà. Le contrôle d’immutabilité décrit ci-dessus peut être réalisé sous la forme d’une simple tentative de suppression S3 sur un objet verrouillé, le refus étant consigné comme preuve. La page sécurité et cyber-résilience décrit les contrôles plus en détail.
À retenir concrètement : planifiez la première restauration de niveau 2 ce trimestre, mesurez les cinq chiffres et notez l’écart entre ce qui a été atteint et ce qui a été promis.