Presque toutes les entreprises savent qu’il est essentiel d’avoir un plan de reprise après sinistre (DR). Cependant, il est tout aussi important de tester vos plans de reprise après sinistre, et toutes les entreprises ne suivent pas ce point. Dans cet article, je vais détailler cinq scénarios de test de reprise après sinistre essentiels que votre organisation devrait envisager pour garantir que ses plans de reprise après sinistre fonctionneront au moment où ils seront le plus nécessaires.
Table des matières
Il existe de nombreuses raisons pour lesquelles les entreprises sont à la traîne dans les tests de reprise après sinistre. Le processus de test n’est pas amusant, il nécessite beaucoup de ressources et enlève des ressources à d’autres initiatives commerciales en cours. Certaines entreprises notables comme Google effectuent régulièrement des tests de reprise après sinistre complets où elles déplacent l’intégralité de leurs charges de travail de production vers leur infrastructure de sauvegarde, puis les déplacent plus tard.
C’est évidemment plus que ce que la plupart des entreprises ont besoin de faire. Heureusement, la plupart des entreprises peuvent tester périodiquement différents composants de leurs plans de reprise après sinistre. Jetons un coup d’œil aux scénarios de test les plus essentiels que toutes les organisations devraient effectuer.
Scénario de test de reprise après sinistre n° 1 : Communication avec les membres critiques de l’équipe de DR
L’un des plus simples mais le plus souvent Les aspects ignorés des tests de reprise après sinistre sont la capacité de communiquer avec les différents membres de l’équipe qui font partie de votre plan de reprise après sinistre. L’impossibilité de contacter les membres de votre équipe DR rendra rapidement tout plan inefficace.
Ici, vous devez vous assurer que vous disposez d’informations de contact mises à jour et à jour, y compris les numéros de téléphone, les e-mails, les SMS et les identifiants de contact Microsoft Teams/Slack/Zoom.
Une communication efficace est un aspect clé de la catastrophe récupération
Scénario de test de reprise après sinistre n° 2 : panne matérielle simulée
Sans aucun doute, la restauration du matériel défaillant est au cœur de tous les plans de reprise après sinistre. Les pannes matérielles peuvent résulter d’une variété de composants différents, et le scénario le plus courant est une panne de disque dur.
Dans ce type de test, vous devez être en mesure de basculer vos programmes et services à partir de votre plate-forme informatique principale. à une plate-forme informatique de sauvegarde-il peut s’agir d’une plate-forme sur site, en colocation ou basée sur le cloud, mais des sauvegardes hybrides sur le cloud sont également possibles.
Cette plate-forme de sauvegarde peut être un autre site sur site qui se trouve dans un emplacement différent, ou il peut être dans le cloud. Dans les deux cas, le point de test clé est que vous disposez d’une plate-forme informatique alternative pour exécuter vos services critiques.
Scénario de test de reprise après sinistre n° 3 : échec simulé du système d’exploitation et de l’application
Le suivant La facette de reprise après sinistre la plus importante à tester est la défaillance du système d’exploitation et de l’application. Les défaillances du système d’exploitation et des applications peuvent également être causées par un large éventail d’événements, notamment des mises à jour logicielles et des modifications de configuration ou de programmation qui ont mal tourné. Bien que cela soit moins courant que les pannes matérielles, il est un peu plus facile à tester car vous n’avez pas besoin d’utiliser une autre couche matérielle sous-jacente.
Pour tester votre capacité à récupérer après une défaillance du système d’exploitation et des applications, vous devez être en mesure de restaurer votre système d’exploitation et vos applications à l’aide de sauvegardes, d’instantanés ou d’une cible de réplication. Une partie de ce processus doit inclure la vérification que votre sauvegarde est terminée avec succès et que le support de sauvegarde est utilisable.
Tester la défaillance du système d’exploitation et des applications est un scénario de reprise après sinistre important
Scénario de test de reprise après sinistre n° 4 : Panne de réseau
De nos jours, la connectivité du réseau et du cloud Internet est presque aussi importante que vos propres ressources sur site. La majorité des entreprises utilisent différents types de services cloud pour leurs applications critiques, sans parler de leurs besoins de connectivité interentreprises (B2B).
Une panne de réseau peut être tout aussi perturbatrice qu’une panne matérielle, en particulier dans cette ère post-pandémique où tant d’utilisateurs se connectent à distance. Vous devez tester pour voir que vous disposez de connexions réseau de secours fonctionnelles et éventuellement effectuer des tests qui peuvent simuler des attaques réseau. En outre, vous devez tester et vérifier vos outils de surveillance du réseau.
Scénario de test de reprise après sinistre #5 : Perte de données
Dernier point mais non des moindres, un autre scénario critique que vous devez tester car c’est la perte de données. La perte de données peut être causée par un certain nombre de facteurs différents, allant des pannes matérielles ou logicielles aux rançongiciels et autres attaques de logiciels malveillants.
Dans ces tests, vous devriez être en mesure de restaurer à la fois des fichiers individuels ainsi que des volumes de disque entiers. Pour une protection supplémentaire contre les rançongiciels ou les logiciels malveillants, vous devez disposer d’un ensemble de sauvegardes sauvegardées qui vous pouvez tester et vérifier.
Les sauvegardes isolées protègent contre les ransomwares qui ciblent les sauvegardes en ligne. Elles sont séparées de votre réseau de production et nécessitent généralement des identifiants d’authentification différents.
Résumé
Tous les tests DR que vous effectuez doivent être documentés. Vous devez vous assurer d’enregistrer la durée des procédures de récupération et si vous respectez l’objectif de temps de récupération (RTO) et objectif de point de récupération (RPO) ou non. Si des problèmes ou des problèmes sont rencontrés, ils doivent être notés et vous devez envisager de modifier vos procédures de récupération si cela est approprié.
Des tests réguliers de ces scénarios de reprise après incident vitaux peuvent garantir que vous pouvez restaurer les éléments critiques de votre entreprise. Services informatiques en cas de ces types courants de pannes.