Disaster-Recovery-Runbook: wie Sie die Schritte für ein System aufschreiben, mit Vorlage und Beispiel

Was ein DR-Runbook ist und wie es sich vom DR-Plan unterscheidet

Ein Disaster-Recovery-Runbook (DR-Runbook, auch Wiederanlaufplan) ist das schriftliche Verfahren, das ein System am Ausweichstandort wieder in Betrieb bringt: wer es ausführt, was bereits laufen muss, jeder Schritt mit seinem erwarteten Ergebnis und Zeitbudget, wie das Ergebnis geprüft und freigegeben wird und wie ein Rollback oder Failback abläuft. Der übergeordnete DR-Plan legt fest, wann die Wiederherstellung beginnt, in welcher Reihenfolge die Systeme zurückkehren und wer die Entscheidungen trifft; das Runbook beschreibt für ein System das Wie, sodass auch jemand anderes als sein Verfasser es befolgen kann.

Das Well-Architected Framework von AWS definiert ein Runbook als „einen dokumentierten Prozess, um ein bestimmtes Ergebnis zu erreichen“. NIST SP 800-34 Rev. 1, Stand Oktober 2026 weiterhin die aktuelle Revision, nennt das Dokument je System einen Notfallplan für ein Informationssystem (Information System Contingency Plan), und die Musterformate der Publikation definieren drei Phasen: Aktivierung und Benachrichtigung, Wiederherstellung sowie Rückführung in den Normalbetrieb (Reconstitution), zu der Aktivitäten gehören, „um Fähigkeiten und Funktionalität des Systems zu testen und zu validieren“.

Für die in ihrem Artikel 1 genannten Einrichtungen zählt die Durchführungsverordnung (EU) 2024/2690 in Anhang, Nummer 4.1.2 die Inhalte des Notfallplans für die Aufrechterhaltung und Wiederherstellung des Betriebs auf, die unser Artikel dazu, warum Backup kein Disaster Recovery ist, wiedergibt. Nach unserer Lesart sind die Runbooks je System die „Wiederherstellungspläne für bestimmte Betriebsabläufe, einschließlich der Wiederherstellungsziele“ aus Buchstabe f. Andere Organisationen im Anwendungsbereich von NIS2 folgen ihrem nationalen Recht, und welcher Text gilt, beurteilt die Rechtsabteilung des Unternehmens.

Vorlage für ein DR-Runbook: die Abschnitte und ihr Inhalt

Die Felder der Runbook-Vorlage von AWS lassen sich den zwölf Abschnitten unten zuordnen, zum Beispiel Special Permissions den Voraussetzungen und Escalation POC den Kontakten.

Unsere Vorlage, mit Feldern aus der Runbook-Vorlage von AWS (Well-Architected Framework, OPS07-BP03) sowie Rollen und Regeln zur Überprüfung aus NIST SP 800-34 Rev. 1, Abschnitte 3.4.6 und 3.6.

Die Auslösung entspricht der NIST-Phase Aktivierung und Benachrichtigung, Schritte und Rollback entsprechen der Wiederherstellung, Prüfung und Failback der Rückführung. Die Ziele stammen aus der Business-Impact-Analyse, und das Runbook wiederholt sie, damit die ausführende Person die verstrichene Zeit mit dem Zielwert vergleichen kann.

Runbook-Schritte schreiben, denen auch andere folgen können

NIST SP 800-34 Rev. 1 fordert den Plankoordinator auf zu berücksichtigen, „dass eine Störung einen Teil des Personals für die Reaktion unverfügbar machen könnte“; in diesem Fall kann der Plan „Personal aus einem anderen geografischen Bereich der Organisation“ oder Auftragnehmer und Lieferanten benötigen. Schreiben Sie jeden Schritt für diesen Leser, einen Kollegen von einem anderen Standort, einen Administrator eines Dienstleisters oder einen Vertreter, der das Runbook noch nie ausgeführt hat; AWS beschreibt Runbooks als Prozesse, „die konsistente Ergebnisse liefern, unabhängig davon, wer sie verwendet“.

Jeder Schritt enthält eine Aktion, angegeben als Konsolenpfad oder Befehl für die installierte Version, und das Ergebnis, das zeigt, dass sie funktioniert hat. Wo das Ergebnis abweichen kann, sagt der Schritt, wie es weitergeht: wiederholen, einen älteren Wiederherstellungspunkt verwenden oder den dort genannten Eskalationskontakt anrufen. Ein Zeitbudget je Schritt zeigt früh, wenn die Wiederherstellung in Verzug gerät.

Das Runbook nennt Konten und den Tresor, der ihre Passwörter enthält, nie die Passwörter selbst, und die Konten müssen funktionieren, während die Produktion ausgefallen ist: für das vCenter am Ausweichstandort ein Konto in dessen eigener Single Sign-On-Domäne, nicht eines aus dem produktiven Verzeichnisdienst. NIST sieht vor, eine Kopie des Plans „am Ausweichstandort und bei den Sicherungsmedien“ aufzubewahren; ein Runbook, das nur in einem Wiki am primären Standort liegt, oder ein Passwort-Tresor, der nur dort läuft, ist nicht verfügbar, wenn dieser Standort ausgefallen ist.

Ausgearbeitetes Beispiel: eine dreischichtige Anwendung unter vSphere

Das Beispiel ist eine Anwendung zur Auftragsabwicklung unter vSphere mit zwei Webservern hinter einem Load Balancer, zwei Anwendungsservern und einem Datenbankserver. Zwei Domänencontroller stellen den Verzeichnisdienst, die interne DNS-Zone und die Zeitquelle bereit. Der RTO beträgt 4 Stunden und der RPO 30 Minuten; die VMs werden alle 15 Minuten an einen Ausweichstandort mit denselben Subnetzen repliziert, an dem bereits ein Domänencontroller läuft und mit der Produktion repliziert.

Unser Beispiel; die Zeiten sind beispielhaft und keine Messwerte, verwenden Sie daher die in Ihrem letzten Test erfassten Zeiten.

Identität, DNS und Zeit kommen zuerst, weil jede spätere Prüfung von ihnen abhängt. Kerberos, das der Verzeichnisdienst für Anmeldungen verwendet, setzt Uhren voraus, die RFC 4120 „lose synchronisiert“ nennt, mit einer Toleranz von „typischerweise in der Größenordnung von 5 Minuten“; Kerberos-Anmeldungen von einem Server, dessen Uhr stärker abweicht, scheitern daher. Wie Benutzer den Ausweichstandort erreichen, beschreibt unser Leitfaden zu den Schritten bei Failover und Failback.

Mit diesen beispielhaften Zeiten gibt der Anwendungsverantwortliche nach 2 Stunden 55 Minuten frei, bei einem RTO von 4 Stunden. Auch die Zeit vor der Ausrufung des Notfalls zählt zum RTO, sodass die verbleibenden 65 Minuten Erkennung und Entscheidung abdecken müssen.

Das Beispiel deckt den Verlust des primären Standorts ab. Nach einem Ransomware-Angriff können die Replikate und der Domänencontroller am Ausweichstandort Änderungen des Angreifers enthalten; ein separates Runbook stellt deshalb von Punkten, die vor dem Einbruch liegen, in eine isolierte Umgebung wieder her. Es folgt der Reihenfolge aus unserem Leitfaden zur Wiederherstellung nach Ransomware in den ersten 72 Stunden: zuerst saubere Hosts und ein neuer Backup-Server, dann DNS und Domänencontroller, dann vCenter, dann die Anwendungsschichten.

In unserem Service Cloud Disaster Recovery folgt das Umschalten auf den Ausweichstandort am Tag der Katastrophe einem geprobten Szenario, mit Failback nach Wiederherstellung der Primärseite. Beschreiben Sie die Anwendung, die Sie zuerst dokumentieren würden, und ihre Abhängigkeiten im Formular unten.

Prüfung, Freigabe, Rollback und Failback

Prüfungen laufen auf drei Ebenen: Die VM läuft, der Dienst antwortet, und die Anwendung funktioniert für einen Benutzer. Der Schritt Verify DNS Port von Veeam Recovery Orchestrator „prüft den Port, über den die Verbindung zur wiederhergestellten VM mit der Rolle Domain Naming Service hergestellt wird“, standardmäßig Port 53; das zeigt, dass der Port antwortet, aber nicht, dass die Einträge aktuell sind. Das Runbook ergänzt Namensauflösungen, eine Testbestellung und Schnittstellenaufrufe, und mit der Freigabe durch den Anwendungsverantwortlichen endet die Wiederherstellung, die gegen den RTO gemessen wird.

Der Abschnitt Rollback nennt Abbruchkriterien je Etappe und den Weg zurück: einen älteren Wiederherstellungspunkt, wenn die neueste Datenbankkopie nicht startet, eine Wiederherstellung aus dem Backup, wenn kein Replikatpunkt sauber ist, und eine Entscheidung zum Abbruch, die bei der Person liegt, die den Notfall ausgerufen hat. Das Rückgängigmachen eines Veeam-Failovers wird „alle Änderungen verwerfen, die am VM-Replikat vorgenommen wurden, während es lief“; das Runbook nennt daher, wer es genehmigen darf.

Nach unserer Lesart deckt der Failback Anhang, Nummer 4.1.2 Buchstabe h der Verordnung ab, die „Wiederherstellung und Wiederaufnahme der Tätigkeiten nach vorübergehenden Maßnahmen“. Der Failback in Veeam überträgt „alle Änderungen, die während der Laufzeit des VM-Replikats stattfanden, auf die ursprüngliche VM“. In Live Site Recovery schließt eine geplante Migration die Wiederherstellung ab, sobald der primäre Standort wieder verfügbar ist, ein Reprotect kehrt die Replikation um, und der Failback ist eine geplante Migration zurück, gefolgt von einem zweiten Reprotect. Das Runbook nennt die Methode, wer den Termin festlegt und wie die Rücksynchronisierung geprüft wird.

Was Live Site Recovery und Veeam Recovery Orchestrator automatisieren

In VMware Live Site Recovery, ab VCF 9.1 Teil von Protection and Recovery, bestimmt die Wiederherstellungspriorität „die Reihenfolge, in der virtuelle Maschinen heruntergefahren und eingeschaltet werden“, und Abhängigkeiten „gelten nur, wenn die virtuellen Maschinen dieselbe Priorität haben“; daher gibt das Beispiel seiner Datenbank eine höhere Priorität als seinen Anwendungsservern. Benutzerdefinierte Schritte „führen während einer Wiederherstellung Befehle aus oder zeigen dem Benutzer Meldungen an“, und weil eine Meldung auf eine Antwort wartet, lässt sich die Datenbankprüfung als Pause im Plan abbilden. Broadcoms FAQ zu VCF 9.1 vom 3. September 2026 hält fest: „Die Orchestrierung von Disaster-Recovery-Runbooks erfordert eine eigenständige SRM- oder ACC-Berechtigung“, gemeint ist eine Lizenz für Site Recovery Manager oder Advanced Cyber Compliance. Broadcom erlaubt außerdem, die Schritte eines Plans zu exportieren, „um eine ausgedruckte Sicherungskopie Ihrer Pläne aufzubewahren“.

Veeam Recovery Orchestrator 13 (Benutzerhandbuch vom 26. August 2026) baut Pläne aus Schritten wie Check VM Heartbeat, Verify Domain Controller Port und Custom Script auf und arbeitet mit einer Lizenz für Veeam Data Platform Premium oder einer Advanced-Lizenz mit Orchestrator-Lizenzen. Standardmäßig führt er täglich eine Bereitschaftsprüfung (Readiness Check) jedes aktivierten Plans aus und bestätigt zum Beispiel, dass „Replikat-VMs erkannt und für den Failover bereit sind“ und „erforderliche Zugangsdaten angegeben sind“. Sein Plan Definition Report listet die Schritte und Parameter eines Plans auf, und Veeam zufolge kann er „verwendet werden, um eine Freigabe von Anwendungsverantwortlichen einzuholen, die die Plankonfiguration prüfen müssen“. Bei beiden Werkzeugen bleiben die Auslösung, Änderungen durch Netzbetreiber, DNS-Anbieter oder Partner, fachliche Prüfungen, die Freigabe und Nachrichten an die Benutzer im Runbook.

DR-Runbooks über das Änderungsmanagement aktuell halten

AWS nennt unter den Anti-Patterns von OPS07-BP03: „Zulassen, dass Runbooks nicht mehr zu Systemänderungen und Automatisierung passen“, und NIST SP 800-34 Rev. 1 sieht vor, dass Pläne „im Rahmen des Änderungsmanagementprozesses der Organisation“ überprüft und aktualisiert werden. Für die erfassten Einrichtungen verlangt die Durchführungsverordnung (EU) 2024/2690, dass Änderungen „im Hinblick auf die möglichen Auswirkungen getestet und bewertet werden, bevor sie umgesetzt werden“ (Anhang, Nummer 6.4.2), und dass Pläne nach erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken überprüft und, soweit angemessen, aktualisiert werden (Nummer 4.1.4).

1. Ergänzen Sie jeden Änderungsantrag für ein System mit Runbook um ein Feld „Wiederherstellungsschritte betroffen: ja/nein“, das der Runbook-Verantwortliche prüft.
2. Werten Sie neue oder geänderte IP-Adressen, VLANs, DNS-Namen, Firewall-Regeln, Konten und Zertifikate, Upgrades von vCenter, ESX, der Datenbank oder der Replikationssoftware sowie neue Schnittstellen als betroffen.
3. Aktualisieren Sie Schritte und Kontakte in derselben Änderung und protokollieren Sie dies in der Versionshistorie mit Datum, Grund und Verfasser.
4. Führen Sie die geänderten Schritte in einem isolierten Test aus, bevor die Änderung geschlossen wird.
5. Erfassen Sie nach jedem Test oder Vorfall die Zeit je Schritt und die Befunde, und korrigieren Sie das Runbook.
6. Ersetzen Sie die Kopie am Ausweichstandort durch die neue Version.

Testarten und den Testbericht behandelt unser Artikel zu Disaster-Recovery-Tests.

Jeder planmäßige Failover-Test in unserem Service Cloud Disaster Recovery endet mit einem Bericht: was kam hoch, wie schnell, was ist zu fixen. Nennen Sie uns, wann Ihre Runbooks zuletzt von jemand anderem als ihrem Verfasser befolgt wurden.

Was wir tun

Im Rahmen unseres Services Cloud Disaster Recovery definiert unser Engineering-Partner Vixen.UNO gemeinsam mit Ihnen die kritischen Systeme, Ziel-RPO und -RTO je Systemstufe und die Katastrophenszenarien; das Ergebnis ist ein Continuity-Plan, nicht nur Kopien. Virtuelle Maschinen werden ab einem 15-Minuten-Intervall via Veeam Cloud Connect an einen Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen repliziert, mit planmäßigen Failover-Tests in isolierter Umgebung und einem Bericht nach jedem Test. Das Umschalten am Tag der Katastrophe folgt einem geprobten Szenario; RPO und RTO werden im SLA fixiert, und das erste Gespräch ist kostenlos.

FAQ