Sept façons de s’assurer que l’on peut restaurer une sauvegarde

Quelles sont les clés d’une restauration fiable à partir d’une sauvegarde ?

Les entreprises doivent savoir que leurs sauvegardes fonctionnent, qu’elles peuvent récupérer les données et restaurer les systèmes avec un minimum d’interruption et sans perte ou corruption de données.

Ce sujet se décompose en plusieurs éléments interdépendants. Le plan de sauvegarde et de restauration de chaque entreprise définit l’objectif de délai de restauration (RTO), c’est-à-dire la rapidité avec laquelle les données doivent être récupérées, et l’objectif de point de restauration (RPO), c’est-à-dire jusqu’où l’on est prêt à remonter pour trouver la dernière copie exploitable des données.

Ces paramètres définissent ce à quoi ressemble une récupération réussie pour l’entreprise. Dans le cas des ransomwares, il existe un autre paramètre clé : la possibilité pour l’entreprise de restaurer proprement ses données.

Certains systèmes sont critiques ou doivent être restaurés en premier en raison de leur dépendance à l’égard d’autres applications.

Il ne sert à rien de restaurer les systèmes après une cyberattaque si cela réinfecte les systèmes avec le code du ransomware. Et il se peut que le RPO pour, par exemple, une panne de courant soit différent du RPO pour un ransomware. Tout dépend de la tolérance au risque de l’entreprise.

La fiabilité de la restauration dépend également de l’intégrité des données récupérées. Les fichiers récupérés fonctionnent-ils comme ils le devraient, ou certaines données n’ont-elles pas été restaurées ou encore ont-elles été corrompues ?

Les entreprises doivent également tenir compte de l’ordre dans lequel elles restaurent les données. Certains systèmes sont critiques ou doivent être restaurés en premier en raison de leur dépendance à l’égard d’autres applications. Un test de restauration doit permettre de vérifier que les systèmes sont rétablis dans le bon ordre.

Cela dépend à son tour de l’accès aux supports. Les sauvegardes vers le cloud nécessitent de la bande passante, tandis que les copies locales exigent que les systèmes de sauvegarde soient opérationnels. Les supports de sauvegarde hors site doivent être récupérés et apportés sur place, ou téléchargés sur un système de secours ou sur le cloud.

Les entreprises doivent également vérifier que les systèmes de secours ou de basculement sont opérationnels comme prévu. Cela inclut de la capacité en cloud et des installations de reprise après sinistre, s’il est nécessaire de les utiliser.

Enfin, l’entreprise peut-elle accéder aux services d’appui dont elle a besoin pour récupérer les données ? Il s’agit notamment de l’alimentation électrique et du refroidissement, des communications et du personnel clé. Il ne suffit pas de vérifier que le logiciel de sauvegarde a fonctionné comme prévu.

Comment auditer les processus de sauvegarde ?

Un audit de sauvegarde – ou audit de sauvegarde et de récupération – est un processus formalisé permettant de vérifier que la sauvegarde et la récupération fonctionnent comme il se doit.

Les audits de sauvegarde doivent comprendre des vérifications sur l’emplacement des données et les applications qu’elles supportent, la protection des données existantes et l’emplacement des cibles de sauvegarde. Cela inclut les données conservées dans le cloud et sauvegardées vers celui-ci.

L’audit portera ensuite sur la récupération des données, y compris la conformité aux objectifs RPO et RTO, et examinera la politique et les procédures de sauvegarde ainsi que de récupération de l’entreprise. Cela comprend les critères techniques ainsi que la désignation de la personne qui gérera le processus de récupération.

Il en résultera un rapport assorti de recommandations d’action.

Qu’est-ce que la règle de sauvegarde 3-2-1 ?

La règle des 3-2-1 est une méthode utilisée depuis longtemps pour garantir une protection adéquate des données. Elle stipule que les entreprises doivent conserver trois copies de leurs données, sur au moins deux types de supports ou de systèmes de stockage. Une copie des données doit être hors site.

Il est beaucoup plus facile de respecter la règle des 3-2-1 depuis que le marché offre une pléthore de services de sauvegarde en cloud. Toutefois, dans de nombreux secteurs, la sauvegarde physique hors site reste indispensable, notamment pour se prémunir contre les ransomwares.

Toutes les parties de la règle 3-2-1 doivent être vérifiées pour garantir une restauration efficace et l’intégrité des données.

Comment tester l’intégrité d’une sauvegarde ?

Une sauvegarde est inutile si elle ne parvient pas à être restaurée correctement. Cela peut sembler évident, mais le test de l’intégrité des sauvegardes est un élément essentiel de tout plan de sauvegarde et de récupération ou de continuité des activités.

Les fichiers peuvent être corrompus ou infectés, les supports physiques tels que les bandes magnétiques peuvent se dégrader avec le temps, devenir inaccessibles ou même être détruits lors d’un sinistre. Les services en cloud peuvent devenir indisponibles ou se dégrader, ce qui affecte la capacité à récupérer des données sensibles dans le bon ordre.

Le test de l’intégrité des sauvegardes est un élément essentiel de tout plan de sauvegarde et de récupération ou de continuité des activités.

Les logiciels de sauvegarde utilisent des outils tels que la validation de la somme de contrôle et le hachage pour vérifier la récupération logique. Les fournisseurs ont également introduit des fonctions basées sur l’intelligence artificielle pour rechercher des modèles inhabituels dans les données, afin de repérer les ransomwares et d’autres formes de corruption.

Le seul moyen sûr de tester l’intégrité d’une sauvegarde est d’essayer de la restaurer. Cela pose des problèmes pratiques, notamment lorsqu’il s’agit de restaurer des données sur des systèmes de production critiques qui sont utilisés en permanence. Les équipes informatiques peuvent avoir besoin de tester la restauration un système à la fois, ou sur des machines virtuelles.

Certains fournisseurs ont développé des alternatives. Commvault, par exemple, propose un produit de restauration en « salle blanche » qui permettra aux clients de restaurer les données sur une réplique virtuelle de leur environnement dans le cloud.

Mais il reste essentiel de tester également la restauration sur du matériel physique, en particulier pour les systèmes plus anciens qui ne peuvent pas être facilement répliqués sur des technologies en cloud.

Pourquoi est-il important de tester les procédures de sauvegarde et de restauration ?

Le test des procédures est aussi important que le test de la technologie, mais il est facile de le négliger.

Une grande partie des tests de sauvegarde se concentre à juste titre sur les aspects techniques, comme le fait de savoir si le logiciel de sauvegarde fonctionne comme prévu et si les fichiers de sauvegarde peuvent être récupérés et restaurés.

Mais souvent, lorsque la restauration échoue, c’est pour des raisons non techniques. Dans une situation classique de reprise après sinistre et dans une attaque de ransomware, le personnel est sous pression, les lignes de communication sont perturbées et il est difficile de maintenir le contrôle.

Les procédures doivent être testées de la manière la plus réaliste possible.

Les procédures de sauvegarde et de récupération doivent définir ce qui doit être fait, et quand. Et qui en est responsable. Un plan clair et des procédures solides seront d’une aide précieuse lorsque le pire se produira. Mais cela signifie que les procédures doivent être testées de la manière la plus réaliste possible.

De cette manière, les faiblesses éventuelles peuvent être identifiées et corrigées avant que les procédures ne soient utilisées dans la colère. Les sauvegardes peuvent-elles être trouvées ? Et les systèmes de récupération activés ? Les systèmes se rétablissent-ils dans le bon ordre ? L’environnement de reprise après sinistre – physique ou en cloud – fonctionne-t-il comme prévu ? Et chacun connaît-il son rôle ?

La reprise après sinistre est l’un des cas où il s’agit vraiment d’outils, de processus et de personnes. Tous les éléments doivent être soumis à des tests de résistance.

Quels sont les objectifs des tests de sauvegarde ?

L’objectif principal des tests de sauvegarde est de s’assurer que les fichiers peuvent être restaurés à partir des copies de sauvegarde vers les systèmes de production.

Les tests doivent garantir que les systèmes de production fonctionnent comme ils le devraient après la restauration. Si une entreprise prévoit de basculer vers une configuration de secours dans son propre centre de données, avec un fournisseur de reprise après sinistre ou en cloud, elle doit vérifier que le basculement fonctionne. Et, surtout, qu’elle peut reprendre le système de production le moment venu.

Toutefois, les tests de sauvegarde ne se limitent pas à la question purement technique de savoir si la sauvegarde fonctionne. Comme nous l’avons vu, les entreprises doivent tester leurs procédures générales pour s’assurer que les plans sont exécutés dans le bon ordre, que les communications et le contrôle fonctionnent comme prévu et que chacun connaît son rôle.

Si l’on va plus loin, des tests de sauvegarde complets peuvent en révéler beaucoup plus sur l’état de préparation et la résilience d’une entreprise. Les RPO et RTO, par exemple, sont-ils respectés ? Et s’ils le sont, sont-ils adaptés à l’entreprise ? Les entreprises évoluent et un RTO qui était acceptable il y a cinq ans peut ne plus l’être aujourd’hui.

Les entreprises doivent également tenir compte des exigences réglementaires en matière de continuité des activités et de temps d’arrêt.

À quelle fréquence faut-il tester les restaurations à partir des sauvegardes ?

La réponse est simple : « aussi souvent que possible ». Les tests de sauvegarde et de restauration à grande échelle sont perturbateurs et potentiellement coûteux, et peuvent n’être effectués qu’une fois par an. D’autres tests peuvent être plus fréquents. Il peut s’agir de vérifications ponctuelles sur des applications critiques, ou d’intégrer des tests dans le cadre de mises à jour d’applications, par exemple.

Il se peut que certains systèmes soient testés quotidiennement, mais cela dépendra de la criticité du système, de l’importance de ses données et, bien sûr, de la vision du risque de l’entreprise.