Redundanz und Fehlertoleranz

Jede Komponente kann ausfallen. Festplatten gehen kaputt, Server stürzen ab, Netzwerkkabel werden durchtrennt, Menschen machen Fehler. Ein fehlertolerantes System ist so gebaut, dass der Ausfall einzelner Teile nicht zum Ausfall des Ganzen führt. Das zentrale Werkzeug dafür ist Redundanz: wichtige Teile mehrfach vorhalten, sodass eines das andere ersetzen kann. Diese Lektion zeigt, wo Redundanz nötig ist, wie Umschaltung funktioniert und warum Backups nur so gut sind wie ihre letzte erfolgreiche Wiederherstellung.

1. Einzelne Ausfallpunkte

Einzelne Ausfallpunkte sind nicht immer technisch. Üben Sie, sie zu erkennen:

Eine gute Methode ist, das Architekturdiagramm durchzugehen und bei jedem Kasten und jeder Linie zu fragen: Was passiert, wenn genau das ausfällt? Dazu gehören auch DNS, Zertifikate, Zugangsdaten, der Zahlungsanbieter und das Wissen einzelner Personen. Nicht jeder einzelne Ausfallpunkt muss beseitigt werden – manchmal ist es günstiger, einen seltenen Ausfall hinzunehmen. Aber die Entscheidung sollte bewusst fallen.

2. Aktive und passive Redundanz

Bei aktiver Redundanz arbeiten alle Kopien gleichzeitig, etwa mehrere Anwendungsinstanzen hinter einem Load Balancer. Fällt eine aus, übernehmen die anderen sofort. Bei passiver Redundanz steht eine Kopie bereit, arbeitet aber erst, wenn die Hauptkomponente ausfällt – typisch für Datenbanken mit einem Replikat, das bei Bedarf befördert wird. Diesen Wechsel nennt man Failover. Klicken Sie sich durch einen Datenbank-Failover:

Failover klingt einfach, ist aber heikel. Wird zu schnell umgeschaltet, reicht ein kurzer Netzwerkaussetzer für einen unnötigen Wechsel. Wird zu langsam umgeschaltet, dauert der Ausfall länger. Die größte Gefahr ist Split Brain: Beide Server halten sich für den Primärserver und nehmen Schreibzugriffe an, die sich widersprechen. Verwaltete Datenbankdienste der Cloudanbieter haben diese Abläufe erprobt und sind für die meisten Teams die sicherere Wahl als ein selbst gebautes Failover.

3. Backups

Redundanz schützt vor dem Ausfall von Hardware, aber nicht vor allem. Wenn jemand versehentlich eine Tabelle löscht oder ein Fehler Daten beschädigt, wird die Änderung sofort auf alle Replikate übertragen. Dagegen helfen nur Backups. Zwei Kennzahlen beschreiben sie: Der RPO (Recovery Point Objective) gibt an, wie viele Daten höchstens verloren gehen dürfen. Der RTO (Recovery Time Objective) gibt an, wie lange die Wiederherstellung höchstens dauern darf. Probieren Sie aus:

Für Backups hat sich die 3-2-1-Regel bewährt: drei Kopien der Daten, auf zwei unterschiedlichen Medien, davon eine an einem anderen Ort. Heute kommt oft eine vierte Anforderung hinzu: eine unveränderliche Kopie, die auch ein Angreifer mit Administratorzugang nicht löschen kann – ein wichtiger Schutz gegen Erpressungssoftware. Und vor allem: Backups müssen regelmäßig testweise wiederhergestellt werden. Ein Backup, dessen Wiederherstellung nie geprobt wurde, ist eine Hoffnung, keine Sicherung.

4. Isolation und kontrollierte Verschlechterung

Fehlertoleranz bedeutet auch, dass sich Fehler nicht ausbreiten. Das Bulkhead-Prinzip, benannt nach den Schotten eines Schiffs, trennt Ressourcen so, dass ein Problem in einem Bereich die anderen nicht mitreißt. Ein Beispiel: Die Anwendung nutzt getrennte Verbindungspools für die Buchung und für die langsame Berichtsfunktion. Wenn die Berichte hängen, sind nur deren Verbindungen belegt, und Buchungen funktionieren weiter. Ebenso wichtig ist die kontrollierte Verschlechterung: Fällt ein Nebendienst aus, arbeitet die Anwendung mit eingeschränktem Umfang weiter, statt ganz auszufallen.

5. Verfügbarkeitszonen und Regionen

Cloudanbieter unterteilen ihre Rechenzentren in Regionen, etwa Frankfurt, und innerhalb einer Region in Verfügbarkeitszonen – getrennte Gebäude mit eigener Strom- und Netzwerkversorgung. Verteilt man Anwendungsinstanzen und Datenbankreplikate auf mehrere Zonen, übersteht das System den Ausfall eines ganzen Rechenzentrums, bei nur geringfügig höherer Latenz. Für die meisten Anwendungen ist das der beste Kompromiss. Mehrere Regionen schützen zusätzlich vor dem Ausfall einer ganzen Region, bringen aber erhebliche Komplexität bei der Datenhaltung mit sich – das Modul Moderne Anwendungsmuster greift das auf.

6. Fehler üben

Wie gut ein System Ausfälle verkraftet, zeigt sich erst im Ernstfall – oder in einer Übung. Viele Teams proben deshalb gezielt: Sie schalten eine Instanz ab, simulieren den Ausfall der Datenbank oder stellen ein Backup auf einem leeren Server wieder her. Größere Organisationen betreiben dafür Chaos Engineering, bei dem kontrolliert Fehler in die Produktion eingespielt werden. Für kleinere Teams genügt oft ein halbjährlicher „Ausfalltag“ in einer Testumgebung mit einer einfachen Checkliste. Das Ergebnis sind meist überraschende Erkenntnisse: ein fehlendes Passwort, eine veraltete Anleitung, ein Dienst, der nach dem Neustart nicht von selbst anläuft. Jede dieser Erkenntnisse in der Übung ist ein Ausfall weniger in der Wirklichkeit.

7. Eine Checkliste für den Entwurf

Für die Planung der Fehlertoleranz hilft eine kurze Liste von Fragen. Welche Komponenten sind einzelne Ausfallpunkte, und welche davon lohnt es sich zu beseitigen? Wie lange darf das System höchstens ausfallen, und wie viele Daten dürfen höchstens verloren gehen? Welche Komponenten werden aktiv, welche passiv redundant betrieben, und wer oder was entscheidet über ein Failover? Wo liegen die Backups, wie lange werden sie aufbewahrt, und wann wurde die Wiederherstellung zuletzt geprobt? Welche Funktionen dürfen bei einer Störung wegfallen, und wie wird der Nutzer darüber informiert? Und wer wird im Ernstfall benachrichtigt, mit welcher Anleitung?

Diese Fragen lassen sich auch für ein sehr kleines System beantworten, etwa für eine Zahnarztpraxis mit Online-Terminbuchung. Dort könnte die Antwort lauten: Die Anwendung läuft auf zwei Instanzen bei einem Plattformanbieter, die Datenbank ist ein verwalteter Dienst mit Replikat in einer zweiten Zone und Point-in-Time-Recovery über sieben Tage, einmal täglich wird zusätzlich ein Backup zu einem anderen Anbieter kopiert. Fällt die Verbindung zur Praxissoftware aus, werden Buchungen zwischengespeichert und später übertragen. Einmal im Quartal wird ein Backup testweise wiederhergestellt. Das ist kein großer Aufwand, aber es macht den Unterschied zwischen einem ärgerlichen Vormittag und einem verlorenen Tag voller Termine.

Wichtig ist auch die Dokumentation. Eine kurze Notfallanleitung, die beschreibt, wie ein Backup eingespielt, ein Failover ausgelöst oder eine Version zurückgerollt wird, spart im Ernstfall wertvolle Minuten. Sie sollte an einem Ort liegen, der auch erreichbar ist, wenn das eigene System ausgefallen ist – ein Wiki auf demselben Server hilft dann nicht weiter.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.