Disaster Recovery, Backups, RTO/RPO, Failover und vor allem die Frage, die viele Unternehmen sich erst nach einem Ausfall stellen: können wir das System wirklich wiederherstellen und wieder arbeiten?
Serverausfall. Beschädigte Datenbank. Fehler nach einem Deployment. Ransomware. Probleme beim Infrastruktur-Anbieter. Zufälliges Löschen von Daten. Ausfall einer ganzen Region.
Es gibt viele Szenarien. Das Problem ist, dass sich die meisten Unternehmen vor allem darauf vorbereiten, dass der Ausfall gar nicht erst passiert.
Und viel seltener bereiten sie sich auf die Situation vor, in der er doch eintritt.
Genau das ist der Bereich des Disaster Recovery.
Und hier stellt sich die grundlegende Frage: Wenn Ihre Anwendung heute um 14:00 Uhr ausfällt, wie lange brauchen Sie, um sie wieder zu starten, und wie viele Daten können Sie dabei verlieren?
Wenn die Antwort lautet „wir haben ein Backup“, dann ist das noch keine Antwort auf diese Frage.
Backup ist nicht Disaster Recovery
Ein Backup ist eine Kopie von Daten. Disaster Recovery ist ein Prozess zur Wiederherstellung des Systembetriebs.
Das ist eine sehr wichtige Unterscheidung.
Sie können täglich Datenbankkopien erstellen und trotzdem nicht wissen:
-
ob die letzte Kopie korrekt ist,
-
ob sie sich wiederherstellen lässt,
-
wie lange die Wiederherstellung dauert,
-
ob die Datenbank nach der Wiederherstellung mit der aktuellen Version der Anwendung zusammenarbeitet,
-
ob Sie auch die Systemkonfiguration wiederherstellen,
-
ob Sie alle Schlüssel, Zertifikate und Secrets besitzen, die zum Starten der Umgebung benötigt werden,
-
ob die Infrastruktur, die zum Starten der Anwendung erforderlich ist, noch verfügbar ist,
-
wer die einzelnen Schritte ausführen soll,
-
ob der gesamte Prozess innerhalb des geschäftlich akzeptablen Zeitrahmens liegt.
NIST weist ausdrücklich auf die Notwendigkeit hin, die Wiederherstellung von Kopien zu testen, und auch die aktuellen AWS-Leitlinien behandeln periodische Recovery-Tests als eine Möglichkeit, zu prüfen, ob ein Backup tatsächlich das angestrebte RTO und RPO erreicht.
Deshalb ist ein Backup ein Element der Recovery-Strategie, nicht ihr vollständiges Gegenstück.
Die wichtigste Frage: Was passiert nach einem Ausfall?
Stellen wir uns einen Onlineshop vor.
Um 10:17 Uhr reagiert die Datenbank nicht mehr.
Der Anwendungsserver läuft weiter, aber die Nutzer können sich nicht anmelden. Bestellungen funktionieren nicht. Das Administrationspanel reagiert nicht mehr. Das Zahlungssystem erhält keine korrekten Informationen.
Das Team prüft die Situation.
Es stellt sich heraus, dass das letzte Backup der Datenbank um 8:00 Uhr erstellt wurde.
Theoretisch können die Daten wiederhergestellt werden.
Doch dann tauchen weitere Fragen auf;
- Ist bekannt, wo sich die Kopie befindet?
- Ist bekannt, wie sie wiederhergestellt wird?
- Ist die Person verfügbar, die das kann?
- Ist das Backup vollständig?
- Entspricht die Anwendungskonfiguration der in der Kopie gespeicherten Version?
- Wird die Datenbank nach der Wiederherstellung mit der aktuellen Anwendung funktionieren?
- Und das Wichtigste: Wie lange dauert es, den Betrieb des Shops wiederherzustellen?
Wenn das vorher niemand geprüft hat, kann die Antwort überraschend sein.
RTO – wie viel Ausfallzeit können wir akzeptieren?
RTO, also Recovery Time Objective, definiert die maximal akzeptable Zeit zur Wiederherstellung des Systems nach einem Ausfall.
Beispiel: RTO = 4 Stunden bedeutet, dass die Organisation davon ausgeht, den Systembetrieb innerhalb von maximal vier Stunden wiederherstellen zu können.
Das bedeutet jedoch nicht, dass jede Anwendung ein RTO von vier Stunden haben sollte.
Für ein intern genutztes System, das nur wenige Male am Tag verwendet wird, kann diese Zeit akzeptabel sein. Für eine rund um die Uhr verfügbare Verkaufsplattform kann sie sehr hohe Verluste bedeuten.
Das RTO sollte daher aus dem Geschäft heraus definiert werden und nicht daraus, was die Infrastruktur aktuell bietet.
NIST definiert RTO als die Zeitspanne, in der sich ein System in der Wiederherstellungsphase befinden kann, bevor sich dies negativ auf die Geschäftstätigkeit auswirkt.
RPO – wie viele Daten dürfen wir verlieren?
Der zweite grundlegende Parameter ist RPO, also Recovery Point Objective.
RPO beantwortet die Frage: Wie weit können wir im Fall eines Ausfalls bei den Daten zurückgehen?
Beispiel: RPO = 1 Stunde bedeutet, dass die Organisation einen potenziellen Verlust von maximal etwa einer Stunde an Daten akzeptiert.
Wenn das System um 15:00 Uhr ausfällt und das zuletzt nutzbare Backup aus 14:00 Uhr stammt, entspricht genau dieses Szenario dem festgelegten RPO. Wenn ein Backup jedoch nur einmal täglich erstellt wird, ist ein RPO von einer Stunde schwer zu erwarten.
Das RPO beeinflusst daher direkt die Art der Datensicherung, die Replikation von Daten und das Design der Infrastruktur.
RTO sagt uns vor allem wie lange wir nicht verfügbar sein dürfen.
RPO sagt wie viele Daten wir verlieren dürfen.
Diese beiden Parameter sollten gemeinsam mit dem Business festgelegt werden, da ihre Erreichung mit Kosten und technischen Lösungen verbunden ist. Auch Microsoft betont, dass RTO und RPO aus den tatsächlichen geschäftlichen Anforderungen abgeleitet werden sollten und nicht aus der abstrakten Annahme „null Ausfallzeit und null Datenverlust“.
Ein Backup kann existieren und trotzdem nutzlos sein
Das ist einer der gefährlichsten Mythen in der IT.
„Das Backup wird korrekt erstellt“ bedeutet nicht automatisch: „das System lässt sich daraus wiederherstellen“.
Eine Kopie kann unvollständig sein. Sie kann beschädigt sein. Sie kann Daten enthalten, die sich nicht korrekt verwenden lassen. Sie kann auf eine Weise erstellt worden sein, die eine Wiederherstellung der gesamten Umgebung verhindert.
Deshalb muss ein Backup durch eine echte Wiederherstellung getestet werden.
Es reicht nicht aus, nur zu prüfen, ob die Datei existiert.
Man muss sie wiederherstellen.
Das System starten.
Die Daten prüfen.
Abhängigkeiten verifizieren.
Die Konfiguration prüfen.
Die Zeit messen.
Und die Frage beantworten, ob das Ergebnis den RTO- und RPO-Annahmen entspricht.
AWS nennt als typischen Fehler genau das Wiederherstellen eines Backups, ohne zu prüfen, ob die wiederhergestellte Ressource tatsächlich funktioniert und ob die wiederhergestellten Daten nutzbar sind.
Failover – wenn wir nicht auf die Wiederherstellung warten wollen
Nicht jede Anwendung kann es sich leisten, mehrere Stunden auf die Wiederherstellung zu warten. In solchen Fällen werden unter anderem Failover-Mechanismen eingesetzt.
Failover bedeutet, den Betrieb von der primären Umgebung auf eine vorbereitete Ersatzumgebung umzuschalten.
Das kann sein:
-
ein Ersatzserver,
-
eine zweite Verfügbarkeitszone,
-
eine zweite Region,
-
eine Datenbankreplik,
-
eine Standby-Umgebung,
-
eine alternative Infrastruktur, die startbereit ist.
Im einfachsten Modell läuft die Anwendung an einem Ort, und im Falle eines Ausfalls starten wir die Notfallumgebung. In fortgeschritteneren Lösungen läuft ein Teil der Infrastruktur parallel und ist bereit, den Verkehr zu übernehmen.
Es gibt jedoch nicht eine einzige Strategie, die für alle geeignet ist.
Backup und Restore sind in der Regel günstiger, können aber eine längere Wiederherstellungszeit bedeuten. Lösungen wie Warm Standby oder aktive Redundanz können die Recovery erheblich verkürzen, erfordern jedoch höhere Investitionen und eine komplexere Infrastruktur.
Failover muss ebenfalls getestet werden
Hier taucht ein weiteres Problem auf.
Ein Unternehmen kann eine Ersatzumgebung haben, sie aber seit zwei Jahren nicht benutzt haben;
- Funktioniert sie noch?
- Entspricht die Konfiguration der Produktion?
- Hat sie ausreichende Leistung?
- Sind alle Dienste verfügbar?
- Sind die Zertifikate aktuell?
- Wechselt DNS korrekt um?
- Verbindet sich die Anwendung mit der Datenbank?
- Funktioniert der Autorisierungsmechanismus?
- Weiß das Team, was genau es tun soll?
Erst der Test beantwortet diese Fragen.
AWS empfiehlt, Failover regelmäßig genau deshalb zu testen, um den Ablauf des Wiederherstellungspfads zu überprüfen und festzustellen, ob die tatsächlichen RTO und RPO den Annahmen entsprechen.
Eine Disaster-Recovery-Umgebung, die nie getestet wurde, ist nur teilweise eine Annahme.
Disaster Recovery ist nicht nur Infrastruktur
Es ist leicht, DR ausschließlich durch die Brille von Servern zu betrachten.
Das ist ein Fehler.
Recovery umfasst auch:
- Daten
Sind alle wichtigen Daten geschützt? - Anwendung
Haben wir die richtige Code-Version und die Möglichkeit, sie bereitzustellen? - Konfiguration
Wissen wir, welche Einstellungen nötig sind, um das System zu starten? - Geheimnisse und Zertifikate
Haben wir sicheren Zugriff auf Schlüssel, Tokens und Zertifikate? - Externe Abhängigkeiten
Was passiert, wenn ein externes Zahlungssystem, API, Identitätsanbieter oder ein SaaS-Dienst nicht verfügbar ist? - Infrastruktur
Haben wir einen Ort, an dem die Anwendung gestartet werden kann? - Menschen
Ist klar, wer die Entscheidung über das Auslösen des Verfahrens trifft? - Prozeduren
Gibt es ein konkretes Runbook, oder basiert Recovery auf dem Wissen einer einzelnen Person?
Letzteres ist besonders wichtig.
Wenn nur ein Administrator weiß, wie man das System wiederherstellt, haben wir noch kein belastbares Verfahren. Wir haben eine Abhängigkeit von einer konkreten Person.
Der schlechteste Zeitpunkt, um eine Recovery-Prozedur zu schreiben
Das ist der Moment, in dem das System bereits nicht mehr funktioniert.
Dann entstehen Zeitdruck, Stress, Anrufe von Kunden und Fragen des Managements.
Deshalb sollte das Verfahren im Voraus vorbereitet werden.
Es sollte unter anderem festlegen:
-
wann wir Disaster Recovery aktivieren,
-
wer die Entscheidung trifft,
-
welche Systeme die höchste Priorität haben,
-
wo sich die Backups befinden,
-
wie man sie wiederherstellt,
-
welche Abhängigkeiten gestartet werden müssen,
-
wie das Failover abläuft,
-
wie die Funktionsfähigkeit überprüft wird,
-
wie ein Ausfall kommuniziert wird,
-
wann ein Failback beginnen kann,
-
wer die Rückkehr zur Primärumgebung freigibt.
Im Fall eines schweren Ausfalls sollte kein Platz für die Frage sein: „Was tun wir jetzt?”
Das Verfahren sollte diese Frage vorher beantworten.
DR sollte wie eine Anwendungsfunktion getestet werden
Ein guter Ansatz ist es, Recovery ähnlich wie Softwaretests zu behandeln. Es reicht nicht aus, das Verfahren einmal vorzubereiten.
Das System verändert sich.
Die Datenbank wächst.
Abhängigkeiten ändern sich.
Neue Infrastruktur kommt hinzu.
Die Anwendungsversionen ändern sich.
Neue Integrationen entstehen.
Berechtigungen ändern sich.
Deshalb erfordert die Recovery-Strategie ebenfalls eine kontinuierliche Überprüfung.
Der Test kann mit einem einfachen Szenario beginnen: „Die Datenbank ist verloren gegangen. Stellen wir sie aus der letzten Sicherung wieder her.”
Später kann man zu komplexeren Szenarien übergehen:
- „Der Anwendungsserver funktioniert nicht.”
- „Die gesamte Produktionsumgebung ist nicht verfügbar.”
- „Die Daten wurden verschlüsselt.”
- „Die primäre Region der Infrastruktur funktioniert nicht.”
- „Wir haben keinen Zugriff auf den Hauptadministrator.”
Jeder solche Test kann Probleme aufdecken, die im normalen Systembetrieb nicht sichtbar sind.
Benötigt jede Anwendung ein fortgeschrittenes Disaster Recovery?
Nein.
Und auch das ist wichtig.
Eine Infrastruktur zu entwerfen, die gegen jedes mögliche Szenario robust ist, kann unverhältnismäßig teuer sein.
Wenn ein Ausfall einer internen Anwendung eine Stunde Unannehmlichkeiten bedeutet, brauchen wir nicht unbedingt eine Active-Active-Infrastruktur in mehreren Regionen. Wenn jedoch ein Ausfall des Systems bedeutet, dass Vertrieb, Produktion, Kundenservice oder ein kritischer Geschäftsprozess zum Stillstand kommen, sieht die Lage ganz anders aus.
Zuerst sollte der Einfluss des Ausfalls auf das Geschäft bestimmt werden.
Erst danach wählt man die Technologie aus.
Das kann zu verschiedenen Lösungen führen:
Backup + Restore
Eine einfachere und günstigere Lösung für Systeme mit geringerer Kritikalität.
Warm Standby
Die Ersatzumgebung ist teilweise vorbereitet und kann schnell gestartet werden.
Hot Standby
Die Ersatzumgebung läuft in größerem Umfang parallel und ist bereit, die Last zu übernehmen.
Active-Active
Zwei Umgebungen können den Verkehr gleichzeitig bedienen und verringern die Abhängigkeit von einem einzelnen Ausfallort.
Die Wahl der Lösung sollte sich aus RTO, RPO, der Kritikalität des Systems, den Kosten eines Ausfalls und den technischen Möglichkeiten ergeben.
Checkliste: Ist Ihre Anwendung auf einen Ausfall vorbereitet?
Es lohnt sich, ein paar einfache Fragen zu beantworten.
1. Haben wir ein Backup?
Das ist erst der Anfang.
2. Wird das Backup so aufbewahrt, dass es auch vor einem Ausfall der Produktionsumgebung geschützt ist?
3. Haben wir jemals eine vollständige Wiederherstellung durchgeführt?
4. Wie lange dauert ein Restore tatsächlich?
5. Kennen wir das RTO?
6. Kennen wir das RPO?
7. Können wir nicht nur die Daten, sondern auch die Anwendung und ihre Konfiguration wiederherstellen?
8. Haben wir ein Recovery-Verfahren?
9. Können es mehr als eine Person ausführen?
10. Haben wir Failover getestet?
11. Ist die Ersatzumgebung aktuell?
12. Haben wir nach den letzten Änderungen im System das Recovery erneut getestet?
Wenn wir auf mehrere Fragen mit „ich weiß nicht“ antworten, ist das ein sehr guter Zeitpunkt, sich die Disaster-Recovery-Strategie genauer anzusehen.
Der wichtigste Test lautet: „Zeig es“
In der IT ist es sehr leicht zu sagen:
- „Wir haben ein Backup.“
- „Wir haben einen Ersatzserver.“
- „Wir haben ein Verfahren.“
- „Wir haben Disaster Recovery.“
- Aber die Sicherheit des Systems sollte sich nicht ausschließlich auf Aussagen stützen.
Die wichtigste Frage lautet: Zeig, dass du es wiederherstellen kannst.
- Starte den Restore.
- Miss die Zeit.
- Überprüfe die Daten.
- Teste die Anwendung.
- Führe ein Failover durch.
- Prüfe das Verfahren.
- Wiederhole den Test nach wesentlichen Änderungen.
Erst dann kann man sagen, dass die Recovery-Strategie in der Praxis geprüft wurde.
Backup schützt Daten. Recovery stellt das Geschäft wieder her
Das ist wohl der wichtigste Unterschied.
Backup beantwortet die Frage: „Haben wir eine Kopie?“
Disaster Recovery beantwortet eine deutlich schwierigere Frage: „Können wir nach einem Ausfall wieder in den Betrieb zurückkehren?“
Und dazwischen liegt die gesamte Wiederherstellungsarchitektur: RPO, RTO, Replikation, Backups, Restore, Failover, Konfiguration, Verfahren, Verantwortlichkeiten und regelmäßige Tests.
Ein gut konzipiertes System geht nicht davon aus, dass es niemals zu einem Ausfall kommt. Es geht davon aus, dass irgendwann ein Ausfall eintreten wird und man wissen muss, was zu tun ist.
Denn echte Anwendungsresilienz besteht nicht darin, dass nie etwas kaputtgeht. Sie besteht darin, dass die Organisation, wenn etwas schiefgeht, in vorhersehbarer, kontrollierter und den Geschäftsanforderungen entsprechender Weise wieder in den Betrieb zurückkehren kann.
Glossar
Disaster Recovery (DR) - Strategien und Verfahren, die es ermöglichen, den Betrieb von Systemen nach einem schweren Ausfall wiederherzustellen.
Backup - eine Kopie von Daten, die für deren spätere Wiederherstellung bestimmt ist.
Restore - der Prozess der Wiederherstellung von Daten oder eines Systems aus einer Kopie.
RTO (Recovery Time Objective) - die maximal akzeptable Zeit zur Wiederherstellung des Systems.
RPO (Recovery Point Objective) - der maximal akzeptable Datenverlust, ausgedrückt in Zeit.
Failover - die Umschaltung des Systembetriebs von der primären auf die резервistische Umgebung.
Failback - die Rückkehr des Betriebs in die primäre Umgebung nach Behebung der Ausfallursache.
Recovery test - ein Test, der bestätigen soll, dass sich das System tatsächlich gemäß den angenommenen Vorgaben wiederherstellen lässt.
Runbook - eine detaillierte Anleitung für das Vorgehen in einem bestimmten Ausfallszenario.
