Failover und Failback einfach erklärt

Failover und Failback im Zusammenhang

Failover und Failback sind zwei Hälften eines Vorgangs. Das Failover verlagert den Betrieb eines Dienstes von der ursprünglichen Umgebung auf eine Ersatzumgebung, wenn die ursprüngliche nicht mehr zur Verfügung steht. Das Failback führt den Betrieb später zurück. Im Alltag steht fast immer das Failover im Mittelpunkt, weil es die akute Störung beendet. Das Failback hingegen entscheidet darüber, ob die Organisation nach dem Notbetrieb wieder in einen stabilen, dokumentierten und wirtschaftlich tragfähigen Normalzustand gelangt.

Dieser Beitrag erklärt beide Vorgänge, beschreibt typische Umsetzungsmuster, zeigt die Abhängigkeiten, die in der Praxis am häufigsten Probleme bereiten, und erläutert, wie sich ein Failover prüfen lässt, ohne den laufenden Betrieb zu gefährden. Die begriffliche Einordnung gegenüber Hochverfügbarkeit und Backup nimmt der Beitrag Hochverfügbarkeit vs. Disaster Recovery vor, auf den wir hier verweisen, statt ihn zu wiederholen.

Was bedeutet Failover genau?

Beim Failover übernimmt ein Ersatzsystem die Aufgaben eines ausgefallenen Systems. Dabei kommt es auf drei Fragen an: Wer entscheidet über die Umschaltung, wie aktuell sind die Daten des Ersatzsystems und wie schnell steht es bereit?

Bei der Entscheidung unterscheidet man automatische und manuelle Umschaltung. Eine automatische Umschaltung reagiert auf technische Signale, etwa den Ausfall eines Herzschlags zwischen Clusterknoten. Sie ist schnell, aber anfällig für Fehlalarme, die zu unnötigen Umschaltungen führen. Eine manuelle Umschaltung ist langsamer, erlaubt aber eine Bewertung der Lage, denn nicht jede Störung rechtfertigt den Wechsel in eine Notumgebung. Gerade bei Umschaltungen in eine andere Umgebung, die Kosten verursachen und einen späteren Failback nach sich ziehen, ist eine bewusste Entscheidung mit klarer Zuständigkeit üblich.

Drei Muster, ein Ersatzsystem bereitzustellen

In der Praxis begegnen Ihnen im Wesentlichen drei Muster, die sich in Datenstand, Vorbereitungsaufwand und laufenden Kosten unterscheiden:

• Cluster mit laufender Reserve: Ein zweites System läuft ständig mit und übernimmt bei Ausfall nach kurzer Zeit. Der Datenstand ist sehr aktuell, der Aufwand für Betrieb und Lizenzen dauerhaft hoch. Dies ist die Domäne der Hochverfügbarkeit.
• Replikation auf ein Zielsystem: Daten oder ganze virtuelle Maschinen werden in kurzen Abständen auf ein bereitgehaltenes Zielsystem kopiert, das bei Bedarf aktiviert wird. Der Datenstand ist aktuell, aber nicht identisch mit dem Original. Zudem wird jede Veränderung am Original mit repliziert, auch eine fehlerhafte.
• Start aus dem Backup: Die Ersatzsysteme werden erst im Bedarfsfall aus vorhandenen Sicherungen gestartet, etwa als virtuelle Maschinen in der Cloud. Der Datenstand entspricht dem gewählten Wiederherstellungspunkt, der Start benötigt Zeit, dafür fallen im Normalbetrieb kaum laufende Kosten an.

Welcher Datenstand steht nach dem Failover zur Verfügung?

Unabhängig vom Muster gilt: Nach dem Failover sind nur die Daten vorhanden, die vor dem Ausfall erfasst wurden. Beim Start aus dem Backup entspricht der Stand dem gewählten Wiederherstellungspunkt. Alle Änderungen, die danach im Originalsystem entstanden sind, fehlen. Die Länge dieses Zeitraums bestimmt das Recovery Point Objective (RPO). Welche fachlichen Folgen sie hat, ist je System verschieden: Bei einer Dateiablage lassen sich Dokumente womöglich neu speichern, bei einem Bestellsystem müssen eingegangene Aufträge anderweitig rekonstruiert werden.

Planen Sie deshalb vorab, wie Sie mit der Datenlücke umgehen. Dazu gehören die Frage, wer die fehlenden Änderungen nachträgt, aus welchen Quellen (E-Mails, Belege, Protokolle) das möglich ist und wann die Anwenderinnen und Anwender über den Datenstand informiert werden. Für ausgewählte Daten kann eine kontinuierliche Datensicherung die Lücke verkleinern.

Der Ablauf eines Failovers im Überblick

Ein typischer Ablauf besteht aus diesen Schritten:

• Ausfall feststellen und entscheiden, ob ein Failover nötig ist. Klären Sie vorab, wer entscheidet und wer vertreten wird.
• Wiederherstellungspunkt auswählen. Bei einem Cyberangriff muss er vor der Kompromittierung liegen, siehe Nach Ransomware: Daten sauber wiederherstellen.
• Systeme in der festgelegten Reihenfolge starten, zum Beispiel Verzeichnisdienst und Namensauflösung vor Datenbank und Anwendungen.
• Netzwerk und Zugriff für die Mitarbeitenden herstellen, etwa über VPN, und Zugangsdaten sowie Berechtigungen prüfen.
• Funktion und Datenstand der Systeme fachlich prüfen und die Anwenderinnen und Anwender informieren.
• Ursache der Störung beheben und die Zielumgebung für die Rückführung vorbereiten.
• Failback: Daten und Systeme zurückführen, den Notbetrieb beenden und die Umgebung beobachten.

Wiederanlaufpläne und die Rolle der Abhängigkeiten

Die meisten Schwierigkeiten bei Failover-Übungen entstehen nicht beim Starten einzelner Systeme, sondern bei deren Zusammenspiel. Anwendungen benötigen eine Datenbank, die Datenbank benötigt Speicher und Namensauflösung, die Anmeldung läuft über einen Verzeichnisdienst, und Zertifikate, Lizenzserver oder Schnittstellen zu Drittsystemen müssen erreichbar sein. Wer diese Kette nicht kennt, startet Systeme in der falschen Reihenfolge und verliert Zeit.

Ein Wiederanlaufplan, oft als Runbook bezeichnet, hält daher fest, in welcher Reihenfolge Systeme gestartet werden, welche Prüfungen nach jedem Schritt stattfinden, wer verantwortlich ist und welche Voraussetzungen gelten. Ebenso gehören Netzwerkfragen hinein: Behalten die Systeme ihre IP-Adressen oder werden Adressen und DNS-Einträge angepasst, wie erreichen Mitarbeitende und externe Partner die Notumgebung, und welche Firewall-Regeln gelten dort. Solche Fragen sind in Ruhe zu klären, nicht während des Ausfalls.

Kommunikation und Zuständigkeiten im Ernstfall

Technik allein macht ein Failover nicht erfolgreich. Im Ausfall müssen Entscheidungen schnell fallen, und alle Beteiligten brauchen dieselben Informationen. Legen Sie daher vorab fest, wer die Entscheidung trifft, wer die Umsetzung leitet, wer die Geschäftsleitung, Mitarbeitende, Kunden und gegebenenfalls Dienstleister informiert und über welchen Kanal das geschieht, falls E-Mail und Telefonanlage selbst betroffen sind.

Ebenso gehört dazu, wo der Wiederanlaufplan liegt. Ein Plan, der nur auf dem ausgefallenen Dateiserver gespeichert ist, hilft im Ernstfall nicht. Bewährt hat sich eine aktuelle Fassung außerhalb der eigenen IT, etwa ausgedruckt oder an einem unabhängigen Ort, zusammen mit den Notfallkontakten.

Failback: der unterschätzte zweite Teil

Das Failback wird in der Planung häufig übergangen, weil der Notbetrieb zunächst das drängendere Problem löst. Spätestens nach einigen Tagen stellt sich aber die Frage, wie der Betrieb in die eigene oder eine neu aufgebaute Umgebung zurückkehrt. Die Schwierigkeit besteht darin, dass sich im Notbetrieb Daten verändert haben: Es wurden Aufträge angelegt, Dokumente bearbeitet und Konfigurationen angepasst. Diese Änderungen müssen in die Zielumgebung gelangen, ohne dass dabei Daten verloren gehen oder doppelt entstehen.

Üblicherweise geht man so vor: Zunächst wird die Zielumgebung geprüft und vorbereitet. Dann werden die Daten aus dem Notbetrieb übertragen, gegebenenfalls zunächst als Vorabkopie und anschließend als kurze, abschließende Synchronisation während eines geplanten Zeitfensters. Danach wird der Betrieb umgeschaltet, die Funktion geprüft und der Notbetrieb erst nach einer Beobachtungsphase beendet. Je nach Situation kann es auch sinnvoll sein, die Notumgebung dauerhaft zu behalten und die ursprüngliche Umgebung nicht wieder aufzubauen. Auch das ist eine bewusste Entscheidung, die Sie dokumentieren sollten.

Ein konstruiertes Beispiel

Ein Gedankenbeispiel, das keinen realen Fall wiedergibt: Ein Unternehmen betreibt an einem Standort drei virtuelle Server, einen Domänencontroller, einen Datenbankserver und einen Anwendungsserver. Nach einem Stromschaden ist der Serverraum nicht nutzbar. Der Verantwortliche entscheidet nach Rücksprache mit der Geschäftsleitung, das Failover auszulösen. Die Systeme werden entsprechend dem Wiederanlaufplan in der Cloud gestartet: zuerst der Domänencontroller, danach die Datenbank, zuletzt die Anwendung. Über eine VPN-Verbindung erreichen die Mitarbeitenden die Anwendung wie im eigenen Netz.

Nach zwei Wochen ist der Serverraum instandgesetzt. Das Unternehmen bereitet die Rückführung vor, überträgt die im Notbetrieb entstandenen Daten, setzt für die abschließende Synchronisation ein Zeitfenster am Wochenende an und beobachtet die Systeme in der folgenden Woche, bevor die Notumgebung beendet wird. Der Erfolg dieses Ablaufs hing weniger von einzelnen Werkzeugen ab als davon, dass Zuständigkeiten, Reihenfolge und Netzwerk zuvor festgelegt und getestet waren.

Häufige Fehler und wie Sie sie vermeiden

• Failover wird geplant, Failback nicht. Ergebnis: Der Notbetrieb dauert länger als nötig und die Rückführung wird improvisiert.
• Abhängigkeiten sind nicht dokumentiert, etwa Namensauflösung, Lizenzserver oder Schnittstellen zu Drittsystemen.
• Zugangsdaten und Berechtigungen für die Notumgebung sind nur an einer Stelle gespeichert, die im Ausfall selbst nicht erreichbar ist.
• Der Wiederherstellungspunkt wird nach Datum ausgewählt, ohne zu prüfen, ob er vor einem Angriff liegt.
• Die Übung findet nur auf dem Papier statt. Zeitbedarf und Engpässe zeigen sich erst in einem praktischen Test.

Testen, ohne den Betrieb zu gefährden

Ein Failover-Plan ist erst dann belastbar, wenn er geübt wurde. Man unterscheidet dabei verschiedene Testtiefen. Beim reinen Planspiel gehen die Beteiligten den Ablauf am Tisch durch und finden organisatorische Lücken. Ein Teiltest startet einzelne Systeme in einer abgeschotteten Umgebung und prüft Funktion und Datenstand. Ein vollständiger Test verlagert den Betrieb tatsächlich oder simuliert den Gesamtablauf, bindet allerdings Personal und erfordert Abstimmung mit den Fachbereichen.

Wesentlich ist die Isolation: Ein Test-System darf nicht dieselben Adressen verwenden wie das Produktivsystem und keine Daten aus dem laufenden Betrieb verändern. Dokumentieren Sie nach jedem Test, wie lange einzelne Schritte gedauert haben, was nicht funktioniert hat und welche Maßnahmen daraus folgen. Diese Auswertung liefert zugleich eine belastbare Grundlage für die Festlegung realistischer Zielwerte, siehe Restore-Test: So prüfen Sie Ihr Backup.

Umsetzung mit der Plattform

Die Plattform bietet Cloud-Failover und Failback: Systeme starten aus Ihren Backups in der Cloud, die Reihenfolge legen Sie in Wiederanlaufplänen (Runbooks) fest. Ein Test-Failover läuft in einer isolierten Umgebung, ohne den Betrieb zu stören, einmalig oder regelmäßig. Site-to-Site-VPN, Einzelzugriffe und IPsec-Verbindungen binden die Systeme an Ihr Netz an. Nach dem Vorfall werden Systeme geordnet in Ihre Umgebung zurückgeführt, bei Bedarf schrittweise. Ein Failover ist damit ohne zweiten eigenen Standort möglich.

Abgerechnet wird nur, was im Test oder Ernstfall läuft, nämlich gestartete Systeme, öffentliche IP-Adressen und der Speicher der Wiederherstellungspunkte; die aktuellen Preise nennt die Preisübersicht. Zu beachten ist: Beim Start aus dem Backup müssen die Systeme erst starten. Feste Wiederanlaufzeiten sind nicht zugesagt, denn die Dauer hängt von Datenmenge, Bandbreite, Abhängigkeiten und Vorbereitung ab. Ist ein Server defekt und kein gleicher Ersatz zur Hand, hilft zusätzlich die Wiederherstellung auf abweichender Hardware. Netzwerk und Zugriff bereiten Sie vor, auf Wunsch unterstützen wir Sie gegen Vergütung.

Grenzen

Ein Failover aus dem Backup ersetzt keine Hochverfügbarkeit, es überbrückt einen größeren Ausfall mit einer Unterbrechung. Es setzt voraus, dass verwertbare Sicherungen vorliegen, dass die Abhängigkeiten bekannt sind und dass jemand die Umschaltung verantwortet. Ob der Aufwand für ein System gerechtfertigt ist, bemisst sich an seiner tolerierbaren Ausfallzeit. Wer diese nicht kennt, sollte sie zuerst bestimmen. Lösungsbeispiele finden Sie unter Notfallplan bei Ausfall.