Konzept zur Krisenbewältigung Disaster Recovery im Rechenzentrum

Autor / Redakteur: Pierre Gronau* / Ulrike Ostler

Ein Desaster macht aus, dass es sich im Vorfeld nicht ankündigt. Als katastrophales Ereignis trifft es eine Gemeinschaft, die Wirtschaft und/oder ein Ökosystem plötzlich. Auch ein Rechenzentrum funktioniert wie ein Ökosystem.

Firmen zum Thema

Daten-GAU: Desaster kommen unangekündigt. Gegen Datenverlust hilft nur ein geeignetes Disaster-Recovery-Konzept.
Daten-GAU: Desaster kommen unangekündigt. Gegen Datenverlust hilft nur ein geeignetes Disaster-Recovery-Konzept.
(Bild: Olivier Le Moal - stock.adobe.com)

Wird ein Rechenzentrum von einer Katastrophe heimgesucht, die Strukturen und Daten ernsthaft stört und damit materielle und wirtschaftliche Verluste verursacht, übersteigt dies die Fähigkeit des Betreibers, sie mit eigenen Ressourcen zu meistern. Was zählt, ist eine effektive und situationsgetriebene Krisenbewältigung.

Ein gutes Konzept zur Krisenbewältigung, das Spielraum für Improvisation lässt – so lautet das Erfolgsrezept. Ein Rezept, das die thailändische Festplattenindustrie anwendete, als 2011 starker Regen einsetzte und Fabriken sintflutartig unter Wasser setzte. Als klar wurde, dass aufgestapelte Sandsäcke um die Anlage des Herstellers Western Digital nicht mehr ausreichten, schlossen sich die Technikunternehmen vor Ort flink zusammen und beauftragten thailändische Marinetaucher, die Werkzeuge zur Herstellung von Festplattenlaufwerken zu bergen.

Beim Auftragsfertiger Benchmark Electronics fertigten die Mitarbeiter Flöße aus Blech, die sie einsetzten, um den Bestand aus dem Werk zu entfernen. Jede geborgene Maschine wurde demontiert, dekontaminiert und wieder zusammengesetzt. Durch das schnelle koordinierte Improvisieren war die thailändische Branche für PC-Komponenten viel schneller wieder am Markt, als Analysten dies vorhergesagt hatten.

Und im Rechenzentrum? Blitzeinschläge, erschöpfte LKW-Fahrer, ein einziges Eichhörnchen – die Liste bekannter und überraschender Brandzünder für Katastrophen im Rechenzentrumsbetrieb ist lang. Sie alle eint die erforderliche Konsequenz: Eine Notfallwiederherstellung, im englischen „Disaster Recovery“ (DR) genannt, muss her. Ein solcher Masterplan bündelt zwingend alle Maßnahmen, die Sicherheitsverantwortliche nach einem Komponentenausfall in IT-Systemen ergreifen.

Weitermachen wie gewohnt?

Noch vor der Zerstörung von Hardware ist Datenverlust das Schlimmste, was einem Betrieb passieren kann. Jedes Unternehmen verfügt über eine individuelle Geschäftsstrategie und eine sich daraus ableitende IT-Sicherheitsstrategie, die Datenverfügbarkeit und Datensicherheit unterschiedlich hoch priorisiert und daraus Normalzustände für den IT-Betrieb definiert.

Noch vor der Zerstörung von Hardware ist Datenverlust das Schlimmste, was einem Betrieb passieren kann.
Noch vor der Zerstörung von Hardware ist Datenverlust das Schlimmste, was einem Betrieb passieren kann.
(Bild: Gronau IT Cloud Computing GmbH)

Im links abgebildeten Zeitstrahl markieren die grünen Punkte den gewohnten, vom Unternehmen akzeptierten Status im Rechenzentrumsbetrieb. Zum Zeitpunkt X tritt durch Umwelteinflüsse, menschliches oder technisches Versagen die Katastrophe ein. Diese kann, wenn sie sich nicht zum Beispiel in Form eines Blitzeinschlags oder einer Überschwemmung klar zu erkennen gibt, für einen gewissen Zeitraum unbemerkt weiter wirken.

Man denke hier an Eichhörnchen, die sich genüsslich über die Ummantelung von Kabeln hermachen, ohne hierbei für Aufsehen zu sorgen. Schleichend verschlechtert sich die Performance.

In diesem Zeitfenster des Undercover-Desasters bemühen sich die IT-Mitarbeiter darum, die Hochverfügbarkeit der Daten mit gewohnten Bordmitteln aufrechtzuerhalten. Sobald klar ist, dass dies nicht mit Leichtigkeit gelingen kann, gilt der GAU als erkannt. Die Katastrophe ist bemerkt, aber das um Sicherheit und wenig Lärm bemühte IT-Team versucht weiterhin, Herr der Lage zu werden.

Keine Katastrophe von Anfang an

Sind alle internen Strategien ausgereizt, muss die Katastrophe dem Management gemeldet werden. Wir sprechen hier vom „Disaster Announcement“, das einen Wendepunkt markiert. Der Verantwortliche informiert die Geschäftsführung, dass eine Katastrophe vorliegt, die er alleine nicht bewältigen kann, und dass weitere Maßnahmen ergriffen werden müssen.

Bezogen auf den Rechenzentrumsbetrieb, steht folgende Managemententscheidung an: Wir schalten das Rechenzentrum um. Damit beginnt die Wiederherstellungsphase. Sowohl die IT-Systeme als auch die Daten aus der letzten funktionierenden Datensicherung müssen wieder in Betrieb genommen werden. Am Ende dieses zeitlichen Ablaufs steht die Wiederaufnahme der Produktion oder des gewohnten Geschäftsbetriebs.

Disaster Recovery: ein Drama in vier Akten

Am Ende dieses zeitlichen Ablaufs steht die Wiederaufnahme der Produktion oder des gewohnten Geschäftsbetriebs.
Am Ende dieses zeitlichen Ablaufs steht die Wiederaufnahme der Produktion oder des gewohnten Geschäftsbetriebs.
(Bild: Gronau IT Cloud Computing GmbH)

1. Akt – Wunsch und Wirklichkeit: Kommen wir zurück zur IT-Sicherheitsstrategie, die jedem datenverarbeitenden Unternehmen als Konzept vorliegen sollte. Ein Konzept, das sich wiederum an den unternehmensspezifischen Maximen für Datenverfügbarkeit, Datensicherheit und Wirtschaftlichkeit orientiert.

Wie lange darf uns eine Katastrophe aus wirtschaftlicher Sicht ausknocken? Das ist die zentrale Frage, die sich die Geschäftsführung beantworten muss. Hier greift für Disaster Recovery der Begriff „Maximum Acceptable Outage“ (MAO) aus der Betriebswirtschaftslehre. Er bezeichnet die maximale Ausfallzeit für Geschäftsprozesse oder Servicefunktionen, die das Unternehmen akzeptieren kann, bevor geschäftskritische Konsequenzen drohen.

So definiert ein Versicherungskonzern als fiktives Beispiel maximal 24 Stunden Datenverlust als Risiko und begrenzt die höchstmögliche Wiederherstellungszeit auf drei Tage. Damit MAO kein Hoffnungsszenario bleibt, sondern die Realität widerspiegelt, muss das Konzept Umfang und Kosten aller Maßnahmen klar benennen.

2. Akt – Daten sichern und Daumen drücken: Im Rahmen von DR spielt der Begriff „Recovery Point Objective“ (RPO) eine große Rolle. Er meint die Zeitspanne zwischen dem letzten Backup und dem maximal entfernt liegenden Zeitpunkt, bis zu dem Daten aufgrund eines Ausfalls verloren sein dürfen.

Auch RPO ist akzeptanzgetrieben und variiert: Je höher Datenverfügbarkeit und Datensicherheit im Unternehmen aufgehängt sind, desto schmaler ist die RPO. Ist gar kein Datenverlust bei einem Systemausfall tolerabel, beträgt die RPO demnach null Sekunden.

3. Akt – Basis bereiten: Ist eine Katastrophenmeldung beim Management angekommen, folgen laut Zeitstrahl Maßnahmen zur Wiederherstellung des Geschäftsbetriebs. Zum Startpunkt der Wiederherstellung (im Zeitstrahl gelb markiert) steht der Umfang des potenziellen Datenverlustes fest, der nach dem Ereignis aufgetreten ist.

Nun wird aufgeräumt: Die Phase „Recovery Time Objective“ (RTO) meint nach Verständnis von Gronau IT exakt die Wiederherstellungszeit, in der Geschäftsfunktionen, Systeme und IT-Services so vorbereitet sind, dass die IT-Mitarbeiter ihr Wiederherstellungsverfahren einleiten können.

4. Akt – Neustart: In der nächsten und finalen Etappe folgt die „Work Backlog Recovery“ (WBL), also die aufwandreiche Zeit zur Wiederherstellung des Ursprungszustands. Dazu gehören alle Arbeiten, die Transaktionen und Daten aus der Pre-Desaster-Ära wiederherstellen. Eine Aufräumzeit, die unterschiedlich lange dauert und zu deren Ende alle Daten wieder aufgespielt sind und dem Business wieder zur Verfügung stehen.

Rechenzentrumswahl als Risikominimierung

Disaster Recovery ist eine Teildisziplin von Business Continuity Management (BCM), also eines Prozesses, der Konzepte zur Aufrechterhaltung des Geschäftsbetriebs entwirft und implementiert. Diese Konzepte sollen Unternehmen auf Störungen vorbereiten, diese minimieren und managen.

Sie sind personenunabhängig, nicht aber rollenunabhängig. BC-Konzepte enthalten Ablaufpläne für eintretende Katastrophe, die auch greifen, wenn der zuständige IT-Mitarbeiter nicht anwesend oder nicht mehr im Unternehmen beschäftigt ist.

Bei der Reduktion von Stör- und Katastrophenrisiken im Rahmen von BCM spielt die Wahl des passenden Rechenzentrums eine große Rolle. Dabei gilt es zu beachten, dass ein singuläres Rechenzentrum zwar die Hochverfügbarkeit von Daten durch zwei physisch getrennte Brandschutzbereiche bereitstellen kann, aber keine Disaster-Recovery-Funktionen aufweist.

Um diese Lücke zu schließen, bieten sich folgende kombinierbare Optionen an:

  • DR als Cloud-Service, gekoppelt an leicht skalierbare und kostengünstige Standby-Komponenten
  • DR an einem zweiten, eigenen geeigneten Rechenzentrumsstandort,
  • DR mit einem Co-Location-Partner in kurzer Entfernung, so dass im Unterschied zu den anderen Optionen synchrone Datenreplikation möglich ist,
  • DR mit einem über 200 Kilometer georedundanten Co-Location-Partner.

IT-Entscheider sollten Vor- und Nachteile der aufgeführten Wahlmöglichkeiten individuell abstimmen. Jedoch existieren Mindestanforderungen an die digitale und physische Sicherheit sowie an Kommunikationswege eines Rechenzentrums, die erfüllt sein sollten, wenn es Disaster Recovery leisten soll:

  • mindestens Klasse Tier III,
  • EN 50600 Zertifizierung,
  • Überwachungs- und Alarmempfangszentrale gemäß EN 50518,
  • minimale Bandbreitenkonnektivität von mindestens je 2 x 1 Gigabit pro Sekunde (Gbit/s) an jedem Standort für das Internet,
  • mindestens 2 x 10 Gigabit pro Sekunde für Konnektivität der Wege von Rechenzentrum zu DR, Rechenzentrum mit einer Latenzzeit von bis zu 30 Millisekunden,
  • mindestens zwei verschiedene redundante Kommunikationswege,
  • jeder Kommunikationspfad muss von einem anderen Carrier über verschiedene redundant ausgelegte Leitungen stammen,
  • wenn ein Rechenzentrum auch als Disaster-Recovery-Rechenzentrum eines weiteren Rechenzentrums verwendet wird, müssen die Kommunikationsleitungen physisch getrennt sein
  • Kommunikationswege müssen nach höchsten Standards verschlüsselt werden, also zum Beispiel nicht nur MPLS,
  • asynchrone, verschlüsselte Datenreplikation darf einen maximalen Versatz von einer Stunde aufweisen,
  • automatische Umleitung für angeschlossene Rechenzentren und deren Partner (Routen),
  • ein Fernzugriff bei Disaster Recovery sollte über einen zusätzlichen separaten Kommunikationspfad eingerichtet werden; alle Zugriffsmöglichkeiten müssen autonom von den Zugriffspfaden weiterer angeschlossener Rechenzentren sein.

Kontrolle ist besser

Wenn Disaster Recovery als funktionierender Baustein von Betriebskontinuitätsmanagement funktionieren soll, müssen Unternehmen bei gewohntem Betrieb mindestens jährlich DR-Failover-Tests und Wiederherstellungstests durchführen. Mit diesen IT-Feuerwehrübungen zeigt sich, wie lange es zumindest ohne großen Stress dauert, das Rechenzentrum umzuschalten und den Betrieb wieder aufzunehmen.

Sobald darüber hinaus größere Software-Upgrades im Zusammenhang mit der Datensicherung stattfinden, müssen diese Tests direkt nach dem Upgrade erfolgen. Dabei ist unerlässlich, dass alle CMDB-Informationen in jedem Rechenzentrum vorliegen, die in Disaster Recovery eingebunden sind.

Das Datensicherungsquartett: 3-2-1-0

Um im Katastrophenfall auf der sicheren Seite zu sein, sollten Unternehmen ihre Geschäftsdaten mindestens in dreifacher Ausführung pflegen. Drei Kopien bedeutet, dass zusätzlich zur primären Datenquelle zwei weitere Backups vorliegen sollten.

Das Datensicherungsquartett ist bei einem Systemausfall sinnvoll. Angenommen, Unternehmen X speichert und pflegt seine Daten auf Device #1, und das Backup befindet sich auf Device #2. Beide Hardware-Komponenten haben die gleichen Eigenschaften, und die Systemfehler, die sie produzieren, sind unabhängig voneinander, haben keine gemeinsamen Ursachen. Wenn beispielsweise Device #1 und Device #2 je eine Ausfallwahrscheinlichkeit von 1/100 haben, dann ist die Wahrscheinlichkeit, dass beide Geräte gleichzeitig ausfallen: 1/100 * 1/100 = 1/10.000

Setzt man dieses statistische Rechenbeispiel fort, bedeutet dies bei Primärdaten auf Device #1 sowie zwei Backups davon auf den Geräten #2 und #3 eine gemeinsame Ausfallwahrscheinlichkeit aller Datenträger von 1/100 * 1/100 * 1/100 = 1/1.000.000. Voraussetzung ist, dass alle Devices die gleichen Eigenschaften und keine gemeinsamen Fehlerursachen haben.

Mit dieser Dreifachkopie minimiert sich das Risiko, Daten während einer Katastrophe zu verlieren. Mit dieser Strategie vermeiden Unternehmen zudem, dass die Primärkopie und ihr Backup am selben physischen Speicherort gespeichert werden. Zusätzlich empfiehlt es sich, kritische Geschäftsdaten auf mindestens zwei verschiedenen Arten von Speichermedien zu speichern.

Unterschiedliche Speichertypen

Das 3-2-1-0-Backup-Modell des obigen Abschnitts greift, wenn es keine gemeinsamen Fehlerursachen für alle Geräte gibt, in denen Datenkopien lagern. Es ist hinfällig, sobald Primärdaten und deren Sicherung an derselben Stelle vorliegen.

So sind zum Beispiel Festplatten innerhalb eines RAID-Systems statistisch nicht unabhängig voneinander. Außerdem ist es nicht ungewöhnlich, dass nach einem Festplattenfehler ein Ausfall einer anderen Festplatte vom selben Speicher etwa zur gleichen Zeit auftritt.

Aus diesem Grund bewahren Unternehmen, die dem 3-2-1-0-Modell folgen, Kopien ihrer Daten auf mindestens zwei verschiedenen Speichertypen. Das können interne Festplatten und Wechselspeichermedien wie Bänder, externe Festplatten, USB-Laufwerke, SD-Karten, CDs, DVDs oder sogar Disketten sein. Auch eine Aufbewahrungsstrategie auf zwei internen Festplatten an verschiedenen Speicherorten ist sinnvoll. In jedem Fall sollte eine Kopie der Backups an einem externen Ort liegen.

Zudem spielt die physische Trennung zwischen den Kopien eine große Rolle, und es ist keine gute Idee, externe Speichergeräte im selben Raum wie zentrale Unternehmensorte, zum Beispiel Produktionslagerplätze, zu halten. Bei Katastrophen wie einem Brand droht der komplette Datenverlust als Konsequenz. Für Unternehmen aus dem Mittelstand, die ohne Remote- oder Zweigstellen arbeiten, stellt die Speicherung von Backups in der Cloud eine weitere Option dar. Auch Offsite-Kassetten sind nach wie vor bei allen Unternehmensgrößen beliebt.

Disaster Recovery ist eine Teildisziplin von Business Continuity Management (BCM) und stützt sich auf verschiedene Säulen.
Disaster Recovery ist eine Teildisziplin von Business Continuity Management (BCM) und stützt sich auf verschiedene Säulen.
(Bild: Gronau IT Cloud Computing GmbH)

Disaster Recovery als Sorgenfresser

Das „Allianz Risk Barometer 2019“ benennt Cyber-Vorfälle und Betriebsunterbrechungen als die beiden größten Sorgen, welche die deutsche Wirtschaft plagen. Diese berechtigten Sorgen liegen im Ranking erstmalig gleichauf, wobei die Top-Risikofaktoren zunehmend gemeinsam auftreten.

Disaster Recovery als regelmäßig geübter Maßnahmenplan kann hier die Auswirkungen reduzieren und Sorgen nehmen. Zu beachten ist jedoch, dass alle Tests nur Trockenübungen sind und nicht unter realen, also katastrophalen Bedingungen, stattfinden können.

Endet ein Testlauf mit einem knappen MAO-Ergebnis, so sollte sich die Unternehmensführung fragen, was dieses Ergebnis wohl für einen tatsächlichen GAU bedeuten würde. Mit einem zeitlichen Puffer von 50 Prozent kann das Management sein Betriebskontinuitätsmanagement, zumindest im Bereich DR, als erfolgversprechend einstufen.

Ergänzendes zum Thema
Über Pierre Gronau

Pierre Gronau arbeitet seit über 20 Jahren für namhafte Unternehmen als Senior IT-Berater mit umfangreicher Projekterfahrung. Zu seinen Kompetenzfeldern gehören Server-Virtualisierungen, moderne Cloud- und Automationslösungen sowie Informationsschutz. 2011 gründete er sein heutiges Unternehmen.

1964 in Augsburg geboren, entfachte ein geschenkter „Apple II“ das Feuer für Computer, Codes und ihre Geheimnisse. Er studierte zunächst Betriebswirtschaftslehre, schlug anschließend jedoch den Weg der Informationstechnologie ein.

Bis 2011 erlangte er seine branchenweite Reputation als externer Experte für die Implementierung virtueller Infrastrukturen mit VMware-Produkten. Er konzipierte und implementierte Cloud- und Automatisierungslösungen, erstellte Sicherheitskonzepte, stellte sie auf den Prüfstand, leitete Projekt-Teams an, nahm Systeme in Betrieb.

2011 – das Gründungsjahr der Gronau IT Computing GmbH. Die Zeit des Alleingangs war vorbei. Pierre Gronau schart ein buntes Team leidenschaftlicher IT-Experten um sich, die sich, als digitale Nomaden über ganz Deutschland verteilt, je nach Projekt und Auftrag zu Teams zusammenfinden, Lösungen finden und wieder neu formieren.

Gronau und seine aktuell 16 Mitarbeiterinnen und Mitarbeiter begleiten heute große mittelständische Firmen und Enterprise-Kunden durch digitale Change-Prozesse und kümmern sich um IT-Lösungen, Compliance, Datenschutz und Datensicherheit.

Pierre Gronau, Gründer und Inhaber der Gronau IT Cloud Computing GmbH mit Firmensitz in Berlin.
Pierre Gronau, Gründer und Inhaber der Gronau IT Cloud Computing GmbH mit Firmensitz in Berlin.
(Bild: Gronau IT Cloud Computing GmbH)

*Der Autor: Pierre Gronau, Gründer und Inhaber der Gronau IT Cloud Computing GmbH mit Firmensitz in Berlin

(ID:46187039)