Failover und Failback: die DR-Schritte im Ernstfall, vom Ausrufen des Notfalls bis zu DNS, VPN und Failback

Failover und Failback: was am Tag des Notfalls geschieht

Der Failover verlagert die Produktion an den Ausweichstandort: Die Replikate starten dort in festgelegter Reihenfolge, und das Netzwerk wird so umgeschaltet, dass die Benutzer sie erreichen. Das Failback bringt die Produktion an den Primärstandort zurück, sobald dieser repariert ist, und überträgt dabei die am Ausweichstandort entstandenen Änderungen in einem geplanten Zeitfenster zurück. Veeam Backup & Replication 13 nennt den Failover „einen Zwischenschritt, der abgeschlossen werden muss“, und zwar durch Undo Failover, Failback oder Permanent Failover. Ein Planned Failover vollzieht denselben Wechsel vor einem im Voraus bekannten Ereignis, solange der Primärstandort noch läuft, nach einer vollständigen Synchronisierung und dem Herunterfahren der Quell-VMs. In VMware Live Site Recovery, ab VCF 9.1 Teil von Protection and Recovery, läuft ein Wiederherstellungsplan als Planned Migration, wie das Produkt diesen Vorgang nennt, oder als Disaster Recovery, und vor dem Failback steht ein Reprotect.

Unsere Checkliste; Begriffe wie in Veeams Leitfäden zu Version 13 und Broadcoms Dokumentation zu Live Site Recovery 9.0 und Protection and Recovery 9.1 (gelesen am 6. Oktober 2026).

Jede Zeile gehört in das Runbook jedes Systems, wie unser Leitfaden zum Disaster-Recovery-Runbook zeigt.

Den Notfall ausrufen: wer entscheidet und nach welchen Kriterien

Der Plan benennt die Rolle, die den Notfall ausruft, mit Stellvertretern, die auch außerhalb der Geschäftszeiten erreichbar sind, sowie Kriterien je Systemstufe. Wir schlagen vor, den Notfall auszurufen, wenn der Primärstandort nicht innerhalb des RTO der Systemstufe zurück sein wird, beschädigt oder unsicher ist oder Daten enthält, denen sich nicht mehr vertrauen lässt. Für die in ihrem Artikel 1 genannten Einrichtungen führt die Durchführungsverordnung (EU) 2024/2690 „Bedingungen für die Aktivierung und die Deaktivierung des Plans“ unter den Inhalten des Plans auf (Anhang, Nummer 4.1.2 Buchstabe d); für andere Unternehmen muss die eigene Rechtsabteilung beurteilen, welches Recht gilt.

Da der RTO mit dem Beginn des Ausfalls läuft, müssen Erkennung und Entscheidung in den RTO abzüglich der Failover-Dauer passen, bei einem Failover von einer Stunde und einem RTO von zwei Stunden also in die erste Stunde. Abwarten ist nur dann die bessere Wahl, wenn der Ausfall sicher innerhalb des RTO endet, denn ein Failover kostet die Schreibvorgänge seit dem letzten Replikationslauf und später ein Failback; unser Leitfaden zu RPO und RTO behandelt die Zielwerte je Systemstufe.

Broadcom trennt die Berechtigung, einen Plan in Live Site Recovery auszuführen, von der Berechtigung, ihn zu testen, weil eine Ausführung „an beiden Standorten Änderungen vornimmt, deren Rückgängigmachung erheblichen Zeit- und Arbeitsaufwand erfordert“. Bei Veeam Cloud Connect startet der Tenant seinen Cloud-Failover-Plan selbst oder bittet, wenn auch sein Backup-Server verloren ist, den Provider, ihn zu starten.

Mit dem Ausrufen des Notfalls wird auch der Wiederherstellungspunkt festgelegt. Nach einem Brand oder einem Hardwareausfall ist es der neueste, nach einem fehlerhaften Update einer aus der Zeit davor und nach Ransomware einer aus der Zeit vor dem Eindringen des Angreifers. Veeam kann den Failover „auf den neuesten Stand eines Replikats oder auf einen beliebigen seiner Wiederherstellungspunkte“ ausführen, doch der Quick Start Guide für Version 12 begrenzt VM-Replikate auf 28 Wiederherstellungspunkte, also etwa 7 Stunden bei einem 15-Minuten-Intervall; ältere saubere Punkte kommen aus Backups.

Failover-Reihenfolge nach Systemstufe und Abhängigkeit

Systeme starten in der Reihenfolge, die ihre Abhängigkeiten verlangen, Verzeichnisdienst und DNS zuerst. VMware Live Site Recovery startet virtuelle Maschinen nach Wiederherstellungspriorität, von 1, der höchsten, bis 5, wobei jede virtuelle Maschine eines neuen Plans auf 3 steht, und wartet auf den Heartbeat der VMware Tools aller virtuellen Maschinen einer Priorität, bevor die VMs der nächsten Priorität starten; Abhängigkeiten wirken nur innerhalb einer Priorität. Veeam-Failover-Pläne legen die Reihenfolge und eine Verzögerung vor der nächsten VM fest, die laut Veeam „hilft sicherzustellen, dass einige VMs, etwa ein DNS-Server, bereits laufen, wenn die abhängigen VMs starten“; ein Cloud-Failover-Plan startet höchstens 10 VMs gleichzeitig.

Ein Heartbeat zeigt nur, dass das Gastbetriebssystem läuft; prüfen Sie daher jede Stufe vor der nächsten: Die Datenbank nimmt Verbindungen an, der Anwendungsserver meldet sich bei ihr an, und ein Testbenutzer schließt eine Transaktion ab, bevor die Frontends geöffnet werden.

Re-IP, gestreckte Netze oder Network Extension

Wiederhergestellte Server erhalten neue Adressen aus den Subnetzen des Ausweichstandorts (Re-IP), bleiben in Produktionssubnetzen, die über beide Standorte gestreckt oder per Routing dorthin verlegt sind, oder behalten ihre Adressen hinter Appliances, die das Netz bis zu einem Provider erweitern.

Veeams Re-IP-Regeln „bilden IP-Adressen am Produktionsstandort auf IP-Adressen am Disaster-Recovery-Standort (DR-Standort) ab“, und zwar beim Failover und nur für VMs einer einzigen Familie von Gastbetriebssystemen; Linux-Server brauchen ein anderes Verfahren, etwa ein Skript im Gast. VMware Live Site Recovery passt die IP-Einstellungen je virtueller Maschine an, für viele VMs auf einmal mit dem Werkzeug DR IP Customizer oder über Regeln auf Subnetzebene, und braucht dafür VMware Tools oder VMwares Operating System Specific Packages im Gast. Jede neue Adresse muss anschließend in DNS, Firewall-Regeln, hosts-Dateien und Anwendungseinstellungen eingetragen werden.

Ein gestrecktes Layer-2-Netz behält die Adressen bei, doch sein Standard-Gateway muss am Ausweichstandort ohne den Primärstandort funktionieren, und eine Netzwerkschleife oder ein Broadcast-Sturm erreicht beide Standorte. Routing kann ein Subnetz nur als Ganzes verlegen, was zu einem vollständigen Standort-Failover passt (unsere Lesart).

Auch bei Veeam Cloud Connect behalten Server ihre Produktionsadressen, da Veeam „keine Re-IP-Regeln für VM-Replikate auf dem Cloud-Host unterstützt“, und weil die Cloud-Connect-Replikation „DHCP nicht unterstützt“, brauchen replizierte VMs statische Adressen. Network Extension Appliances verbinden die Subnetze nach einem Teil-Failover über ein VPN und dienen nach einem vollständigen Standort-Failover als Gateway der Replikate, wie unser Vergleich von Veeam-Replikation, Backup Copy und Cloud Connect erklärt.

DNS-TTL, öffentliche IP-Adressen und VPN

RFC 1035 definiert die TTL als das Intervall, für das ein Eintrag „zwischengespeichert werden darf, bevor die Quelle der Information erneut befragt werden sollte“. Nach einer Änderung können Clients die alte Adresse so lange verwenden, wie die TTL es zulässt. Senken Sie die TTL der Einträge, die sich beim Failover ändern würden, lange vor jedem Notfall, denn bereits zwischengespeicherte Antworten behalten die alte TTL; wir schlagen einige Minuten vor.

Öffentliche Adressen bleiben in der Regel beim Internetprovider des Primärstandorts. Bei Veeam Cloud Connect stellt der Provider öffentliche Adressen über den Hardware-Plan bereit, und für einen vollständigen Standort-Failover ordnet der Tenant im Cloud-Failover-Plan jede öffentliche Adresse und jeden Port der internen Adresse und dem Port eines Replikats zu. Dann ändern sich die öffentlichen DNS-Einträge für Website, E-Mail, VPN-Gateway und Partnerschnittstellen, und Partner, die Ihre Adressen auf einer Allowlist führen, brauchen die neuen vorab.

Konfigurieren Sie Site-to-Site-VPN-Peers, Schlüssel und Routen am Ausweichstandort vor dem Ernstfall, und geben Sie Remote-Access-Clients das Gateway des Ausweichstandorts als zweiten Server oder als DNS-Namen mit kurzer TTL mit.

Unser Service Cloud Disaster Recovery repliziert virtuelle Maschinen via Veeam Cloud Connect an einen Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen. Schicken Sie uns die Subnetze, öffentlichen Adressen und VPN-Peers, die Ihre kritischen Systeme heute nutzen.

Firewall-Regeln, Zertifikate und Lizenzserver

Die Firewalls des Ausweichstandorts müssen die Verbindungen zulassen, die die Produktion braucht, und nach einem Re-IP braucht jede Regel, die für eine Adresse oder ein Subnetz geschrieben wurde, dort ein Gegenstück.

Ein Zertifikat deckt nur die Namen ab, die es aufführt, und ein automatisierter Client, der keine Übereinstimmung findet, „SOLLTE den Kommunikationsversuch mit einem Fehler ‚bad certificate‘ abbrechen“, wie RFC 9525 festlegt; ein Dienst, der unter einem neuen Namen erreicht wird, braucht diesen Namen daher in seinem Zertifikat. Zertifikate auf Reverse Proxys und Load Balancern außerhalb der Replikate müssen am Ausweichstandort ebenfalls installiert werden, und eine interne Zertifizierungsstelle, die ihre Sperrliste nur am Primärstandort veröffentlicht, kann dazu führen, dass Clients, die den Sperrstatus prüfen, gültige Zertifikate ablehnen.

Software, die ihre Lizenz gegen einen Lizenzserver, eine MAC-Adresse oder eine Host-ID prüft, kann am Ausweichstandort den Start verweigern, und der Lizenzserver selbst kann an seine Adresse gebunden sein: Das NVIDIA License System, das die vGPU-Software lizenziert, verlangt für die Plattform seines Delegated License Service „eine feste (unveränderliche) IP-Adresse“.

Benutzerzugriff und Betrieb am Ausweichstandort

Die Benutzer erreichen den Ausweichstandort über dort vorbereitete VPN-Gateways und veröffentlichte Anwendungen und melden sich am Verzeichnisdienst der ersten Systemstufe an; Multi-Faktor-Authentifizierung, RADIUS und gegebenenfalls ein Identity Provider müssen von dort ebenfalls erreichbar sein. Informieren Sie die Benutzer über die Änderungen auf einem Kanal, der nicht vom Primärstandort abhängt, denn die E-Mail ist womöglich ausgefallen.

Sichern Sie die wiederhergestellten Systeme ab der ersten Stunde, denn das Replikat enthält die einzige Kopie der dort geschriebenen Daten. Protokollieren Sie jede Änderung am Ausweichstandort, von Firewall-Regeln bis zu DNS-Einträgen, denn das Failback macht jede davon rückgängig oder behält sie bei. Proben Sie diese Netzwerkseite in Teil-Failover-Tests, denn isolierte Tests lassen sie aus, wie unser Leitfaden zu Disaster-Recovery-Tests beschreibt.

Der Failback-Prozess: Delta-Synchronisierung und abweichende Daten

Das Failback in Veeam überträgt „alle Änderungen, die während der Laufzeit des VM-Replikats stattgefunden haben, auf die ursprüngliche VM“, oder an einen neuen Ort, wenn der Quellhost verloren ist, und die Änderungen werden „nur übertragen, aber nicht veröffentlicht“, bis Sie die ursprüngliche VM testen und Commit Failback ausführen. Bei Cloud Connect ist das Failback „nur auf der Tenant-Seite verfügbar“: Ein Backup-Server, der mit dem Standort verloren ging, muss also zuerst neu aufgebaut und mit dem Provider verbunden werden, und nach einem vollständigen Standort-Failover führt der Tenant das Failback für jede VM des Cloud-Failover-Plans gesondert aus, in einer schriftlich festgelegten Reihenfolge.

In VMware Live Site Recovery entsteht, wenn ein geschützter Standort nach einem Disaster Recovery wieder online kommt, das, was Broadcom „ein Split-Brain-Szenario“ nennt: Produktions-VMs an beiden Standorten, bis der Plan erneut als Planned Migration läuft, die sie am geschützten Standort ausschaltet und die Wiederherstellung abschließt; ein Reprotect, eine Planned Migration zurück und ein zweites Reprotect bilden dann das Failback, wie unser Artikel zu VMware Live Site Recovery nach Broadcom erklärt.

Schreibvorgänge, die nach dem letzten Replikationslauf und bis zur Isolierung des Primärstandorts die primären Systeme erreicht haben, bilden die Abweichung; sie wird kleiner, wenn ein Disaster Recovery in Live Site Recovery „zuerst eine Speichersynchronisierung versucht“ und diese gelingt. Das Failback bringt die primären Festplatten auf den Stand des Ausweichstandorts, und Broadcoms Reprotect „erzwingt die Synchronisierung des Speichers vom neuen geschützten Standort zum neuen Wiederherstellungsstandort“; nach unserer Lesart gehen diese Schreibvorgänge daher verloren, sofern sie nicht vorher extrahiert werden, aus einer Kopie der alten VM oder aus ihren Datenbankprotokollen. Undo Failover arbeitet umgekehrt, kehrt zur ursprünglichen VM zurück und verwirft „alle Änderungen, die am VM-Replikat während seiner Laufzeit vorgenommen wurden“.

1. Halten Sie die VMs des reparierten Primärstandorts bis zur Umschaltung ausgeschaltet oder vom Netz getrennt.
2. Vereinbaren Sie mit den Datenverantwortlichen, welche auf der Primärseite verbliebenen Schreibvorgänge extrahiert und welche aufgegeben werden.
3. Schalten Sie in einem vereinbarten Wartungsfenster mit Rollback-Plan um, denn die Systeme stehen still, während die letzten Änderungen übertragen werden.
4. Richten Sie DNS-Einträge, Zuordnungen öffentlicher Adressen, VPN-Peers und Firewall-Regeln wieder auf den Primärstandort aus.
5. Lassen Sie die Systemverantwortlichen die ursprünglichen Systeme testen und führen Sie dann Commit Failback aus, oder machen Sie das Failback rückgängig und schalten Sie das Netzwerk wieder auf das Replikat um.
6. Stellen Sie die Replikation in ihrer ursprünglichen Richtung wieder her und prüfen Sie, ob Backups die primären Systeme schützen.

Ein Permanent Failover behält das Replikat als Produktion bei, was Veeam für akzeptabel hält, wenn Original und Replikat „sich am selben Standort befinden und hinsichtlich der Ressourcen nahezu gleichwertig sind“. Bei Cloud Connect folgt er auf einen vollständigen Standort-Failover und entfernt die Wiederherstellungspunkte des Replikats; „andere Jobs werden nicht automatisch geändert“, passen Sie Backup-Jobs also selbst an.

Unser Service Cloud Disaster Recovery schaltet am Tag der Katastrophe nach einem geprobten Szenario auf den Ausweichstandort um und führt nach Wiederherstellung der Primärseite das Failback aus. Nennen Sie uns, welche Systeme zuerst vom Ausweichstandort aus laufen würden und wer den Notfall ausrufen darf.

Was wir tun

Im Rahmen unseres Service Cloud Disaster Recovery definiert unser Engineering-Partner Vixen.UNO gemeinsam mit Ihnen die kritischen Systeme, Ziel-RPO und -RTO je Systemstufe und die Katastrophenszenarien, gegen die Sie sich absichern; das Ergebnis ist ein Continuity-Plan. Virtuelle Maschinen werden ab einem 15-Minuten-Intervall via Veeam Cloud Connect in Baltnetas Tier-3-Rechenzentren in Litauen (ISO 27001, PCI DSS) repliziert, verwaltet aus Ihrer bestehenden Veeam-Konsole oder komplett auf unserer Seite, mit planmäßigen Failover-Tests in isolierter Umgebung und einem Bericht nach jedem Test. Am Tag der Katastrophe erfolgt das Umschalten auf den Ausweichstandort nach dem geprobten Szenario, nach Wiederherstellung der Primärseite folgt das Failback, und Support, RPO und RTO sind im SLA fixiert.

FAQ