Et si une tornade traversait VOTRE centre de données?

Au cours du week-end dernier, nous avons eu de violentes tempêtes ici en Virginie et bien sûr, la crise au Japon nous rappelle que les choses peuvent mal tourner en un clin d'œil! Une question que je me pose: "Et si une tornade frappait mon centre de données, je suis prêt?"

J'ai d'excellents systèmes de sauvegarde "dans mon rack", y compris une sauvegarde sur bande. Parce que le centre de données n'est pas proche, il n'est pas possible de déplacer des bandes hors site. Ce que j'aimerais trouver ou créer, c'est un système qui, selon un calendrier, peut sauvegarder des éléments critiques tels que des sites Web, des bases de données et les copier à distance, c'est-à-dire mon serveur à la maison. J'ai FIOS avec un service de 35 mbit, j'ai donc le haut débit, ce dont j'ai besoin est le "système" pour le faire. Je suis un programmeur afin que je puisse créer quelque chose qui contienne des informations FTP sur un calendrier, mais je suis curieux de savoir s'il y a quelque chose qui pourrait combler ce besoin de sauvegarde à distance maintenant? Mes serveurs SQL sont sauvegardés sur des matrices de stockage, je pourrais faire baisser ces sauvegardes ou même planifier mon serveur SQL ici pour qu'il se synchronise avec les serveurs de production selon un calendrier. J'utilise Windows Server 2008 R2 et SQL Server 2008 R2.

Que recommandez-vous tous à une stratégie hors site en cas de crise telle qu'une catastrophe naturelle qui met notre centre de données hors service? Es-tu prêt? J'espère que d'autres se poseront cette question et tireront des leçons de ces catastrophes naturelles que nous avons trop souvent vues.

Vos options doivent être dictées par vos accords de niveau de service avec vos clients et limitées par votre budget.

Au minimum, vous devriez avoir des sauvegardes hors site de toutes les données critiques. C'est à ce jour, toutes les données que vous ne pouvez pas recréer à partir de zéro doivent être stockées ailleurs. Les sauvegardes hors ligne sont meilleures: les sauvegardes ou la réplication en ligne peuvent aider lorsqu'une tornade frappe, mais que se passe-t-il si un employé en colère supprime une base de données ou détruit un système de fichiers?

À partir d'une base de sauvegardes hors ligne, vous pouvez commencer à explorer les options qui accéléreront la récupération en échange d'un coût plus élevé. Il existe un grand nombre d'options allant d'un seul hôte pour les sauvegardes en ligne que vous décrivez jusqu'à des environnements complètement répliqués avec une réplication synchrone des données exécutée active (-active) + pour un temps d'indisponibilité proche de zéro.

Vous constaterez que la récupération à partir de zéro est beaucoup plus facile si vous séparez vos données de votre infrastructure aussi soigneusement que possible. Par exemple, la récupération à partir de zéro sera beaucoup, beaucoup plus rapide si vous déployez à l'aide de systèmes tels que marionnette ou chef plutôt qu'à la main. Refaire tout le travail que vous avez mis dans la construction de vos systèmes sera beaucoup plus rapide si vous pouvez automatiser autant que possible. La séparation des données réduit également la quantité de données que vous devez sauvegarder: ne perdez pas des gigaoctets de système d'exploitation si vous n'avez vraiment besoin que de quelques Mo de configurations système et de données d'application.

Les options peuvent devenir assez coûteuses, vous devez donc déterminer ce que votre entreprise est prête à dépenser pour la reprise après sinistre et combien de temps d'arrêt vos clients peuvent tolérer. Éliminez les options trop chères ou trop lentes pour vos clients.

Une fois que vous avez choisi une solution de reprise après sinistre, assurez-vous de la mettre en pratique. Je recommanderais au moins une fois par an ou chaque fois que votre architecture change, selon ce qui se produit le plus souvent.

La continuité des activités va bien au-delà de la simple garantie d'avoir accès à des sauvegardes lisibles. Mais en limitant la portée de la réponse à cela, cela ne sera finalement viable que si la bande passante de bout en bout du centre de données à l'emplacement de sauvegarde est suffisamment grande pour gérer le volume des modifications de données.

Lorsque vous parlez d'un centre de données, pour la plupart des gens, c'est Gigaytes de données par semaine.

IME, même à petite échelle, la meilleure solution est une opération distribuée (ou en miroir). Planifiez-le correctement et il devrait y avoir peu de frais généraux par rapport à un seul centre de données.

Mais si vous devez copier toutes les données vers un emplacement de secours ou même simplement vers un stockage distant, alors

1) N'utilisez pas FTP - c'est juste la mauvaise façon de le faire pour de nombreuses raisons

2) pour les fichiers génériques, utilisez quelque chose comme rsync qui est optimisé à cet effet

3) pour les bases de données, regardez les outils disponibles spécifiquement pour votre SGBD - la structure des fichiers peut changer massivement sans que les données changent beaucoup. NB cela inclut le registre MSWindows et les données MSAD.

Nous avons un VPN de notre bureau à notre centre de données hors site. Au centre de données hors site, nous avons un serveur sur lequel est monté un partage réseau que nous configurons comme destination dans notre logiciel de sauvegarde (nous exécutons Symantec BackupExec), c'est-à-dire \ OFFSITEDATACENTER \ OFFSITESTORAGE

Nous faisons ensuite - une sauvegarde complète au cours du week-end à cet endroit
- un incrémental chaque soir

Ainsi que nos sauvegardes "sur site" normales

Nous exécutons également VMWare VDR pour prendre des images de nos serveurs principaux chaque semaine, qui sont placés sur un disque SATA de 2 To chiffré à l'aide de FreeOTFE que je ramène chez moi chaque semaine.

Nous avons un certain nombre de centres de données actifs / actifs ou actifs / semi-actifs séparés avec> 50 miles entre eux, différents fournisseurs d'énergie, la sécurité, des liens maillés de 10 Go / s diversement routés entre eux, oh et nous expédions également nos disques de sauvegarde entre eux. Cela fait pour nous.

Les spécificités de la gestion d'un certain système de sauvegarde ont été couvertes ad nauseum ici et ailleurs. Je vais aborder cette question d'un point de vue plus élevé des directives générales pour vous aider à décider comment aborder la reprise après sinistre. Je me suis retrouvé dans plusieurs situations où une planification devait être en place au cas où le centre de données deviendrait un cratère fumant. Heureusement, nous n'avons dû l'utiliser qu'une seule fois. Les choses les plus importantes à retenir sont:

1) Ne perdez pas votre temps à essayer de sur-concevoir et à tout faire basculer avec une précision <1 ms si vous n'êtes pas obligé. Un échec complet de cette ampleur excusera généralement quelques heures de récupération.

2) En corollaire au n ° 1, assurez-vous que les attentes sont déterminées de manière réaliste et codées quelque part dans une politique. Il est important d'avoir un objectif fixe à atteindre en ce qui concerne le temps de récupération, car vous pouvez passer un temps illimité et faire des fonds est "encore mieux".

3) Priorisez vos systèmes. Le plan de rétablissement doit être construit autour d'une liste définitive de l'importance de chaque système. Ne manquez pas non plus les choses évidentes, comme obtenir DNS et AD avant le reste des serveurs Windows.

4) Si ce n'est pas hors site ET hors réseau, c'est juste une copie. Cela va parfaitement dans le sens d'une autre chose clé à retenir: RAID n'est pas un plan de sauvegarde.

5) Testez, testez, testez! Testez chaque centimètre de votre plan que vous pouvez. Si vous êtes en mesure de profiter d'un week-end pour une période de maintenance, déconnectez la liaison montante et / ou la puissance du bâtiment et testez le temps de réaction et l'efficacité de votre équipe. Un plan de reprise après sinistre qui n'a jamais été testé n'est qu'un vœu pieux.