Fail Over
Was ist Fail Over?
Fail Over bezeichnet die automatische oder manuell ausgelöste Umschaltung von einem ausgefallenen IT-System auf ein funktionsfähiges Ersatzsystem. Die Ausfallsicherung soll Dienste wie Websites, Datenbanken oder Netzwerke verfügbar halten. Abhängig von Architektur und Umschaltzeit kann trotzdem eine kurze Unterbrechung entstehen.
Wie funktioniert Fail Over?
Fail Over (deutsch: Ausfallsicherung) setzt mindestens zwei voneinander unabhängige Systemkomponenten voraus. Eine aktive Instanz bearbeitet die Anfragen, während eine weitere Instanz bereitsteht oder parallel arbeitet. Erkennt ein Health Check einen definierten Fehler, leitet ein Steuerungssystem den Datenverkehr auf die verbleibende Instanz um.
Ein Health Check prüft in festen Intervallen, ob ein Dienst erreichbar und funktionsfähig ist. Eine erfolgreiche Netzwerkverbindung reicht dafür nicht immer aus: Ein Webserver kann antworten, obwohl die Datenbankverbindung gestört ist oder die Website nur eine leere Seite ausliefert. Aussagekräftige Prüfungen rufen deshalb eine konkrete URL oder Anwendungsfunktion auf und kontrollieren zusätzlich den HTTP-Statuscode sowie den erwarteten Inhalt.
<alert style="info"]Ein Fail Over ist erst abgeschlossen, wenn der Ersatzdienst Anfragen korrekt verarbeitet. Das bloße Starten eines zweiten Servers genügt nicht. DNS, Load Balancer, Datenbank, Sitzungsdaten, Zertifikate und externe Schnittstellen müssen ebenfalls auf die Ersatzumgebung abgestimmt sein.[/alert]
Fail-Over-Varianten im Vergleich
Die geeignete Fail-Over-Architektur hängt davon ab, wie viel Unterbrechung und Datenverlust ein Unternehmen akzeptieren kann. Ein Onlineshop mit laufenden Transaktionen benötigt beispielsweise eine andere Absicherung als eine selten genutzte Informationsseite.
| Variante | Funktionsweise | Typische Eigenschaft |
|---|---|---|
| Active-Passive | Ein System arbeitet, das Ersatzsystem wartet im Bereitschaftsmodus. | Klare Rollen, aber mögliche Startzeit beim Wechsel. |
| Active-Active | Mehrere Systeme verarbeiten gleichzeitig Anfragen. | Last wird verteilt, die Datenhaltung ist komplexer. |
| Warm Standby | Das Ersatzsystem läuft bereits, benötigt aber eine kurze Aktivierung. | Kompromiss zwischen Kosten und Umschaltzeit. |
| Cold Standby | Die Ersatzumgebung wird erst nach dem Ausfall gestartet. | Längere Wiederherstellung, geringer Ressourcenbedarf. |
| Geografisches Fail Over | Der Dienst wechselt in ein anderes Rechenzentrum oder eine andere Region. | Schützt auch bei lokalen Infrastrukturstörungen. |
Active-Active bedeutet nicht automatisch vollständige Ausfallsicherheit. Greifen beide Instanzen auf dieselbe Datenbank, Stromversorgung oder Netzwerkverbindung zu, bleibt dort ein gemeinsamer Ausfallpunkt bestehen. Prüfe jede Komponente vom DNS bis zur Datenspeicherung auf sogenannte Single Points of Failure.
Umschaltzeit und Datenverlust
Die Qualität eines Fail Overs lässt sich nicht allein an der Serveranzahl beurteilen. Zwei Zielwerte beschreiben, was die Architektur leisten muss: Das Recovery Time Objective, kurz RTO, legt die maximal akzeptierte Wiederherstellungszeit fest. Das Recovery Point Objective, kurz RPO, beschreibt den höchstens akzeptierten Datenverlust, gemessen als Zeitraum seit der letzten konsistenten Kopie.
Ein RTO von fünf Minuten bedeutet beispielsweise, dass ein Dienst spätestens fünf Minuten nach dem Ausfall wieder funktionieren soll. Ein RPO von einer Minute erlaubt höchstens den Verlust der Daten, die innerhalb der letzten Minute entstanden sind. Ein schneller Serverwechsel erfüllt das RTO nur dann, wenn Datenbank und Anwendungsdaten auf dem erforderlichen Stand verfügbar sind.
Messbar ist Fail Over durch kontrollierte Ausfalltests und kontinuierliches Uptime-Monitoring. Dabei werden Erkennungszeit, Umschaltzeit, HTTP-Antwort, Seiteninhalt und Datenkonsistenz protokolliert. Die Performance Suite kann die Erreichbarkeit einer Website laufend überwachen und bei Ausfällen alarmieren. Technische 5xx-Fehler lassen sich zusätzlich mit einem Technik-Crawler erfassen.
Fail Over und Hochverfügbarkeit
Der Unterschied zwischen Fail Over und Hochverfügbarkeit liegt im Umfang. Fail Over ist der konkrete Umschaltmechanismus bei einem Fehler. Hochverfügbarkeit ist das übergeordnete Ziel, einen Dienst innerhalb eines definierten Zeitraums möglichst durchgehend nutzbar zu halten. Dazu gehören neben Fail Over auch Redundanz, Monitoring, Wartung, Kapazitätsplanung und regelmäßige Tests.
Die Verfügbarkeit wird als Anteil der funktionsfähigen Betriebszeit berechnet: Betriebszeit geteilt durch Gesamtzeit, multipliziert mit 100. Bei 99,9 Prozent Verfügbarkeit sind in einem Zeitraum von 30 Tagen rechnerisch rund 43 Minuten Ausfall möglich. Dieser Wert sagt jedoch nicht, ob ein einzelner langer Ausfall oder viele kurze Unterbrechungen aufgetreten sind. Prüfe deshalb zusätzlich Anzahl und Dauer der Vorfälle.
Abgrenzung zu Load Balancing
Load Balancing verteilt laufende Anfragen auf mehrere Systeme, um Lastspitzen abzufangen und Ressourcen auszulasten. Fail Over übernimmt Anfragen, nachdem eine Komponente als fehlerhaft erkannt wurde. Ein Load Balancer kann beide Aufgaben verbinden, wenn er den Zustand der Zielsysteme prüft und ausgefallene Instanzen automatisch aus der Verteilung entfernt.
Abgrenzung zu Backup und Disaster Recovery
Ein Backup speichert eine wiederherstellbare Kopie von Daten, übernimmt aber keinen laufenden Dienst. Disaster Recovery beschreibt den umfassenden Wiederanlauf nach schweren Ereignissen, etwa dem Ausfall eines Rechenzentrums. Fail Over überbrückt dagegen einen konkreten Komponentenausfall. Eine belastbare Notfallplanung benötigt häufig alle drei Verfahren.
Relevanz für SEO, SEA und GEO
Ein längerer Serverausfall verhindert, dass Nutzer und Suchmaschinen-Crawler Inhalte abrufen können. Der Server liefert dann häufig einen Statuscode der Klasse 5xx, etwa 500 oder 503. Wiederkehrende Fehler erschweren Crawling und Indexierung. Ein Fail Over begrenzt die Dauer solcher Störungen und schützt damit die technische Grundlage der SEO-Sichtbarkeit.
Bei SEA führt eine nicht erreichbare Landingpage dazu, dass bezahlte Klicks keine Inhalte oder Formulare erreichen. Kampagnen können weiterhin Kosten verursachen, obwohl die Zielseite keine Conversion ermöglicht. Unternehmen sollten deshalb die Verfügbarkeit wichtiger Landingpages überwachen und technische Alarme mit ihren Kampagnenprozessen verbinden.
GEO, also Generative Engine Optimization, benötigt ebenfalls erreichbare und maschinenlesbare Quellen. KI-Crawler können Inhalte nur abrufen, wenn Webserver, robots.txt, Zertifikate und Anwendungen korrekt reagieren. Fail Over schützt die technische Erreichbarkeit, ersetzt aber keine saubere Seitenstruktur oder zitierfähige Inhalte.
Ein technisches SEO-Audit prüft unter anderem Statuscodes, Weiterleitungen, Indexierbarkeit und Serverreaktionen. Ergänzend zeigt ein kostenloser Ladezeiten-Check, ob eine Website stabil und schnell antwortet.
Typische Fehler beim Fail Over
Häufige Fragen zu Fail Over
Was löst ein Fail Over aus?
Ein Fail Over wird durch definierte Fehlerbedingungen ausgelöst, etwa fehlgeschlagene Health Checks, einen nicht erreichbaren Server oder eine gestörte Datenbankverbindung. Die Bedingungen sollten mehrere Prüfungen berücksichtigen, damit eine kurze Verzögerung nicht unnötig zur Umschaltung führt.
Wie lange dauert ein Fail Over?
Die Dauer reicht je nach Architektur von Sekunden bis zu mehreren Minuten. Active-Active-Systeme reagieren meist schneller als Cold-Standby-Umgebungen, die zunächst gestartet und synchronisiert werden müssen.
Kann ein Fail Over Datenverlust verhindern?
Ein Fail Over verhindert Datenverlust nur, wenn die Daten regelmäßig oder fortlaufend auf das Ersatzsystem übertragen werden. Die zulässige Datenlücke wird über das Recovery Point Objective festgelegt.
Muss ein Fail Over automatisch erfolgen?
Ein Fail Over kann automatisch oder manuell ausgelöst werden. Automatische Verfahren verkürzen die Reaktionszeit, benötigen aber klare Prüfbedingungen und Schutzmechanismen gegen fehlerhafte Umschaltungen.
Wie oft sollte man ein Fail Over testen?
Ein Fail Over sollte regelmäßig sowie nach wesentlichen Änderungen an Hosting, Anwendung oder Datenbank getestet werden. Das konkrete Intervall richtet sich nach dem Ausfallrisiko und den festgelegten RTO- und RPO-Zielen.
Was passiert nach der Umschaltung?
Nach der Umschaltung muss das ausgefallene System geprüft, repariert und kontrolliert wieder eingebunden werden. Dieser Rückwechsel wird als Failback bezeichnet und sollte ebenso geplant und getestet sein wie das eigentliche Fail Over.
Wenn du technische Risiken deiner Website strukturiert bewerten möchtest, kannst du einen kostenlosen und unverbindlichen Potenzialcheck anfragen.
Kostenlosen Potenzialcheck anfragen
Sie haben noch Fragen?
