Alle Begriffe

Glossar

RTO und RPO

Auch: Recovery Time Objective · Recovery Point Objective

Zwei Zahlen für den Ernstfall: Wie lange darf die Wiederherstellung dauern (RTO), und wie viele Daten dürfen dabei verloren gehen (RPO).

Beide Werte sind Geschäftsentscheidungen, keine technischen. Eine Stunde Ausfall kostet in einem Onlineshop etwas völlig anderes als in einem internen Werkzeug, und daraus folgt, wie viel Aufwand die Absicherung rechtfertigt.

Aus RTO und RPO ergibt sich die Architektur, nicht umgekehrt: Ein RPO von null bedeutet synchrone Replikation und damit Latenz und Kosten. Ein RPO von vier Stunden erlaubt ein einfaches Sicherungsverfahren.

Die Zeitrechnung beim RTO beginnt früher, als die meisten annehmen. Sie startet nicht, wenn jemand mit der Wiederherstellung beginnt, sondern wenn der Ausfall eintritt. Dazwischen liegen Erkennung, Alarmierung, Einwahl der Bereitschaft, Lagebeurteilung und die Entscheidung, den Wiederanlauf überhaupt auszulösen. In der Praxis sind das die ersten dreißig bis sechzig Minuten, und sie sind der Grund, warum ein technisch zwanzigminütiger Wiederanlauf ein RTO von einer Stunde reißt.

Beim RPO ist die entsprechende Feinheit die Frage, was „Datenverlust" fachlich bedeutet. Eine Stunde verlorene Bestellungen ist kein Datenproblem, sondern ein Kundenproblem, und je nach Geschäft gibt es einen Weg zurück, etwa wenn die Zahlungen beim Dienstleister noch vorliegen und nachgezogen werden können. Diese Rekonstruierbarkeit verändert die Anforderung erheblich und wird bei der Festlegung selten mitgedacht.

Die Werte gehören nicht pauschal für „das System" festgelegt, sondern je Ablauf. In einem Onlineshop dürfen Bestellannahme und Berichtswesen völlig unterschiedliche Zahlen haben, und diese Differenzierung ist der größte Kostenhebel überhaupt: Eine mehrfach ausgelegte Umgebung für alles ist um ein Vielfaches teurer als eine für den einen Ablauf, bei dem es zählt.

Aus dem Zahlenpaar folgt unmittelbar eine Ausbaustufe. Sicherung mit Wiederherstellung im Bedarfsfall kostet am wenigsten und liefert Stunden bis Tage. Ein kalt vorgehaltenes Abbild verkürzt auf Stunden. Ein klein mitlaufendes zweites System auf Minuten bis eine Stunde. Zwei aktive Umgebungen liefern nahezu null und kosten ungefähr das Doppelte im Betrieb, plus die Komplexität doppelter Datenhaltung.

Was all das wertlos macht, ist die fehlende Übung. Ein Wiederanlaufverfahren, das nie durchgeführt wurde, ist eine Vermutung mit Aktenzeichen.

Woran Sie es erkennen

  • Es gibt Zielwerte, aber niemand hat sie geprüft.
  • Sicherungen laufen, wurden aber nie zurückgespielt.
  • Die Kosten einer Stunde Ausfall sind nicht bekannt.
  • Es gibt eine Zahl für „das System", nicht je Ablauf.
  • Nur eine Person weiß, wie der Wiederanlauf geht.

Nicht zu verwechseln mit

SLA
Eine vertragliche Zusage an Kunden, meist als Verfügbarkeit in Prozent, mit Rechtsfolge. RTO und RPO sind interne Zielwerte für den Katastrophenfall.
Hochverfügbarkeit
Absicherung gegen den Ausfall einzelner Komponenten im laufenden Betrieb. RTO und RPO beschreiben den Fall, in dem das nicht mehr greift.
Backup
Ein Mittel, kein Ziel. Eine Sicherung ohne gemessene Wiederherstellungsdauer sagt nichts über das RTO aus.

Wann es trägt

  • Vor dem Entwurf der Absicherung: die Zahlen bestimmen die Architektur.
  • Wenn ein Kunde oder Prüfer nach Wiederanlaufzeiten fragt.
  • Nach einem Vorfall, um Erwartung und Realität abzugleichen.
  • Bei einer Migration, weil sich Wiederherstellungswege dabei ändern.

Wann nicht

  • Pauschal für die gesamte Landschaft: das führt zur Absicherung nach dem strengsten Fall und ist die teuerste Variante.
  • Als Zahl aus einer Vorlage, ohne die Ausfallkosten zu kennen.

Wie man rangeht

  1. Ausfallkosten je Stunde schätzenUmsatz, Vertragsstrafen, Nacharbeit, Reputationsfolgen. Grob genügt. Ohne diese Zahl ist die Diskussion über Aufwand nicht entscheidbar.
  2. Je Ablauf festlegen, nicht je SystemBestellannahme, Zahlung, Berichtswesen haben unterschiedliche Anforderungen. Diese Differenzierung ist der größte Kostenhebel.
  3. Erkennung und Entscheidung mitrechnenDas RTO beginnt beim Ausfall, nicht beim Beginn der Arbeit. Wer wird wie schnell alarmiert, und wer darf den Wiederanlauf auslösen.
  4. Ausbaustufe daraus ableitenSicherung, kaltes Abbild, klein mitlaufendes zweites System oder zwei aktive Umgebungen. Die Zahl bestimmt die Stufe, nicht der Wunsch.
  5. Vollständig proben, mit StoppuhrAuf Produktionsdatenmenge und ohne die Person, die es gebaut hat. Die Übung deckt fehlende Zugänge, Zertifikate und Reihenfolgen auf.
  6. Gemessene Zahlen gegen die Ziele stellenWeicht die Messung ab, wird entweder investiert oder das Ziel korrigiert. Ein Zielwert, den man nachweislich nicht hält, ist schlechter als ein ehrlicher.

Häufig gefragt

Wie ermittle ich sinnvolle Werte für RTO und RPO?

Aus den Kosten des Ausfalls, nicht aus der Technik. Rechnen Sie durch, was eine Stunde Stillstand in Umsatz, Vertragsstrafen und Nacharbeit kostet. Erst diese Zahl macht die Frage entscheidbar, ob synchrone Replikation ihren Preis wert ist oder eine stündliche Sicherung reicht.

Warum reißen wir das RTO, obwohl die Wiederherstellung schnell geht?

Weil die Uhr beim Ausfall startet, nicht bei Arbeitsbeginn. Erkennung, Alarmierung, Einwahl, Lagebeurteilung und die Entscheidung, den Wiederanlauf auszulösen, verbrauchen in der Praxis dreißig bis sechzig Minuten. Wer die Frist halten will, verkürzt zuerst diese Spanne, und das ist meist billiger als jede Technik.

Wie oft sollte man den Ernstfall proben?

Mindestens jährlich, und zusätzlich nach jeder größeren Änderung an Datenhaltung oder Infrastruktur. Aussagekräftig wird es, wenn die Person, die das Verfahren gebaut hat, nicht mitmacht. Ein Wiederanlauf, den nur eine Person durchführen kann, hat im Urlaub kein RTO.

Braucht man für ein niedriges RPO immer synchrone Replikation?

Nicht zwingend. Manchmal lassen sich verlorene Vorgänge aus einer anderen Quelle rekonstruieren, etwa aus dem Protokoll des Zahlungsdienstleisters oder aus eingegangenen Nachrichten, die noch in der Warteschlange stehen. Diese Rekonstruierbarkeit ist oft deutlich billiger als synchrone Replikation und wird bei der Festlegung fast immer übersehen.

WeiterlesenWenn AWS eine Region verliert