Disaster Recovery auf einer Insel: Lehren aus einer Hurrican-Katastrophe

Ein Hurrikan verwüstete eine Insel, auf der sich zwei Rechenzentren befanden, die geschäftskritische Systeme für ein amerikanisches Biotech-Unternehmen steuerten. Ein Backup-Experte mit vier Jahrzehnten Erfahrung wurde mit einem Firmenjet auf die Insel geflogen, um die Situation zu retten. Die Eigennamen wurden aus Gründen der Anonymität von der Redaktion geändert. [...]

Initech hatte zwei Rechenzentren auf Atlantis mit insgesamt 400 TB Daten, die auf etwa 200 virtuellen und physischen Maschinen liefen. Das Backup-System basierte auf einem führenden Anbieter traditioneller Backup-Software und sicherte auf einem Ziel-Deduplizierungsplattensystem. Jedes Rechenzentrum sicherte auf sein eigenes lokales Deduplizierungssystem und replizierte dann seine Backups auf das Plattensystem im anderen Rechenzentrum. Dies bedeutete, dass jedes Rechenzentrum eine vollständige Kopie aller Initech-Backups auf Atlantis hatte, so dass selbst bei der Zerstörung eines Rechenzentrums das Unternehmen noch über alle Daten verfügen würde.

Initech kopierte diese Backups auch gelegentlich auf Band und lagerte sie auf Atlantis, um sie als Air Gap zu sichern. Sie hätten auch auf dem Festland gespeichert werden können, wurden es aber nicht, und glücklicherweise wurden die Bänder bei der Katastrophe nicht zerstört. Initech hatte in Erwägung gezogen, die Cloud für die Notfallwiederherstellung zu nutzen, fand dies aber aufgrund der Bandbreitenbeschränkungen auf Atlantis unpraktisch.

Als der Hurrikan zuschlug, begann Initech mit der Suche nach jemandem, der den Wiederherstellungsprozess vor Ort leiten sollte. Aufgrund des Ausmaßes der Zerstörung wussten sie, dass sie jemanden brauchten, der die Wiederherstellung auf höchster Ebene durchführen konnte. Es gab nur wenige Leute mit diesen Fähigkeiten bei Initech, und einer von ihnen war Ron. Sie setzten ihn in einen Privatjet und flogen ihn nach Atlantis.

Dort fand er ein unglaubliches Ausmaß an allgemeiner Zerstörung vor, und speziell bei Initech war ein Rechenzentrum überflutet worden, wobei die unterste Reihe der Server in jedem Rack zerstört wurde, während die Server in den oberen Racks unversehrt blieben. Der Wiederherstellungsplan sah vor, die noch funktionierenden Server in das trockene Rechenzentrum zu verlegen und dort alles wiederherzustellen.

Während der Gesamtplan, die Server von einem Ort zum anderen zu transferieren, erfolgreich war, sagte Ron, dass die Eile dazu führte, dass einige Server unsachgemäß behandelt wurden. Das bedeutete, dass es schwieriger war, sie am anderen Ende des Umzugs wieder zusammenzubauen. 

Die größte Hürde, die Ron zu überwinden hatte, war, dass die Internetverbindung zwischen Atlantis und dem Festland aufgrund des Hurrikans vorübergehend unterbrochen war, was ein großes Problem darstellte. Initech hatte die unglückliche Entscheidung getroffen, sich für Dinge wie Active Directory auf dem Festland zu verlassen, anstatt ein separates Active Directory auf Atlantis einzurichten. Das bedeutete, dass alle AD-Abfragen direkt an das Festland gehen mussten, das nun nicht mehr erreichbar war. Das bedeutete, dass sie sich nicht bei den Systemen anmelden konnten, die sie für die Wiederherstellung benötigten.

Es wurden mehrere Optionen ausprobiert, angefangen mit satellitengestütztem Internet. Dies ermöglichte zwar eine gewisse Konnektivität, aber die tägliche Bandbreitenzuteilung war erschöpft, woraufhin der Satelliten-ISP die Verbindung drosselte. Sie versuchten auch eine Richtfunk-Verbindung zu einem anderen ISP. Dabei handelte es sich um ein mehrstufiges Richtfunk-Relais, so dass ein Stromausfall in einem der Gebäude im Relais einen weiteren vorübergehenden Ausfall verursachen konnte. Es stellte sich heraus, dass es wirklich schwierig ist, eine stabile Netzwerkverbindung zu realisieren, wenn die Infrastruktur, auf die sich diese Netzwerkverbindung stützt – Gebäude und Strom – nicht stabil ist.

Die eigentliche Wiederherstellung erwies sich als der einfache Teil. Sie war sicherlich nicht schnell, aber sie hat funktioniert. Der gesamte Prozess der Wiederherstellung eines Rechenzentrums in einem anderen dauerte etwas mehr als zwei Wochen. 

Die verwendete Backup-Software sicherte VMware auf Hypervisor-Ebene, so dass die Wiederherstellung der über 200 VMs relativ einfach war. Die Wiederherstellung der wenigen physischen Server, die eine Bare-Metal-Wiederherstellung benötigten, erwies sich als etwas schwieriger. Windows ist zwar ziemlich nachsichtig, aber manchmal funktionieren die Dinge einfach nicht, und es braucht viele zusätzliche Schritte, die man manuell durchführt. 

Lehren aus der Katastrophe

Die erste Lektion aus dieser Katastrophe ist eine der tiefgreifendsten: So wichtig Backup- und Wiederherstellungssysteme auch sind, sie stellen vielleicht nicht die schwierigsten Herausforderungen bei einer Disaster Recovery dar.  Einen Ort für die Wiederherstellung und ein Netzwerk zu bekommen, das genutzt werden kann, kann sich als viel schwieriger erweisen. Dies ist jedoch kein Grund, beim Backup-Design nachzulassen. Es geht darum, dass zumindest die Backups funktionieren, wenn sonst nichts mehr geht.

Lokale Konten, die nicht auf Active Directory angewiesen sind, wären ein guter Anfang. Dienste wie Active Directory, die zum Starten einer Wiederherstellung notwendig sind, sollten zumindest eine lokal zwischengespeicherte Kopie des Dienstes haben, die auch ohne Internetverbindung funktioniert.  Eine komplett separate Instanz eines solchen Dienstes wäre wesentlich ausfallsicherer.

Üben Sie groß angelegte Disaster Recoveries so gut wie möglich und stellen Sie sicher, dass Sie wissen, wie Sie diese ohne eine grafische Benutzeroberfläche durchführen können. Die Möglichkeit, sich über SSH bei den Servern anzumelden und Wiederherstellungen über die Kommandozeile auszuführen, ist energieeffizienter und flexibler. So fremd das vielen Leuten auch erscheinen mag, eine Wiederherstellung über die Kommandozeile ist oft der einzige Weg, um weiterzukommen. Auf Atlantis war der Stromverbrauch sehr hoch, so dass die Verwendung des Stroms für die Monitore nicht wirklich eine Option war. 

Zusätzliche Hardware kann besonders hilfreich sein. Ein Problem bei der Wiederherstellung im Katastrophenfall ist, dass die Systeme, sobald sie wiederhergestellt sind, gesichert werden müssen. Aber bei einer Wiederherstellung wie dieser haben Sie nicht unbedingt eine Menge zusätzlicher Hardware, die für Backups verwendet werden kann. Die Hardware, die Sie haben, arbeitet sehr hart daran, andere Systeme wiederherzustellen, also möchten Sie sie nicht mit der Aufgabe betrauen, die Systeme zu sichern, die Sie gerade wiederhergestellt haben. Die Cloud könnte hier hilfreich sein, aber das war in diesem Fall keine Option.

Sie müssen planen, wie Sie Ihre Server während und nach der Disaster Recovery sichern, während Ihr primäres Sicherungssystem mit der Wiederherstellung beschäftigt ist. Initech löste dies mit seiner Bandbibliothek. Vor der Katastrophe verwendete Initech Bänder, um eine Kopie der Backups an einen sicheren Ort außerhalb des Unternehmens zu bringen. Das primäre Festplattensystem wurde für die Wiederherstellung voll ausgelastet, so dass man etwas für die tägliche Sicherung der neu wiederhergestellten Server benötigte. Sie deaktivierten den Offsite-Bandkopie-Prozess und leiteten ihre Produktions-Backups vorübergehend auf die Bandbibliothek, die zuvor nur zur Erstellung einer Offsite-Kopie verwendet worden war. Eine gute Sache bei Bändern ist, dass sie eine praktisch unbegrenzte Kapazität haben, solange man genügend zusätzliche Bänder herumliegen hat. Außerdem sind sie viel kostengünstiger als eine Menge zusätzlicher Festplatten. Angesichts der Kapazität des Initech-Rechenzentrums würde sie weniger als 1000 Dollar kosten. Die Lektion ist jedoch, dass Sie planen müssen, wie Sie Backups machen, während Sie eine große Wiederherstellung durchführen.

Die automatische Einbindung von Backups ist der Weg der Wahl. Alle modernen Backup-Softwarepakete haben die Möglichkeit, alle VMs und alle Laufwerke auf diesen VMs zu sichern, aber nicht jeder nutzt diese Funktion. Initech hat – wie viele andere Unternehmen auch – versucht, etwas Geld zu sparen, indem nur bestimmte Dateisysteme in das Backup aufgenommen wurden. Das bedeutete, dass sie eine Reihe wichtiger Dateisysteme ausließen, weil sie nicht manuell ausgewählt worden waren. Lektion: Nutzen Sie die Fähigkeit Ihrer Backup-Software, alles automatisch zu sichern. Wenn Sie wissen, dass etwas kompletter Müll ist, können Sie es manuell ausschließen. Aber manuelle Ausschlüsse sind viel sicherer als das manuelle Inklusions-Verfahren, das Initech für einige seiner Systeme gewählt hat.

Sie müssen eine Lösung finden, wo Ihre Disaster Recovery-Leute schlafen! Bei einer großen Katastrophe gibt es keine Hotelzimmer, also planen Sie im Voraus und stellen Sie sicher, dass Sie vor Ort die Möglichkeit haben, Ihre IT-Mitarbeiter unterzubringen und zu ernähren, die für eine ganze Weile in diesem Gebäude leben werden. Ron wurde gesagt, er solle seinen Schlafsack mitbringen, aber es sollten brandneue Schlafsäcke, aufblasbare Matratzen und Toilettenartikel vor Ort verfügbar sein. Außerdem sollten Sie sich um Notrationen für Lebensmittel kümmern. Initech war in der Lage, Ron und seine Kollegen zu verpflegen, aber es war sicherlich nicht einfach. Der Kauf und die Pflege dieser Vorräte ist ein kleiner Preis dafür, dass Ihre Recovery-Crew ausgeruht und wohl ernährt bleibt.

DR-Tests, die nur einen Teil der Katastrophe testen, sind völlig unzureichend, um zu simulieren, wie eine echte Katastrophe aussehen wird. Es ist schwer, eine vollständige Disaster Recovery zu testen, aber hätte Initech tatsächlich einen solchen Test durchgeführt, hätte es einige ungenaue Annahmen über eine tatsächliche Wiederherstellung identifizieren können. Je mehr man testet, desto mehr weiß man.

Selbst wenn Sie einen vollständigen DR-Test durchführen, wird die reale Situation anders sein. Dies gilt insbesondere, wenn Sie es mit einer Naturkatastrophe zu tun haben, die Ihr Rechenzentrum überflutet, in Brand setzt oder sogar in die Luft sprengt. Sie können Ihr Bestes tun, um all diese Szenarien zu berücksichtigen, aber letztendlich brauchen Sie auch Leute, die auf das Unerwartete vor Ort reagieren können. In diesem Fall schickte Initech einen erfahrenen Veteranen, der sich als genau die richtige Person für die Situation erwies. Er und die anderen IT-Mitarbeiter kamen mit der Situation zurecht und fanden einen Weg, das Problem zu lösen. Auch mit all den modernen IT-Systemen, die zur Verfügung stehen, sind Menschen immer noch Ihr bestes Kapital.

Ein Denkanstoß

Einige Fragen, die Sie bei der Planung der Disaster Recovery berücksichtigen sollten:

• Gibt es fehlerhafte Annahmen in Ihrem Backup-Design?
• Haben Sie sich mit alternativen Kommunikationssystemen beschäftigt, falls Ihre Hauptverbindung ausfällt?
• Wissen Sie, wo Sie eine Reihe von IT-Mitarbeitern unterbringen würden, die sich in unmittelbarer Nähe zu Ihrem Rechenzentrum aufhalten müssen?
• Wie zuversichtlich sind Sie hinsichtlich Ihrer Fähigkeit, eine solche Katastrophe zu überstehen?

Wenn Sie keine guten Antworten auf diese Fragen haben, sind vielleicht ein paar Zoom-Sitzungen angesagt. 

*W. Curtis Preston ist Redakteur von Network World.