DR-Tests ohne Auswirkungen

Ein Disaster-Recovery-Plan, der noch nie getestet wurde, ist lediglich eine Hypothese. Erfahrungen aus der Praxis zeigen, dass DR-Pläne häufig Lücken aufweisen – etwa Konfigurationsabweichungen, fehlende Automatisierung, veraltete Runbooks oder längere als erwartete Startzeiten –, die erst unter Testbedingungen sichtbar werden. Regelmäßige DR-Tests sind die einzige Möglichkeit, sicherzustellen, dass Ihr Plan funktioniert, wenn Sie ihn am dringendsten benötigen.

Test Failover ist eine integrierte Funktion von Azure Site Recovery, mit der Sie ein Failover in die sekundäre Region simulieren können, ohne die Produktion zu unterbrechen. Während eines Test-Failovers erstellt ASR Kopien der replizierten VMs in einem isolierten virtuellen Netzwerk in der sekundären Region. Die Produktions-VMs laufen in der primären Region normal weiter, sodass keine Gefahr für aktive Benutzer besteht.

Das isolierte Test-VNet darf keine Verbindung zu Produktionssystemen haben. Dadurch wird verhindert, dass Test-VMs versehentlich in die Produktionsdatenbank schreiben, E-Mails an echte Kunden senden oder Zahlungstransaktionen auslösen. Erstellen Sie ein dediziertes test failover VNet ohne Peering zu Produktions-VNets und ohne Internetzugriff und verwenden Sie es ausschließlich für DR-Übungen.

Ein DR-Test sollte bestimmte Kriterien überprüfen:

• Startzeit – Starten alle VMs innerhalb des erwarteten Zeitfensters?
• Anwendungsstart – Wird die Anwendung korrekt initialisiert, wenn sie mit der wiederhergestellten Datenbank verbunden ist?
• Datenintegrität – Sind die Daten am Wiederherstellungspunkt konsistent und vollständig?
• Tatsächliches RTO – Messen Sie die gesamte verstrichene Zeit vom Auslösen des Failovers bis zur Verarbeitung von Anforderungen durch die Anwendung
• Ausführung des Runbooks – Wurden alle Automatisierungsskripts erfolgreich abgeschlossen?

Starten Sie während des Tests den Timer genau in dem Moment, in dem Sie das Test-Failover auslösen. Stoppen Sie den Timer, sobald bestätigt wurde, dass die Anwendung fehlerfrei läuft (die Integritätsprüfung des Lastenausgleichs gibt 200 OK zurück). Dies ist Ihr tatsächliches RTO. Vergleichen Sie es mit Ihrem Ziel-RTO. Wenn das tatsächliche RTO den Zielwert überschreitet, ermitteln Sie die Engpässe – etwa einen langsamen VM-Start, eine lange Datenbankinitialisierung oder eine Verzögerung bei der DNS-Propagation – und beseitigen Sie sie.

Stellen Sie nach Abschluss des Test-Failovers eine Verbindung mit der wiederhergestellten Datenbank her und überprüfen Sie die Daten. Prüfen Sie, ob Transaktionen, die vor dem Replikationsabschluss festgeschrieben wurden, vorhanden sind und ob teilweise festgeschriebene Transaktionen korrekt behandelt werden (Rollback oder Abschluss). Testen Sie bei Datenbanken mit point-in-time restore (PITR) die Wiederherstellung auf einen bestimmten Zeitstempel und überprüfen Sie den erwarteten Datenstand.

Nach Abschluss des Tests müssen Sie Ressourcen des Test-Failovers bereinigen – die Test-VMs, ihre Datenträger und Netzwerkschnittstellen in der sekundären Region. Azure Site Recovery stellt im Portal die Aktion 'Cleanup test failover' bereit, mit der alle Testressourcen automatisch entfernt werden. Wenn Sie die Bereinigung vergessen, entstehen unnötige Kosten und in der sekundären Region sammeln sich veraltete Ressourcen an.

Erstellen Sie nach jedem DR-Test einen Testbericht, der Folgendes enthält: Datum und Umfang des Tests, erreichtes tatsächliches RTO und RPO, eine Checkliste der Prüfpunkte mit dem Status „Bestanden/Nicht bestanden“, festgestellte Lücken oder Fehler sowie geplante Korrekturmaßnahmen. Dieser Bericht ist für Compliance-Audits (ISO 27001, SOC 2, HIPAA) und zur Dokumentation der Weiterentwicklung Ihrer DR-Reife im Laufe der Zeit wertvoll.

Branchenübliche bewährte Methoden und Compliance-Frameworks verlangen in der Regel mindestens jährliche DR-Tests. Viele Organisationen testen Workloads der Stufe 1 jedoch vierteljährlich oder sogar monatlich. Häufigere Tests erkennen Konfigurationsabweichungen früher und stärken das Vertrauen sowie die Routine des Teams. Automatisieren Sie möglichst viele Schritte der Testeinrichtung und -überprüfung, um den Aufwand regelmäßiger Tests zu verringern.

Azure Chaos Studio ist ein verwalteter Dienst für Chaos Engineering, mit dem Sie kontrollierte Ausfälle in Azure-Ressourcen einschleusen können, um die Resilienz von Anwendungen zu testen. Sie können VMs herunterfahren, Zonen ausfallen lassen, die CPU drosseln oder Netzwerklatenzen einschleusen, um das Verhalten Ihrer Anwendung zu beobachten. Im Gegensatz zu einer standardmäßigen DR-Übung testet Chaos Engineering, ob sich Ihre Anwendung bei Teilfehlern kontrolliert verschlechtert.

DR-Tests sind als Teil eines kontinuierlichen Verbesserungszyklus besonders wertvoll: Planen → Ausführen → Messen → Beheben → Wiederholen. Beheben Sie nach jedem Test die festgestellten Lücken, aktualisieren Sie Runbooks und Dokumentation und testen Sie anschließend erneut. Mit der Zeit sollte sich die Lücke zwischen Ihren angegebenen RTO-/RPO-Zielen und den tatsächlich erreichten Werten schließen, bis Sie jeden Test innerhalb der Toleranzgrenzen zuverlässig bestehen.

Testen Sie Ihr Verständnis der Konzepte von Microsoft Azure Fundamentals (AZ-900) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Mit test failover können Sie ein DR-Ereignis simulieren, ohne die Produktion zu unterbrechen, indem Kopien von VMs in einem isolierten VNet erstellt werden; während des Tests müssen Sie das tatsächliche RTO messen und die Datenintegrität überprüfen; außerdem sollten Sie nach jeder Übung Testressourcen bereinigen und die Ergebnisse dokumentieren. Als Nächstes sehen wir uns Disaster Recovery speziell für PaaS-Dienste wie Azure SQL Database an.