Les deux datacenters d’Initech hébergeaient pas moins de 400 Térabytes de données utilisées par environ 200 machines virtuelles et physiques. Le système de sauvegarde était basé sur un logiciel de sauvegarde traditionnel de premier plan, et il était sauvegardé sur un système de disques de déduplication cible. Chaque datacenter effectuait la sauvegarde sur son propre système de déduplication local, puis répliquait ses sauvegardes sur le système de disques de l'autre datacenter. Cela signifie que chaque datacenter conservait une copie complète de toutes les sauvegardes d'Initech, de sorte que, si un datacenter était détruit, l’entreprise aurait toujours la totalité de ses données. Initech copiait aussi occasionnellement ces sauvegardes sur bande et les stockait hors site, mais sur l’île, pour des raisons d’éloignement. Les bandes auraient pu être stockées sur le continent, mais ne l'ont pas été : heureusement qu’elles n'ont pas été détruites lors de la catastrophe, mais cela aurait pu arriver. L’entreprise de biotechnologie avait envisagé d'utiliser le cloud pour la reprise après sinistre, mais elle a estimé la solution peu pratique en raison des limitations de bande passante sur l’île.

Quand l'ouragan a frappé, Initech a commencé à chercher quelqu'un sur place pour prendre en charge le processus de récupération. Mais compte tenu de l’importance des dégâts, l’entreprise savait qu’elle avait besoin d’une personne capable de maîtriser la reprise avec des commandes en ligne. Chez Initech, seules quelques personnes avaient ce niveau de compétence, et notamment Ron, envoyé sur place en jet privé. Là-bas, il a constaté l’incroyable niveau de destruction, en particulier, dans les bâtiments d’Initech. L’un des datacenters avait été inondé : la première rangée de rack de tous les serveurs était sous l’eau, mais les racks supérieurs étaient intacts. Le plan de récupération consistait à déplacer les serveurs qui fonctionnaient encore vers le datacenter qui n’avait pas été inondé, et de tout récupérer là-bas. Même si globalement le transfert des serveurs d'un endroit à l'autre s’est bien passé, Ron a déclaré que, dans la précipitation, certains serveurs avaient subi des dommages et qu’il avait eu du mal à les remonter.

Lien sous-marin indispensable

Mais c’est la connexion Internet entre l’île et le continent qui a posé le plus de problèmes à l’expert. Celle-ci avait été temporairement désactivée à cause de l'ouragan, et Ron s’est retrouvé face à un problème majeur. L’entreprise avait pris la malheureuse décision d’exécuter les tâches Active Directory sur le continent, au lieu d’installer un Active Directory séparé sur ses datacenters distants. Si bien que toute requête AD devait être envoyée sur le continent, désormais inaccessible. Et donc, Ron ne pouvait pas se connecter aux systèmes qu'il devait utiliser pour lancer la récupération. Avec son équipe, il a essayé plusieurs options, à commencer par l'Internet par satellite. Même s’ils ont pu retrouver une forme de connectivité, ils ont constaté qu'ils étaient limités dans leur allocation quotidienne de bande passante, et qu’au-delà, le fournisseur d'accès Internet par satellite réduisait leur connexion. Ils ont également essayé une connexion par micro-ondes avec un autre fournisseur d'accès. Mais avec ce système de relais micro-ondes à plusieurs étages, la perte de puissance au niveau de l’un des relais pouvait provoquer une autre panne temporaire. Il s'avère qu'il est très difficile d'avoir une connexion réseau stable quand l'infrastructure - bâtiments et alimentation - sur laquelle repose cette connexion réseau, n'est pas stable.

Finalement, la restauration proprement dite a été la phase la plus facile de l’opération. Elle n'a certainement pas été rapide, mais elle a fonctionné. Le processus complet de restauration d'un datacenter à l’autre a pris un peu plus de deux semaines. Vus les dégâts occasionnés sur l’île, la performance est assez impressionnante. Le logiciel de sauvegarde qu'ils ont utilisé sauvegardait VMware au niveau de l'hyperviseur, si bien que la restauration des plus de 200 machines virtuelles a été relativement simple. La restauration des quelques serveurs physiques qui nécessitaient une restauration bare-metal s'est avérée un peu plus difficile. Si vous n'avez jamais effectué de restauration bare-metal sur un hardware différent, il suffit de dire que l’opération peut être compliquée. Windows est assez indulgent, mais parfois les choses ne fonctionnent pas et il est nécessaire de réaliser de nombreuses étapes supplémentaires manuellement. Ces récupérations ont été la partie la plus difficile de la restauration.

Quelles leçons tirer de cette catastrophe ?

La première leçon, et la plus significative, à tirer de cette catastrophe est la suivante : aussi importants que soient les systèmes de sauvegarde et de récupération, ce ne sont pas eux qui posent les défis les plus difficiles à relever dans le cadre d'une reprise après sinistre. Il peut s'avérer beaucoup plus difficile de trouver un nouveau lieu de récupération et un réseau. Ce n'est pas une raison pour négliger ses stratégies de sauvegardes. Au contraire, c’est plutôt rassurant dans ce genre de situation de savoir qu'au moins les sauvegardes fonctionnent quand rien d'autre ne fonctionne. Prévoir des comptes locaux qui ne reposent pas sur Active Directory serait un bon début. Les services comme Active Directory, nécessaires pour lancer une récupération, devraient avoir au moins une copie en cache local du service qui fonctionne sans connexion Internet. Une instance complètement distincte d'un tel service serait beaucoup plus résistante. Répétez les récupérations à grande échelle du mieux que vous pouvez, et assurez-vous également que vous savez comment les faire sans interface graphique. La possibilité de se connecter aux serveurs via SSH et d'exécuter des restaurations en ligne de commande est plus efficace et plus souple. Aussi inhabituel que cela puisse paraître à beaucoup, une récupération en ligne de commande est souvent la seule façon d'avancer. Sur l’île, l’accès au réseau électrique était limité, donc il ne fallait pas trop compter dessus pour alimenter les moniteurs. Avoir du matériel supplémentaire peut s’avérer aussi très utile. L'un des problèmes de la reprise après sinistre, c’est que dès que vous récupérez vos systèmes, ils doivent être sauvegardés. Mais dans ce genre de situation, vous n'avez pas nécessairement beaucoup de matériel en surplus à votre disposition pour les sauvegardes. Le matériel dont vous disposez travaille déjà très dur pour restaurer d'autres systèmes, et vous ne voulez pas, en plus, lui confier la tâche de sauvegarder les systèmes que vous venez de restaurer. Le cloud pourrait être utile dans ce cas, mais Ron n’avait pas cette possibilité.

Il faut prévoir comment sauvegarder ses serveurs pendant et après la reprise d'activité, pendant que le système de sauvegarde principal est mobilisé pour effectuer la restauration. L’entreprise de biotechnologie a résolu ce problème grâce à sa bibliothèque de bandes. Avant le désastre, Initech dupliquait ses sauvegardes sur bandes et les entreposait dans un endroit sûr hors site. Le disque principal était utilisé à pleine capacité pour effectuer la restauration, Ron et son équipe avaient donc besoin d’un support pour effectuer la sauvegarde quotidienne des serveurs nouvellement restaurés. Ils ont désactivé le processus de copie sur bande hors site et ont temporairement redirigé leurs sauvegardes de production vers la bibliothèque de bandes qui n'avait été utilisée antérieurement que pour créer une copie hors site. L'avantage des bandes, c’est qu'elles ont une capacité pratiquement illimitée tant qu'il y a suffisamment de bandes à disposition. Il est aussi plus avantageux d'avoir des bandes en excès plutôt que beaucoup de disques supplémentaires. Étant donné la capacité du datacenter d'Initech, le coût des bandes supplémentaires pour gérer les sauvegardes pendant quelques semaines s’élevait à moins de 1000 dollars. Mais la leçon essentielle à tirer, c’est de prévoir à l’avance la solution de sauvegarde que vous utiliserez si vous avez besoin de faire une restauration majeure.

Plus d'infrastructures

La sauvegarde automatique est la vraie solution. Tous les logiciels de sauvegarde modernes ont la capacité de sauvegarder toutes les machines virtuelles et tous les disques de ces machines, mais tout le monde n'utilise pas cette fonction. Comme beaucoup d'entreprises, l’entreprise de biotechnologie américaine a essayé de faire des économies en n'incluant que certains systèmes de fichiers dans sa sauvegarde. Cela signifie qu'ils ont perdu un certain nombre de systèmes de fichiers importants parce qu'ils n'avaient pas été sélectionnés manuellement. Un conseil : utilisez la fonction de sauvegarde automatique de la totalité de vos données, proposée par votre logiciel. Si la sauvegarde de certaines données est complètement inutile, vous pouvez l'exclure manuellement. Mais les exclusions manuelles sont bien plus sûres que l’approche par inclusion manuelle choisie par Initech pour certains de ses systèmes. 

Vous devez également prévoir une solution pour héberger l’équipe de récupération ! En cas de sinistre majeur comme celui-ci, il peut ne pas y avoir d'hôtel. Alors, planifiez à l'avance et assurez-vous que vous avez les moyens de loger, soigner et nourrir le personnel IT qui va devoir vivre dans le bâtiment pendant un certain temps. Ron a dû prendre son propre sac de couchage… Ça aurait été mieux si Initech avait prévu des sacs de couchage, des matelas gonflables et des affaires de toilette pour son équipe. Et il ne faut pas oublier les rations alimentaires d'urgence. Cela n’a certainement pas été facile, mais Initech a pu nourrir Ron et ses collègues. L'achat de ces fournitures ne représente pas grand-chose. Il est important que l’équipe de récupération puisse se reposer et se nourrir.

Les tests ne suffisent pas 

Les tests de reprise après sinistre qui ne testent qu'une partie des dégâts sont totalement inadéquats pour simuler ce qui se passe en cas de catastrophe réelle. Il est difficile de tester une récupération complète après sinistre, mais si Initech avait pu réellement faire ce test, elle aurait constaté que certaines hypothèses ne se vérifiaient pas dans le cadre de cette récupération réelle. Plus vous testez, plus vous en savez. Enfin, un test de performance ne permet pas de prédire la performance réelle. Même si vous effectuez un test complet de reprise après sinistre, la réalité sera différente. C'est particulièrement vrai si vous êtes confronté à une catastrophe naturelle comme une inondation, un incendie ou l’explosion de votre datacenter. Vous pouvez faire de votre mieux pour essayer de tenir compte de tous ces scénarios, mais en fin de compte, ce dont vous avez également besoin, ce sont des personnes capables de réagir à l'inattendu sur le terrain. Dans le cas d’Initech, elle a pu envoyer une personne très expérimentée qui s'est avérée la bonne personne pour la situation d’urgence à laquelle elle était confrontée. Lui et les autres informaticiens qui ont travaillé avec lui ont encaissé les coups et trouvé des solutions. Tous les systèmes informatiques modernes n’auraient pu les remplacer. Les gens restent votre meilleur atout.

En guise de réflexion

Voici quelques questions à se poser au moment de la planification d’une reprise après sinistre : La conception de votre sauvegarde se base-t-elle sur des hypothèses erronées ? Avez-vous envisagé d'autres systèmes de communication au cas où votre connexion principale serait coupée ? Savez-vous si vous pourrez héberger les équipes d’informaticiens à proximité de votre datacenter si nécessaire ? Pensez-vous pouvoir mener à bien une reprise après sinistre en cas de catastrophe ?