Disaster Recovery: Flussdiagramm für den IT-Wiederanlauf

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.