Disaster Recovery: Flussdiagramm für den IT-Wiederanlauf

Was ist disaster recovery: flussdiagramm für den it-wiederanlauf?

Disaster Recovery ist die technische Hälfte der Kontinuitätsarbeit: IT-Systeme und Daten nach einem Ereignis zurückholen, das die normale Störungsbearbeitung nicht mehr auffängt: Standortverlust, Speicherausfall, ein großflächiger Ausfall beim Hosting-Anbieter. Es ist nicht Business Continuity. Ein Notfallplan beschreibt, wie die Organisation weiter Geschäft macht, während die Systeme stehen: manueller Notbetrieb, Ausweichflächen, Personal, Lieferanten, Kundenzusagen. Dieser Prozess beschreibt die Server, die Daten und die Reihenfolge, in der sie zurückkommen. Verbunden sind beide an genau einer Stelle: Die hier verwendeten Wiederanlaufprioritäten sollten aus der Business Impact Analyse des Notfallplans stammen und nicht aus dem Bauchgefühl eines Technikers im Ausfall.

Ebenso wenig ist es Incident Management oder Incident Response. Ein einzelner Dienst, der im laufenden Betrieb ausfällt, bleibt beim Service Desk und erreicht die Auslösung nie. Ist die Störung durch einen Angriff verursacht, läuft die Incident Response parallel und entscheidet, wann eine Wiederherstellung sicher ist, denn ein Neuaufbau, bevor der Umfang verstanden ist, kann den Angreifer wieder einsetzen oder Beweise vernichten. Am anderen Ende ist die Rückführung ein geplanter Change und gehört ins Change Management, nicht in den Notfallablauf.

Die meisten DR-Pläne scheitern an derselben Handvoll Dinge: keine vereinbarten Auslösekriterien, sodass Stunden vergehen, während diskutiert wird, ob dieser Fall zählt; eine willkürliche Wiederanlaufreihenfolge, sodass Anwendungen hochkommen, bevor die Verzeichnis- und Datenbankdienste stehen, von denen sie abhängen; eine Wiederherstellung, die auf die Nutzer geschaltet wird, bevor sie jemand geprüft hat; und eine Meldung „Dienst läuft wieder“, die kein Anwendungsverantwortlicher jemals bestätigt hat. Diese Vorlage legt den Ablauf über fünf Bahnen und fünf Phasen aus, mit einer Auslöseentscheidung, einer Integritätsprüfung mit Rücksprungschleife und einem Validierungstor, das bei den Anwendungsverantwortlichen liegt und nicht bei dem Infrastrukturteam, das die Arbeit gemacht hat.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Fünf Swimlanes mit einem Verantwortlichen für jeden Schritt (Monitoring / Betrieb, DR-Koordination, Geschäftsleitung, Infrastrukturteam, Anwendungsverantwortliche) über fünf Phasen: Erkennung und Bewertung, Auslösung, Wiederherstellung, Validierung sowie Rückführung und Auswertung.
• Erkennung und Bewertung, in der „Störereignis erkannt“ auf „Auswirkung und betroffene Systeme bewerten“ und „An die DR-Koordination eskalieren“ führt, bevor überhaupt etwas erklärt wird.
• Die Entscheidung „Auslösekriterien für DR erfüllt?“ in der Bahn der DR-Koordination: Der Zweig Nicht erfüllt endet bei „Als normale Störung bearbeitet“, der Zweig Erfüllt geht auf „DR-Auslösung freigeben“ in der Bahn der Geschäftsleitung: Die Erklärung bleibt damit bei der befugten Rolle.
• Mobilisierung und Priorisierung: „DR-Team mobilisieren“, danach „Systeme nach RTO und RPO priorisieren“, mit einem Kommentar dazu, was die beiden Zielgrößen bedeuten und warum geteilte Abhängigkeiten (Verzeichnisdienste, Netzwerk, Datenbanken) vor den Anwendungen wiederhergestellt werden, die sie brauchen.
• Die Wiederherstellung in der Bahn Infrastrukturteam: „Auf den Ausweichstandort umschalten“, „Daten aus dem Backup wiederherstellen“ und die Entscheidung „Datenintegrität bestätigt?“, deren Zweig Fehlgeschlagen über „Aus älterer Sicherung wiederherstellen“ in den Wiederherstellungsschritt zurückläuft.
• Validierung und Abschluss: „Anwendungen fachlich prüfen“ und das Tor „Dienste laufen wie erwartet?“, das Fehler an das Infrastrukturteam zurückgibt, gefolgt von „Wiederherstellung an die Nutzer kommunizieren“, der Planung der Rückführung, der Beendigung des DR-Betriebs, der Nachbereitung sowie aktualisiertem DR-Plan und Testplan.

Wann Sie diese Vorlage verwenden sollten

• Sie dokumentieren einen DR-Plan oder den IKT-Wiederanlaufteil eines Notfallplans und wollen Abfolge und Verantwortliche jedes Schritts auf einer Seite haben.
• Sie legen Auslösekriterien und die Befugnis zur Erklärung eines Katastrophenfalls fest, bevor ein Ausfall die Frage um drei Uhr nachts erzwingt.
• Sie bereiten einen DR-Test oder eine Planübung vor: Entscheidungen, Schleifen und Übergaben liefern das Drehbuch, gegen das Sie den Plan prüfen.
• Sie briefen Bereitschaftsingenieure, die Teile der Wiederherstellung möglicherweise ohne die Autoren des Plans durchführen müssen.
• Sie weisen einem Auditor oder Kunden nach, dass der IKT-Wiederanlauf dokumentiert und geübt ist (ein Diagramm belegt den Prozess, es belegt für sich genommen keine Normkonformität).

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Rollen

   Ersetzen Sie Monitoring / Betrieb, DR-Koordination, Geschäftsleitung, Infrastrukturteam und Anwendungsverantwortliche durch Ihre realen Rollen: NOC oder Monitoring, IT-Service-Continuity-Manager, die Führungskraft in der Krisenbereitschaft, Plattform- und Datenbankteams, benannte Serviceverantwortliche. Kleinere Organisationen führen Koordination und Infrastruktur häufig zusammen; hat eine Bahn niemanden, löschen Sie sie, statt sie unbesetzt zu lassen.

2. Schreiben Sie Ihre Auslösekriterien an die Entscheidung

   Machen Sie „Auslösekriterien für DR erfüllt?“ objektiv genug, dass jemand sie unter Druck anwenden kann: Primärstandort nicht zugänglich, erwartete Ausfalldauer länger als die Wiederanlaufzeit eines Tier-1-Systems, primärer Speicher oder primäre Datenbank vor Ort nicht wiederherstellbar. Benennen Sie die zur Auslösung befugte Rolle und eine Vertretung und halten Sie fest, wie beide außerhalb der Geschäftszeiten erreicht werden.

3. Hinterlegen Sie echte RTO- und RPO-Werte je System

   Nehmen Sie die Zielwerte aus der Business Impact Analyse und nicht aus dem, was die Infrastruktur heute schafft, und listen Sie sie in Stufen an „Systeme nach RTO und RPO priorisieren“. Halten Sie neben der Prioritäts- auch die Abhängigkeitsreihenfolge fest: Eine Tier-1-Anwendung lässt sich nicht validieren, bevor Verzeichnisdienst, Netzwerk und Datenbank darunter laufen.

4. Beschreiben Sie Ihren tatsächlichen Wiederanlaufmechanismus

   „Auf den Ausweichstandort umschalten“ bedeutet bei replizierter Infrastruktur, einem Warm Standby, einer zweiten Cloud-Region und einem Neuaufbau von Sicherungsmedien jeweils etwas anderes. Schreiben Sie Mechanismus, Link zum Runbook, Ablageort der Zugangsdaten und Break-Glass-Konten sowie alle manuellen DNS- oder Netzwerkänderungen in die Kommentare der Kästen, damit das Diagramm während einer Wiederherstellung brauchbar ist und nicht nur im Review.

5. Definieren Sie, was „Integrität bestätigt“ heißt und wer das sagt

   Legen Sie die Prüfungen hinter „Datenintegrität bestätigt?“ fest: Satzzahlen, Konsistenz- und Referenzprüfungen, fachliche Smoke-Tests, Abgleich gegen den letzten bekannten guten Stand. Entscheiden Sie, was „ältere Sicherung“ konkret bedeutet, wie viele Versuche Sie unternehmen, bevor eskaliert wird, und halten Sie fest, dass jeder Schritt zurück den Datenverlust erhöht, den Sie gegenüber dem RPO erklären müssen.

6. Ergänzen Sie die Rückführung, testen Sie das Diagramm und halten Sie die Version

   Prüfen Sie, ob der Rückführungsweg zu Ihrer Arbeitsweise passt: Zeitfenster, Datenabgleich vom Ausweichstandort zurück, Freigabe über das Change Management und der Punkt, an dem der DR-Betrieb formell beendet wird. Üben Sie das Diagramm anschließend, vergleichen Sie erreichte Wiederanlaufzeit und tatsächlichen Datenverlust in der Nachbereitung mit Ihren Zielwerten und veröffentlichen Sie die freigegebene Fassung, damit die Leute dieselbe Revision üben, der sie im Ernstfall folgen.

Häufig gestellte Fragen

Worin unterscheiden sich Disaster Recovery und Business Continuity?

Business Continuity sorgt dafür, dass die Organisation ihre Produkte und Leistungen während einer Störung weiter erbringt, mit allen verfügbaren Mitteln: manueller Notbetrieb, Ausweichflächen, umgesetztes Personal, Ersatzlieferanten, Kundenkommunikation. Disaster Recovery ist der IT-Teil davon: die Wiederherstellung der Systeme, Daten und Infrastruktur, auf die die Organisation angewiesen ist. Die Prioritäten setzt die Kontinuitätsarbeit, denn die Business Impact Analyse entscheidet, welche Aktivitäten am wichtigsten sind und wie lange sie unterbrochen sein dürfen; Disaster Recovery übernimmt diese Zeiten als RTO- und RPO-Zielwerte und liefert dagegen. Ein DR-Plan ohne Kontinuitätsinput stellt tendenziell das zuerst wieder her, was am einfachsten wiederherzustellen ist.

Was bedeuten RTO und RPO genau?

RTO, das Recovery Time Objective oder die Wiederanlaufzeit, ist die Zielzeit, innerhalb derer ein System oder Dienst wieder nutzbar sein muss, gemessen ab der Störung und nicht ab dem Moment, in dem jemand das Auslöseformular unterschreibt. RPO, das Recovery Point Objective, ist der Zeitpunkt, auf den Daten zurückgeholt werden müssen, gemessen rückwärts ab der Störung; praktisch ist es also der maximale Datenverlust, den die Organisation zu akzeptieren bereit ist. Beide treiben unterschiedliche Investitionen: Das RTO hängt daran, wie schnell Sie Infrastruktur hochbekommen (Standby-Kapazität, Automatisierung, Übung), das RPO ist dagegen dadurch begrenzt, wie oft Daten weggesichert werden: Eine nächtliche Sicherung trägt kein RPO unter etwa einem Tag, egal wie schnell die Rücksicherung läuft. Beide Begriffe sind in Kontinuitätsnormen wie der ISO 22301 definiert.

Wer sollte die DR-Auslösung freigeben, und wann?

Die Auslösung gehört zu einer Rolle, die Kosten und Risiko einer Umschaltung akzeptieren darf, typischerweise die Geschäftsleitung oder die Krisenstabsleitung, mit benannter Vertretung und dokumentiertem Erreichbarkeitsweg außerhalb der Geschäftszeiten. Sie ist in diesem Diagramm bewusst von der DR-Koordination getrennt: Die Koordination bewertet und empfiehlt, die Geschäftsleitung gibt frei, danach führt die Koordination die Wiederherstellung. Der Auslöser sollte vorab geschrieben sein und sich an Fakten prüfen lassen, die früh in einem Ausfall verfügbar sind: Der teure Fehler ist nicht, zu früh auszulösen, sondern drei Stunden mit der Frage zu verbringen, ob dieser Fall zählt, während die RTO-Uhr läuft.

Was passiert, wenn die zurückgespielten Daten die Integritätsprüfung nicht bestehen?

Das Diagramm dreht eine Schleife, statt weiterzumachen: „Datenintegrität bestätigt?“ gibt den Zweig Fehlgeschlagen an „Aus älterer Sicherung wiederherstellen“, das wieder in den Wiederherstellungsschritt mündet, sodass erneut geprüft wird. In dieser Schleife wird das RPO real getestet, denn jeder Schritt zurück auf eine ältere Kopie erhöht den Datenverlust, den Sie erklären müssen, und irgendwann lautet die ehrliche Antwort, dass der Zielwert nicht erreichbar ist und dem Geschäft gesagt werden muss, welchen Zeitraum es manuell rekonstruieren muss. Vereinbaren Sie vorab, wie viele Versuche Sie machen, wer einen Wiederherstellungspunkt schlechter als das RPO akzeptieren darf und wie die Lücke dokumentiert wird.

Wie oft sollte der Disaster-Recovery-Prozess getestet werden?

So oft, dass der Plan die aktuelle Landschaft abbildet, und mit schriftlich festgehaltenen Ergebnissen. Die meisten Organisationen fahren eine Mischung: häufige Rücksicherungsprüfungen auf Backups, unterjährige Komponenten- oder Teilumschaltungen und eine umfassendere Übung in einem festen Turnus, üblicherweise jährlich, wobei regulierte Branchen und kritische Dienste mehr erwarten. Wichtiger als das Intervall ist, was geprüft wird. Eine Rücksicherung, die nie eingehängt und gelesen wird, beweist nichts, und eine Übung, die Validierung und Rückführung auslässt, verdeckt genau die beiden Probleme, die im Ernstfall am meisten wehtun: Anwendungsverantwortliche, die unerwartete Fehler finden, und ein fehlender abgestimmter Weg zurück zum Primärstandort.