Notfallwiederherstellung: RTO und RPO passend festlegen

Die meisten Notfallwiederherstellungspläne scheitern schon an dem Tag, an dem sie geschrieben werden, nicht am Tag des Ausfalls. Jemand wählt runde Zahlen, die sicher klingen, niemand bepreist sie, und die Lücke zeigt sich erst, wenn eine Datenbank bereits in Flammen steht. Der Ausweg besteht darin, RTO und RPO als geschäftliche Entscheidungen mit einem Preis zu behandeln und nicht als technische Ehrenabzeichen.

Was RTO und RPO tatsächlich bedeuten

Zwei Abkürzungen tragen in jedem Gespräch über Notfallwiederherstellung den größten Teil der Last, deshalb lohnt es sich, bei ihnen präzise zu sein.

RTO (Recovery Time Objective) gibt an, wie lange ein System ausfallen darf, bevor die Ausfallzeit einen inakzeptablen Schaden verursacht. Wenn Ihr Checkout-Dienst eine RTO von einer Stunde hat, verpflichten Sie sich, ihn innerhalb von sechzig Minuten nach Beginn eines Vorfalls wieder für Kunden verfügbar zu machen.

RPO (Recovery Point Objective) gibt an, wie viele Daten Sie sich zu verlieren leisten können, gemessen in Zeit. Ein RPO von fünf Minuten bedeutet, dass Sie nach der Wiederherstellung höchstens die letzten fünf Minuten an Schreibvorgängen zu verlieren akzeptieren. Der RPO ist eigentlich eine Aussage darüber, wie häufig Sie einen wiederherstellbaren Zustand erfassen.

Die Falle besteht darin, beide als "so niedrig wie möglich" zu behandeln. Nahezu null bei beiden ist technisch machbar, aber die Kostenkurve ist brutal. Ihre RTO oder RPO zu halbieren verdoppelt die Kosten nur selten. Es vervielfacht sie oft um das Fünf- oder Zehnfache, sobald Sie synchrone Replikation, Standby-Infrastruktur und die Entwicklungszeit hinzufügen, um alles verlässlich zu halten.

RTO und RPO sind nicht dasselbe wie ein SLA

Ein SLA beschreibt den Normalbetrieb, zum Beispiel 99,9 Prozent monatliche Verfügbarkeit. RTO und RPO beschreiben den Ausnahmezustand: einen Regionsausfall, ein Ransomware-Ereignis, eine fehlerhafte Migration, die eine Tabelle beschädigt. Ein Dienst kann sein SLA jahrelang jeden Monat einhalten und dennoch von einer einzigen Katastrophe ausgelöscht werden, für deren Überstehen er nie ausgelegt war. Bewahren Sie diese Kennzahlen in getrennten Dokumenten auf, damit niemand "meist zuverlässig" mit "wiederherstellbar" verwechselt.

Beginnen Sie bei den geschäftlichen Auswirkungen, nicht bei der Infrastruktur

Der häufigste Fehler, den wir sehen, ist, dass Ingenieure RTO und RPO von der technischen Seite her festlegen. Die richtige Reihenfolge ist umgekehrt. Sie beginnen mit einer Analyse der geschäftlichen Auswirkungen und lassen diese die Stufen vorgeben.

Gehen Sie jedes kritische System durch und stellen Sie dessen Verantwortlichem drei einfache Fragen:

1. Wenn dieses System eine Stunde lang ausfällt, was bricht im Geschäft zusammen? Und nach vier Stunden oder einem ganzen Tag?
2. Wenn wir hier die letzten fünfzehn Minuten an Daten verlieren, ist das ein Ärgernis oder ein rechtliches und finanzielles Problem?
3. Was tun die Menschen manuell, während das System ausgefallen ist, und wie lange können sie das aufrechterhalten?

Die Antworten gruppieren sich von selbst. Ein Abrechnungsbuch und ein Marketing-Blog verdienen nicht denselben Schutz, und dafür zu bezahlen, sie gleichermaßen zu schützen, ist der Weg, auf dem Budgets für die Notfallwiederherstellung verschwendet werden. Nach unserer Erfahrung landen die meisten Organisationen bei drei oder vier Stufen statt bei einem einzigen unternehmensweiten Ziel.

Ein praxistaugliches Stufenmodell

Hier ist eine Stufenstruktur, die wir bei Kundenprojekten als Ausgangspunkt verwenden. Passen Sie die Zahlen an Ihre eigene Risikobereitschaft an.

• Stufe 0, geschäftskritisch für die Mission: RTO im Minutenbereich, RPO nahe null. Zahlungen, Authentifizierung, die zentrale transaktionale Datenbank. Diese rechtfertigen einen Hot Standby und synchrone oder nahezu synchrone Replikation.
• Stufe 1, geschäftskritisch: RTO von einer bis vier Stunden, RPO von fünfzehn Minuten. Die primären Anwendungsdienste und ihre unterstützenden Datenspeicher. Ein Warm Standby mit häufiger asynchroner Replikation passt in der Regel.
• Stufe 2, wichtig: RTO von einem Arbeitstag, RPO von einigen Stunden. Interne Werkzeuge, Reporting, Back-Office-Systeme. Eine Wiederherstellung aus dem Backup reicht oft aus.
• Stufe 3, aufschiebbar: RTO von mehreren Tagen, RPO von vierundzwanzig Stunden. Archive, Protokolle, alles, was Sie neu aufbauen können. Günstiger Cold Storage ist hier die richtige Antwort.

Jedes System einer Stufe zuzuordnen ist die wertvollste Stunde, die Sie aufwenden werden, denn sie verwandelt diffuse Sorge in eine kleine Menge konkreter, bepreisbarer Ziele.

Passen Sie die Wiederherstellungsstrategie an die Zahlen an

Sobald jedes System eine Stufe hat, ergibt sich die Strategie fast von selbst. Das klassische Muster hier, bekannt geworden durch Cloud-Referenzarchitekturen, erstreckt sich über vier grobe Ansätze, geordnet vom günstigsten zum teuersten.

• Backup und Wiederherstellung: Regelmäßige Backups in dauerhaften Speicher, Neuaufbau bei Bedarf. Niedrigste Kosten, RTO in Stunden bis Tagen, RPO an die Backup-Häufigkeit gebunden. Richtig für Stufe 2 und Stufe 3.
• Pilot Light: Kerndaten werden kontinuierlich repliziert, eine minimale Infrastruktur bleibt in Betrieb, der Rest wird beim Eintreten der Katastrophe bereitgestellt. Ein guter Mittelweg für viele Systeme der Stufe 1.
• Warm Standby: Eine herunterskalierte, aber stets aktive Kopie der Umgebung, die Sie beim Failover hochskalieren. RTO im Bereich von Minuten bis zu wenigen Stunden.
• Hot Standby oder standortübergreifend aktiv-aktiv: Vollständig duplizierte Kapazität, die live läuft, wobei der Datenverkehr mit geringer oder gar keiner Unterbrechung umgeleitet wird. Die einzige Möglichkeit, die Ziele der Stufe 0 zu erreichen, und entsprechend bepreist.

Der Kompromiss stellt Geld und Komplexität der Wiederherstellungsgeschwindigkeit gegenüber. Aktiv-aktiv liefert Ihnen die beste RTO und RPO, zwingt Sie aber, die Datenkonsistenz über Standorte hinweg zu lösen, verdoppelt einen großen Teil Ihrer laufenden Kosten und fügt eigene Fehlerarten hinzu. Kaufen Sie keinen Schutz der Stufe 0 für ein System der Stufe 2, nur weil die Folie eines Anbieters es einfach aussehen ließ.

Wenn Sie dies gegen Ihre umfassenderen Cloud-Ausgaben abwägen, erklärt unser Leitfaden zur Optimierung von Cloud-Kosten, wie Sie verhindern, dass Standby-Kapazität still und leise zu Ihrem größten Kostenposten wird.

Planen Sie für die Ausfälle, die tatsächlich passieren

Regionsweite Cloud-Ausfälle machen Schlagzeilen, aber sie sind nicht die Katastrophe, auf die wir am häufigsten reagieren. Die alltäglichen Bedrohungen sind banaler und gefährlicher, weil Teams sie unzureichend einplanen.

• Versehentliches Löschen und fehlerhafte Deployments: Eine Migration entfernt eine Spalte, ein Skript kürzt eine Tabelle. Replikation rettet Sie hier nicht, denn sie kopiert den Fehler in Sekunden getreu auf Ihren Standby.
• Ransomware und böswillige Insider: Auch Ihre Backups sind ein Ziel. Wenn sie mit denselben Zugangsdaten wie die Produktion erreicht und verschlüsselt werden können, sind es keine echten Backups.
• Datenkorruption, die sich lautlos ausbreitet: Die schlimmste Art, denn sie kann sich in jede Replik und sogar in aktuelle Backups fortpflanzen, bevor es jemand bemerkt.

Deshalb kann der RPO nicht allein durch Live-Replikation erfüllt werden. Sie brauchen unveränderliche, versionierte und idealerweise offline oder logisch abgeschottete (air-gapped) Backups mit ausreichender Aufbewahrung, um über eine Korruption hinaus zurückzurollen, die Sie nicht sofort bemerkt haben. Ransomware-Resilienz überschneidet sich stark mit Ihrer umfassenderen Sicherheitslage, daher lohnt es sich, dies zusammen mit unserem Leitfaden zur Zero-Trust-Architektur zu lesen. Dasselbe Prinzip, den Wirkungsradius zu begrenzen, gilt unmittelbar für den Schutz Ihrer Wiederherstellungsdaten.

Der Plan ist wertlos, bis Sie ihn testen

Ein Notfallwiederherstellungsplan, der nie ausgeführt wurde, ist eine Hypothese, keine Fähigkeit. Die Lücke zwischen der RTO, die Sie aufgeschrieben haben, und der RTO, die Sie tatsächlich erreichen können, ist meist groß, und Sie finden es erst heraus, wenn Sie die Übung durchführen.

Bauen Sie das Testen in einen Zeitplan ein und steigern Sie den Realismus im Laufe der Zeit:

1. Planbesprechung am Tisch (vierteljährlich): Das Team geht ein Szenario Schritt für Schritt durch. Günstig, und es legt fehlende Runbooks und unklare Zuständigkeiten schnell offen.
2. Wiederherstellung einer Komponente (monatlich): Stellen Sie eine einzelne Datenbank oder einen einzelnen Dienst aus dem Backup in einer isolierten Umgebung wieder her und überprüfen Sie, dass die Daten intakt und nutzbar sind, nicht nur, dass die Datei heruntergeladen wurde.
3. Vollständige Failover-Übung (zweimal im Jahr): Schalten Sie eine ganze Stufe auf ihr Wiederherstellungsziel um und messen Sie die reale RTO mit einer Stoppuhr. Vergleichen Sie sie mit Ihrem Ziel.
4. Game Day mit Überraschungselementen: Sobald die Grundlagen solide sind, bauen Sie eine unerwartete Wendung ein, zum Beispiel eine fehlende Zugangskennung oder ein veraltetes Runbook, um zu testen, wie das Team improvisiert.

Zwei Dinge sorgen dafür, dass sich diese Übungen auszahlen. Erstens: Stoppen Sie immer die Zeit und halten Sie die tatsächlichen Zahlen fest, denn "es fühlte sich schnell an" ist keine Kennzahl. Zweitens: Überprüfen Sie die wiederhergestellten Daten mit echten Prüfungen: Zeilenanzahl, Prüfsummen (Checksums), ein Smoke-Test der Anwendung. Eine Wiederherstellung, die abschließt, aber eine beschädigte Datenbank zurückgibt, hat Ihre RTO erfüllt und Ihr Geschäft vollständig im Stich gelassen.

Häufige Fehlerarten, die es zu vermeiden gilt

Über Audits hinweg treten dieselben Fehler wiederholt auf, und es lohnt sich, sie zu benennen, damit Sie Ihren eigenen Plan daran messen können.

• Ungetestete Backups. Der Backup-Job läuft jahrelang grün und niemand stellt jemals daraus wieder her. Die erste echte Wiederherstellung zeigt, dass ihm die ganze Zeit ein kritisches Schema fehlte.
• Abhängigkeiten ignorieren. Sie führen ein Failover der Anwendung durch, vergessen aber, dass sie DNS, einen Secrets-Speicher, eine Nachrichtenwarteschlange und eine Drittanbieter-API benötigt, die ihren eigenen Ausfall hat. Die Wiederherstellungsreihenfolge ist wichtig, also dokumentieren Sie sie.
• Ein einzelner Ausfallpunkt im Wiederherstellungspfad. Das Runbook liegt nur auf dem Laptop des einen Ingenieurs, der während des Vorfalls nicht erreichbar ist. Speichern Sie es dort, wo es die Katastrophe überlebt.
• Ein RPO, der Daten in Bearbeitung ignoriert. Sie replizieren die Datenbank, aber nicht die Warteschlange unverarbeiteter Ereignisse, sodass die Wiederherstellung Transaktionen verliert, die mitten im Ablauf waren.

Halten Sie den Plan aktuell

Systeme ändern sich wöchentlich, und ein Notfallwiederherstellungsplan, der für die Architektur des letzten Jahres geschrieben wurde, wird die diesjährige nicht wiederherstellen. Koppeln Sie eine leichtgewichtige Überprüfung an Ihren Änderungsprozess, sodass jeder neue Dienst der Stufe 0 oder Stufe 1 vor der Auslieferung eine zugewiesene RTO und RPO erhält. Überarbeiten Sie den vollständigen Plan mindestens zweimal im Jahr und immer nach einem echten Vorfall, denn die Nachbetrachtung des Vorfalls ist Ihre ehrlichste Quelle dafür, was der Plan falsch eingeschätzt hat.

Wie Innovation T helfen kann

Bei Innovation T beginnen unsere Cloud- und DevOps-Dienstleistungen die Notfallwiederherstellung dort, wo sie hingehört: mit einer Analyse der geschäftlichen Auswirkungen, die vage Ängste in eine klare Menge von Stufen verwandelt, jede mit einer RTO und einer RPO, die Sie gegenüber der Finanzabteilung vertreten können. Von dort aus entwerfen wir die passende Wiederherstellungsarchitektur, sei es Backup und Wiederherstellung für Back-Office-Systeme oder ein Warm Standby für Ihren Umsatzpfad, und wir bauen die Automatisierung, die das Failover schnell und wiederholbar macht statt heldenhaft. Wir führen außerdem die Übungen mit Ihnen durch, messen die realen Wiederherstellungszahlen und schließen die Lücke zwischen dem Plan auf dem Papier und dem Plan, der um drei Uhr morgens funktioniert.

Wenn Ihr aktueller Plan noch nie einen echten Test überstanden hat oder Sie nicht sicher sind, wie Ihre wahre RTO heute aussähe, nehmen Sie Kontakt auf. Wir helfen Ihnen, Ziele festzulegen, die zu Ihrem Geschäft passen, und die Resilienz aufzubauen, um sie tatsächlich zu erreichen.