Test de restauration des sauvegardes

Le test de restauration des sauvegardes est l'exercice par lequel une entreprise reconstruit, à partir de ses copies, des données ou un système entier, pour vérifier que la sauvegarde sert le jour où il faut repartir. Une sauvegarde jamais restaurée reste une hypothèse. Juin 2017, NotPetya : chez A.P. Møller-Maersk, la reconstruction de l'annuaire a reposé, d'après le récit publié ensuite, sur un contrôleur de domaine resté hors ligne au Ghana à cause d'une coupure de courant. Personne n'avait prévu ce chemin. Le questionnaire cyber demande désormais la fréquence des tests, leur périmètre et la date du dernier. Restaurer un fichier pris au hasard ne dit rien de la reprise d'un hyperviseur, d'un annuaire Active Directory ou d'un progiciel de gestion intégré (ERP). Le souscripteur veut savoir si un système complet a été restauré, dans un environnement isolé, et en combien de temps par rapport à l'objectif de reprise annoncé. Il demande souvent le compte rendu du dernier exercice. Les rançongiciels visent les sauvegardes en premier : l'attaquant cherche la console de sauvegarde, efface ou chiffre les copies, puis lance le chiffrement de la production. D'où le lien avec les sauvegardes immuables et hors ligne, que le test doit couvrir aussi. Un échec de restauration change la nature du sinistre. La perte d'exploitation s'allonge, les frais de reconstitution des données montent, et la pression pour payer la rançon grandit, ce que le marché regarde de près quand il applique une coassurance propre au rançongiciel. Réserve de praticien : les entreprises restaurent volontiers ce qui se restaure bien. Le test qui pèse porte sur l'annuaire et les identités, sans lesquels aucun serveur restauré ne redémarre proprement.