Disaster-Recovery-Tests: von der Tabletop-Übung bis zum isolierten und vollständigen Failover-Test

Disaster-Recovery-Tests und die Arten von DR-Tests

Disaster-Recovery-Tests zeigen, ob Ihre Systeme am Ausweichstandort innerhalb der angestrebten Wiederherstellungszeit (Recovery Time Objective, RTO) und ohne größeren Datenverlust, als der angestrebte Wiederherstellungspunkt (Recovery Point Objective, RPO) zulässt, wieder anlaufen und ob das Team und der Plan sie dorthin bringen. Die Testarten reichen von der Diskussion bis zum Produktivbetrieb: die Tabletop-Übung, in der ein Szenario durchgesprochen wird, der Drill einer einzelnen Funktion, automatisierte Prüfungen von Backups oder Replikaten, der isolierte Failover-Test, der eine ganze Systemstufe am Ausweichstandort startet, ohne die Produktion zu berühren, sowie teilweise und vollständige Failover-Tests, die den Produktivbetrieb verlagern.

Tabelle 3-6 in NIST SP 800-34 Rev. 1, „ISCP TT&E Activities“, nennt Beispielaktivitäten nach der Auswirkungsstufe des Systems: eine Tabletop-Übung für Systeme mit geringer Auswirkung, eine funktionale Übung für Systeme mit mittlerer Auswirkung, beschrieben als „Simulation einer Störung mit einer Komponente zur Systemwiederherstellung“, und eine umfassende funktionale Übung sowie einen Test am Ausweichstandort für Systeme mit hoher Auswirkung. Manche DR-Pläne verwenden fünf andere Bezeichnungen: Checklistenprüfung, strukturierter Walk-through, Simulation, Paralleltest und vollständiger Unterbrechungstest. Die ersten beiden prüfen den Plan auf Papier oder in einer Besprechung, eine Simulation kommt einer funktionalen Übung nahe, und die letzten beiden nehmen den Ausweichstandort in Betrieb. Wie Sie die Zielwerte für jede Systemstufe festlegen, beschreibt unser Leitfaden zu RPO und RTO.

Tabletop-Übung nach NIST SP 800-84 und SP 800-34 Rev. 1 (Tabelle 3-6), Drill nach der HSEEP-Doktrin der FEMA (Januar 2020); die übrigen Zeilen, Aufwand und Häufigkeit sind unser Vorschlag.

Tabletop-Übungen und DR-Drills

Eine Tabletop-Übung führt die im Plan genannten Personen durch ein Szenario, ohne ein System zu berühren. Ein Moderator spielt das Szenario schrittweise ein, zum Beispiel ein ausgefallenes Speicher-Array und danach die Nachricht, dass der neueste saubere Wiederherstellungspunkt einen Tag alt ist, und die Teilnehmer sagen, was sie tun und wen sie anrufen würden. Die Tabletop Exercise Packages der CISA mit „vorgefertigten Übungszielen, Szenarien und Diskussionsfragen“ enthalten Ransomware-Szenarien.

Das Wort Drill hat zwei Bedeutungen; prüfen Sie daher, welche eine Richtlinie oder ein Vertrag meint. Die HSEEP-Doktrin der FEMA (Januar 2020) definiert einen Drill als „eine operative Übung, die häufig eingesetzt wird, um einen einzelnen Vorgang oder eine einzelne Funktion zu validieren“; im DR-Kontext kann das heißen, das Bereitschaftsteam nachts zu erreichen oder den Verzeichnisdienst in einer Laborumgebung wiederherzustellen. In AWS Elastic Disaster Recovery ist „ein Recovery Drill ein unterbrechungsfreier Test, der dieselben Schritte ausführt wie eine tatsächliche Wiederherstellung“, und AWS empfiehlt einen solchen „mindestens vierteljährlich“.

Isolierte Failover-Tests in Veeam und VMware Live Site Recovery

Ein isolierter Failover-Test startet die Replikate am Ausweichstandort in Netzen ohne Verbindung zur Produktion, sodass wiederhergestellte Server ihre Adressen und Namen aus der Produktion behalten, ohne mit den Originalen zu kollidieren. NIST SP 800-34 Rev. 1 sagt, Tests sollten „in einer Umgebung durchgeführt werden, die einer Betriebsumgebung so nahe wie möglich kommt“, und ein Test auf den Hosts am Ausweichstandort, mit den Replikaten, die Sie im Ernstfall verwenden würden, kommt dem nahe, ohne den Betrieb zu stören.

Veeam Backup & Replication 13 nennt die isolierte Umgebung ein virtuelles Labor (Virtual Lab). Veeams Help Center beschreibt, wie SureReplica ein reguläres Replikat oder ein CDP-Replikat „vom benötigten Wiederherstellungspunkt in der isolierten Umgebung“ startet, Tests ausführt, es ausschaltet und „einen Bericht über den Zustand des VM-Replikats“ erstellt. Eine Anwendungsgruppe (Application Group) startet zuerst die Maschinen, von denen die geprüfte Maschine abhängt, typischerweise Domänencontroller und DNS-Server. Masquerade-IP-Adressen ermöglichen den Zugriff aus der Produktion über die Proxy-Appliance des Labors, und benutzerdefinierte Prüfskripte können die Anwendung über vordefinierte Tests wie Heartbeat und Ping hinaus prüfen.

In VMware Live Site Recovery, ab VCF 9.1 Teil von Protection and Recovery, startet der Test eines Wiederherstellungsplans die geschützten VMs am Ausweichstandort in der Reihenfolge des Plans. Mit dem automatisch erzeugten isolierten Netz und ohne Zuordnungen auf Standortebene werden sie laut Broadcoms Dokumentation zu Live Site Recovery 9.0 (aktualisiert am 14. Juli 2026) an „temporäre Netze, die mit keinem physischen Netz verbunden sind“, angeschlossen, und die Dokumentation hält fest: „Ein isoliertes Testnetz erstreckt sich nicht über mehrere Hosts.“ Da VMs, die miteinander interagieren, „im selben Testnetz“ wiederhergestellt werden müssen, braucht eine über mehrere Hosts verteilte Anwendung ein zugewiesenes Testnetz, das diese Hosts überspannt, etwa ein VLAN ohne Route in die Produktion; das ist unsere Lesart. Der Verlauf des Wiederherstellungsplans erfasst „die Start- und Endzeiten für den gesamten Plan und für jeden Schritt“, bei Tests ebenso wie bei Ausführungen des Plans.

Prüfen Sie die Isolation vor und nach jedem Test. Broadcoms KB 444382 beschreibt Test-VMs, deren DNS-PTR-Einträge in die Produktion gelangten, weil der wiederhergestellte Domänencontroller einen Netzwerkpfad zu den produktiven Domänencontrollern hatte, und hält fest, dass das Problem „häufig auftritt, wenn ‚User Defined‘-Netzwerkzuordnungen statt automatisch erzeugter ‚Isolated‘-Netze verwendet werden“. Veeams Best-Practice-Leitfaden warnt, dass ein virtuelles Labor über mehrere Hosts, dessen VLAN-ID in der Produktion verwendet wird, nicht isoliert ist.

Unser Service Cloud Disaster Recovery führt planmäßige Failover-Tests in isolierter Umgebung durch, ohne Einfluss auf die Produktion. Nennen Sie uns, welche Systeme Sie zuerst testen würden und wie Sie diese heute wiederherstellen.

Teilweise und vollständige Failover-Tests

Ein isolierter Test lässt die Netzwerkseite der Produktion aus: DNS-Änderungen, die bei den Clients ankommen, öffentliche IP-Adressen, VPN-Tunnel, Firewall-Regeln, Lizenzserver, Benutzer an ihren eigenen Geräten und volle Last. Ein Teil-Failover-Test deckt diese Punkte für eine Anwendung oder Systemstufe ab, die in einem Wartungsfenster an den Ausweichstandort wechselt, Benutzer bedient und per Failback zurückkehrt; ein vollständiger Failover-Test tut dasselbe für die gesamte Umgebung. In VMware Live Site Recovery ist das eine geplante Migration, die am geschützten Standort „virtuelle Maschinen in umgekehrter Prioritätsreihenfolge herunterfährt“ und vor der Umschaltung die replizierten Datastores synchronisiert; sie misst also die Wiederherstellungszeit, nicht den Datenverlust nach einem plötzlichen Ausfall. Bei Veeam-Replikaten ist es ein geplanter Failover (Planned Failover), eine manuell gestartete Umschaltung von der primären VM auf ihr Replikat.

Im Vokabular der fünf Bezeichnungen lässt ein Paralleltest die wiederhergestellten Systeme neben der Produktion laufen, oft mit Kopien derselben Eingaben zum Vergleich, während die Benutzer auf den Produktivsystemen bleiben; ein vollständiger Unterbrechungstest fährt die Produktion herunter, läuft nur vom Ausweichstandort und wird zum Ausfall, wenn die Wiederherstellung scheitert.

Behandeln Sie den Failback als Teil des Tests, denn die Systeme kehren mit den Änderungen zurück, die am Ausweichstandort vorgenommen wurden, und führen Sie teilweise und vollständige Tests mit einem Rollback-Plan erst durch, wenn isolierte Tests bestanden sind. Die Schritte am Tag des Ernstfalls beschreibt unser Leitfaden zu den Schritten bei Failover und Failback.

Einen DR-Test Schritt für Schritt durchführen

1. Vereinbaren Sie mit den Systemverantwortlichen den Umfang, das Szenario, die Abbruchkriterien und was als funktionierender Dienst gilt, zum Beispiel eine im ERP-System gebuchte Testbestellung statt einer VM, die auf einen Ping antwortet.
2. Benennen Sie die Rollen: Das diensthabende Team führt das Runbook aus, sein Verfasser schaut nur zu, damit Lücken in den aufgeschriebenen Schritten sichtbar werden, ein Datenerfasser führt die Zeitleiste, und eine Person mit Befugnis ruft den simulierten Notfall und sein Ende aus.
3. Prüfen Sie, dass das Testnetz keine Route in die Produktion hat, und sperren Sie seinen ausgehenden Verkehr, damit wiederhergestellte Anwendungen keine E-Mails senden und keine Partnerschnittstellen aufrufen können.
4. Rufen Sie den Notfall aus, starten Sie die Uhr und lassen Sie das Team nach dem Runbook arbeiten, mit einem Zeitstempel für jede Phase.
5. Lassen Sie die Anwendungsverantwortlichen ihre Dienste mit Testtransaktionen bestätigen, und erfassen Sie den Zeitpunkt der Freigabe je Systemstufe.
6. Räumen Sie auf, bestätigen Sie, dass sich DNS- und Verzeichnisdaten der Produktion nicht geändert haben, und halten Sie die Nachbesprechung am selben Tag ab.
7. Schreiben Sie den Bericht, planen Sie die Korrekturmaßnahmen ein und legen Sie den Termin des Wiederholungstests fest.

NIST SP 800-84 ergänzt für funktionale Übungen zwei Rollen: Controller, „die das Übungsgeschehen überwachen, steuern und kontrollieren“, und Simulatoren, die nicht teilnehmende Parteien spielen, etwa einen Hosting-Anbieter. Das Runbook je System beschreibt unser Leitfaden zum Disaster-Recovery-Runbook.

Was Sie in einem DR-Test messen

Geben Sie menschlichen Schritten wie Entscheidungen, Anmeldungen und Prüfungen eigene Zeitstempel, denn die Protokolle der Werkzeuge decken die maschinellen Schritte ab.

Unsere Checkliste; Erfassungsmethoden nach Broadcoms Verlauf der Wiederherstellungspläne, Veeams SureReplica-Bericht und NIST SP 800-84.

In einem isolierten Test ist der Datenverlust der Abstand zwischen dem ausgerufenen Notfall und dem Wiederherstellungspunkt, von dem aus der Test startet. Bei Replikation alle 15 Minuten sollte er innerhalb dieses Intervalls zuzüglich der Dauer eines Replikationslaufs bleiben; ein größerer Abstand bedeutet, dass der Zeitplan oder die Bandbreite den RPO nicht trägt.

Der DR-Testbericht und die Korrekturmaßnahmen

NIST SP 800-84 schließt einen Test mit einem Hotwash ab, „einer informellen Nachbesprechung des Tests mit den Teilnehmern“, und mit einem After Action Report, der „ermittelt, wie gut die getesteten Systeme oder Komponenten funktioniert haben“, mit Beobachtungen und Empfehlungen, aus denen Aufgaben zugewiesen werden. Für einen DR-Test hält der Bericht fest, was hochgekommen ist, wie schnell und was zu beheben ist: Umfang und Szenario, die Zeitleiste je Systemstufe gegen den RTO, die Wiederherstellungspunkte gegen den RPO, gescheiterte oder improvisierte Schritte sowie Korrekturmaßnahmen mit einer verantwortlichen Person, einem Fälligkeitsdatum und einem Termin für den Wiederholungstest.

Die Durchführungsverordnung (EU) 2024/2690 macht das Dokumentieren von Testergebnissen und das Handeln danach zur Pflicht für die in ihrem Artikel 1 genannten Einrichtungen, darunter Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten und Anbieter verwalteter Dienste. Punkt 4.1.4 verlangt, „dass die aus diesen Tests gezogenen Lehren in die Pläne einfließen“, und Punkt 4.2.6 zu Tests der Wiederherstellung von Sicherungskopien und Redundanzen ergänzt: „Die betreffenden Einrichtungen dokumentieren die Testergebnisse und ergreifen erforderlichenfalls Korrekturmaßnahmen.“ Die Punkte 3.5.5 und 4.3.4 betreffen Tests der Verfahren zur Reaktion auf Sicherheitsvorfälle und des Krisenmanagementplans. Andere Organisationen im Anwendungsbereich von NIS2 folgen ihrem nationalen Recht und können die Verordnung als Referenz nutzen; welcher Text gilt, beurteilt die Rechtsabteilung des Unternehmens. Die zugehörigen Punkte behandelt unser Artikel zu den NIS2-Anforderungen an Backup und Business Continuity.

Nach jedem planmäßigen Failover-Test in unserem Service Cloud Disaster Recovery erhalten Sie einen Bericht: was kam hoch, wie schnell, was ist zu fixen. Schicken Sie uns Datum und Ergebnis Ihres letzten DR-Tests über das Formular unten.

Testhäufigkeit und Anlässe für zusätzliche Tests

NIST SP 800-84 verlangt Tests, Schulungen und Übungen „regelmäßig; nach organisatorischen Änderungen, Aktualisierungen eines IT-Plans oder der Herausgabe neuer TT&E-Leitlinien; oder wenn anderweitig erforderlich“, und SP 800-34 Rev. 1 überlässt die Häufigkeit der Organisation. Für DR ist ein zusätzlicher Test nach Änderungen am Wiederherstellungsweg fällig: neuer Speicher oder neue Versionen der Hypervisor- oder Replikationssoftware an einem der beiden Standorte, ein umgestaltetes Netzwerk, neue Abhängigkeiten einer kritischen Anwendung, ein anderes Replikationsprodukt oder ein anderer Anbieter oder ein neues Bereitschaftsteam. Wie die EU-Texte das Intervall formulieren, erläutert unser Artikel dazu, warum Backup kein Disaster Recovery ist.

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. Virtuelle Maschinen werden ab einem 15-Minuten-Intervall via Veeam Cloud Connect an einen Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen repliziert. Planmäßige Failover-Tests laufen in isolierter Umgebung, ohne Einfluss auf die Produktion, und nach jedem Test gibt es einen Bericht: was kam hoch, wie schnell, was ist zu fixen. Die Standardziele des Services sind RPO ab 15 Minuten und RTO von 1 bis 2 Stunden für kritische Systeme, Ihre Ziele je Systemstufe werden im SLA fixiert, und das erste Gespräch ist kostenlos.

FAQ