Le test de restauration que personne n'exécute

Toutes les organisations ont des sauvegardes. Peu ont restauré récemment. L'écart entre les deux est l'un des risques les plus répandus et les moins visibles des systèmes d'information.

Pourquoi le test n'est jamais fait

Il n'est jamais urgent. Il mobilise des personnes rares sur une journée entière. Il n'a aucun résultat visible en cas de succès. Et il présente un risque perçu — « et si le test cassait quelque chose ». Chaque trimestre, il est repoussé au suivant pour de bonnes raisons individuelles.

Ce que le test révèle presque toujours

Le délai réel est plus long que le délai annoncé. Le plan de continuité affiche quatre heures. La restauration réelle en prend onze, parce que le temps de transfert depuis le stockage froid n'avait pas été mesuré, ou parce que la reconstruction des index prend plusieurs heures sur un volume de production.

Il manque quelque chose. Presque toujours la même chose : les secrets, les certificats, les configurations d'ordonnanceur, ou les droits d'accès. La base est restaurée, l'application ne démarre pas.

Personne ne sait exécuter la procédure. Elle a été écrite par quelqu'un qui a quitté l'entreprise, elle référence des outils qui ont changé de version, et elle suppose des accès que la personne d'astreinte n'a pas.

Le point de reprise réel n'est pas celui annoncé. La sauvegarde tourne à deux heures du matin, ce qui signifie que la perte de données maximale n'est pas d'une heure comme indiqué, mais de vingt-quatre heures moins l'heure de l'incident.

Comment mener le test

Dans un environnement isolé, jamais en production, avec un réseau séparé pour éviter qu'une application restaurée n'écrive dans un système réel.

Chronométré, du déclenchement à la disponibilité fonctionnelle vérifiée par un utilisateur métier — pas au moment où la base répond, mais au moment où quelqu'un confirme que les données sont là et correctes.

Par une personne qui n'a pas écrit la procédure. C'est le point qui rend le test utile : il mesure la procédure, pas la connaissance de son auteur.

Avec un scénario réaliste. Restaurer la sauvegarde de la nuit dernière est le cas facile. Restaurer celle d'il y a onze jours, parce qu'une corruption est passée inaperçue une semaine, est le cas qui révèle les vrais problèmes.

Ce qu'il faut en faire

Le chiffre qui sort du test remplace celui du plan de continuité. Si le délai réel est de onze heures et que le métier a besoin de quatre, vous avez un écart à traiter, et vous le savez avant l'incident plutôt qu'après.

Il arrive aussi que l'écart soit acceptable et que ce soit le plan qui soit trop ambitieux. Le corriger vers le haut est un résultat légitime : un plan de continuité honnête vaut mieux qu'un plan flatteur.

La fréquence raisonnable

Une fois par an pour les applications standard, une fois par trimestre pour les applications critiques, et systématiquement après un changement majeur d'architecture ou de fournisseur de sauvegarde.

Inscrivez la date du dernier test réussi dans votre documentation de sécurité. C'est une question que posent tous les questionnaires fournisseurs sérieux, et « nous avons des sauvegardes » n'y répond pas.