In vielen Azure-Projekten höre ich dieselbe Frage. Wie testet ein Unternehmen seine Disaster-Recovery-Fähigkeiten (DR) tatsächlich, ohne die Produktion zu gefährden oder den Überblick zu verlieren? Bei Azure Site Recovery für Azure-VMs kommt es darauf an, regelmäßig und nachvollziehbar in einer abgeschotteten Umgebung testen zu können. Vor einem Auditor gibt es kaum etwas Unangenehmeres als einen DR-Plan, der nie geprobt wurde oder dessen Schritte nirgends dokumentiert sind.

Azure Site Recovery repliziert laufende Azure-VMs in eine zweite Region

Azure Site Recovery (ASR) repliziert laufende Azure-VMs in eine sekundäre Azure-Region. Damit steht ein echter Notfall-Fallback bereit, wie man ihn in der Cloud nur selten so konsistent umgesetzt findet. Die Replikation arbeitet blockbasiert auf Storage-Ebene, sodass sich die VM im Ernstfall mit minimalem Datenverlust wiederherstellen lässt. Üblich ist ein RPO von wenigen Sekunden bis Minuten. Gesteuert wird alles über den Recovery-Services-Tresor. Dort verwaltet man Quell-VMs, Zielregion, Netzwerk, Replikationsrichtlinien und Aufbewahrungszeiten. Mit Azure Backup ist ASR nicht zu verwechseln. Es stellt keine einzelnen Dateien oder Snapshots wieder her, sondern bringt ganze Workloads an einem Ausweichstandort schnell und geordnet in Betrieb, einschließlich Netzwerk, DNS, Identität und Automatisierung.

Recovery Plans steuern den Failover in einer festgelegten Reihenfolge

Das Herzstück von Azure Site Recovery sind für mich die Recovery Plans. Mit ihnen lässt sich ein Failover strukturiert orchestrieren. Mehrere VMs starten in einer festgelegten Reihenfolge, dazwischen können Runbooks (z. B. PowerShell-Automatisierung in Azure Automation) und manuelle Schritte wie Checklisten oder DNS-Updates laufen. In komplexen Umgebungen, in denen Applikationsserver, Datenbanken und Domänencontroller voneinander abhängen, geht es ohne diese Steuerung kaum. Man legt Recovery Plans im Recovery-Services-Tresor an und ergänzt sie nach und nach um Skripte und Anweisungen. Derselbe Plan dient später für Test-Failover ebenso wie für die produktive Notfallumschaltung. Die Abläufe sind damit gleich übersichtlich dokumentiert, was bei der Auditierung hilft.

Der Test-Failover läuft gefahrlos in einem isolierten Netzwerk ab

Den größten Vorteil von ASR gegenüber klassischem Backup sehe ich im Test-Failover. Ein vollständiger Wiederherstellungstest ist jederzeit möglich, ohne dass die Produktion etwas davon abbekommt. Eine oder mehrere replizierte VMs starten dafür in einem separaten Subnetz, das vom Produktionsnetz getrennt ist, etwa in einem eigenen Test-VNet. Die Produktivsysteme bleiben unangetastet, und weder Nutzer noch Geschäftsanwendungen bemerken den Test. Applikationen, Identität (z. B. Active Directory), DNS-Auflösung und Netzwerkpfade lassen sich unter realistischen Bedingungen prüfen und gezielt auf Schwachstellen abklopfen. Der Ablauf sieht meist so aus:

flowchart TD
    Vorbereitung["Vorbereitung: Recovery Plan definieren"]
    Replikation["Replikation: VMs in Zielregion" ]
    TestFailover["Test-Failover: VMs in Test-VNet starten"]
    Prüfung["Prüfung: Funktion & Abhängigkeiten testen"]
    Bereinigung["Aufräumen: Testumgebung löschen"]
    Vorbereitung --> Replikation --> TestFailover --> Prüfung --> Bereinigung

Abbildung: Typischer Ablauf eines DR-Tests mit Azure Site Recovery

Ist der Test abgeschlossen, entfernt man die Testumgebung im Recovery-Services-Tresor über die Bereinigungsfunktion („Cleanup Test Failover“). So bleiben keine überflüssigen Ressourcen stehen, die weiter Kosten verursachen.

An Netzwerk, DNS und Identität scheitern DR-Übungen besonders oft

Meine Erfahrung zeigt, dass DR-Übungen selten an der eigentlichen VM-Replikation scheitern. Viel häufiger hakt es bei den „weichen“ Abhängigkeiten wie Netzwerk, DNS oder Identität. Wer beim Test-Failover keinen Domain Controller im Ziel-VNet bereitstellt, erlebt eine böse Überraschung. Die VM bootet zwar, findet aber keinen Weg in die Domäne, und keine kritische Applikation läuft. In einen Recovery Plan gehört deshalb immer auch das Starten oder vorübergehende Bereitstellen von DCs, DNS-Forwardern und den nötigen Netzwerkkonfigurationen. Für die produktive Umschaltung muss außerdem feststehen, wie man IP-Adressen, NSGs und Routingtabellen im Zielnetz zügig anpasst. Komplexe Public-IP-Konfigurationen oder Application Gateways sollte man vorab unbedingt testen und dokumentieren, weil hier oft Handarbeit nötig ist.

Mein Tipp: Für DR-Übungen lohnt sich ein eigenes Test-VNet mit separaten Subnetzen. Es lässt sich immer wieder verwenden und vermeidet Fehler, die beim Nachbauen von Produktionsnetzen per Copy & Paste entstehen.

Erst regelmäßige Drills und saubere Protokolle machen RPO und RTO belastbar

Ein Disaster-Recovery-Plan taugt nur etwas, wenn er regelmäßig getestet und dokumentiert wird. Für kritische Workloads empfehle ich mindestens einen DR-Drill pro Jahr. Dazu gehören ein lückenloses Protokoll aller Schritte, Screenshots und die Lessons Learned. Failover- und Bereinigungsvorgänge zeichnen die Recovery-Services-Tresore zwar automatisch auf. Die eigentlichen Prüfungen wie Applikationstest, Identitätsvalidierung oder DNS-Checks sollte man jedoch für jeden Drill in einem eigenen Protokoll nachvollziehbar festhalten. Beim RPO erreicht Azure Site Recovery üblicherweise wenige Sekunden bis Minuten, je nach Last und Replikationseinstellungen. Wie lange der Wiederanlauf (RTO) tatsächlich dauert, hängt dagegen stark davon ab, wie automatisiert und sauber Netzwerk, DNS und Identitätsmanagement orchestriert sind. Wer regelmäßig unter realen Bedingungen übt, findet Schwachstellen früh und kann beim nächsten Audit Ergebnisse vorlegen.

Im Unternehmensalltag entfaltet Azure Site Recovery seinen Wert erst durch geübte Abläufe

Azure Site Recovery ist mehr als ein Backup und für echte Hochverfügbarkeit und Disaster Recovery innerhalb von Azure oft unverzichtbar. Damit das Konzept auch außerhalb des Papiers trägt, müssen Recovery Plans, Netzwerk- und Identitätsdesign sowie die Abläufe für den Test-Failover sauber aufgebaut und dokumentiert sein. In meinen Projekten erlebe ich immer wieder dasselbe. Die Technik ist schnell eingerichtet, dauerhaft erfolgreich wird man aber erst mit realistischen DR-Drills, wiederkehrenden Tests und konsequenter Dokumentation. Wer bei der Planung unsicher ist, findet in der Microsoft-Dokumentation brauchbare Anleitungen, etwa zur Einrichtung der Replikation und zu Test-Failover-Drills.

Wer für DR-Zwecke noch auf klassische Backups setzt, sollte beide Ansätze unbedingt miteinander vergleichen. Speziell zu Unveränderlichkeit und Ransomware-Schutz lohnt sich der Artikel über Azure Backup Immutable Vaults.