RTO und RPO sind Geschäftsentscheidungen, keine Backup-Einstellungen

Die Datensicherung läuft erfolgreich, das Ausweichsystem steht bereit und der Dienstleister nennt eine Wiederherstellungszeit. Trotzdem kann im Notfall eine entscheidende Frage offenbleiben: Passt diese technische Lösung überhaupt dazu, wie lange das Geschäft ohne den Prozess arbeiten kann und wie viele Daten verloren gehen dürfen?

RTO und RPO werden häufig dort eingetragen, wo sie technisch konfiguriert werden. Dann bestimmt der vorhandene Sicherungsrhythmus den tolerierten Datenverlust, und die zugesagte Reaktionszeit eines Dienstleisters wird mit dem notwendigen Wiederanlauf verwechselt. Die Reihenfolge gehört umgedreht.

Zuerst beschreibt das Geschäft, ab wann eine Unterbrechung oder ein Datenverlust nicht mehr tragbar ist. Danach entwickelt die IT einen Notbetrieb, eine Wiederanlaufstrategie und einen belastbaren Nachweis. RTO und RPO sind deshalb keine Eigenschaften eines Backup-Produkts. Sie sind übersetzte Geschäftsanforderungen.

Vier Zeitbegriffe beantworten unterschiedliche Fragen

Für eine belastbare Diskussion müssen ähnliche Begriffe getrennt werden:

• Die maximal tolerierbare Ausfallzeit beschreibt, wann die Folgen einer Unterbrechung für den Geschäftsprozess nicht mehr akzeptabel sind.
• Das Recovery Time Objective (RTO) ist das Ziel, innerhalb welcher Zeit ein Prozess oder eine benötigte Ressource in den vorgesehenen Notbetrieb gebracht werden soll.
• Das Recovery Point Objective (RPO) beschreibt den maximal tolerierten Datenverlust als zeitlichen Abstand zwischen dem letzten nutzbaren Datenstand und dem Ausfall.
• Die vollständige Wiederherstellung führt aus dem Notbetrieb zurück in einen geregelten Normalbetrieb und kann deutlich länger dauern als der erste Wiederanlauf.

Der BSI-Standard 200-4 unterscheidet entsprechend zwischen Wiederanlauf, Geschäftsfortführung im Notbetrieb und Wiederherstellung. Diese Trennung verhindert ein typisches Missverständnis: „Das System ist wieder gestartet“ bedeutet noch nicht, dass der Geschäftsprozess wieder ausreichend funktioniert.

Ausgangspunkt ist die Wirkung des Prozessausfalls

Eine Business-Impact-Analyse fragt nicht zuerst nach Servern. Sie untersucht, wie sich die Unterbrechung eines Geschäftsprozesses über die Zeit auswirkt.

Relevante Folgen können sein:

• Aufträge können nicht angenommen, produziert oder ausgeliefert werden,
• gesetzliche oder vertragliche Fristen werden verfehlt,
• Kunden und Lieferanten erhalten keine belastbare Auskunft,
• Sicherheits- oder Qualitätskontrollen fehlen,
• nachgelagerte Prozesse stauen sich,
• manuelle Ersatzverfahren erzeugen Fehler und Nacharbeit,
• Entscheidungen beruhen auf einem veralteten Datenstand.

Die Bewertung sollte Zeitverläufe sichtbar machen. Ein Ausfall kann in der ersten Stunde beherrschbar und nach einem Arbeitstag existenzbedrohend sein. Umgekehrt kann ein Prozess selten laufen, dann aber zu einem festen Stichtag besonders kritisch werden.

Das NIST SP 800-34 Rev. 1 verbindet die Business Impact Analysis ebenfalls mit Wiederherstellungsprioritäten und Anforderungen. Die Publikation richtet sich an US-Bundesbehörden; die Grundlogik, Prozesse und Systeme nach ihrer Wirkung zu priorisieren, ist dennoch übertragbar.

Konstruiertes Beispiel: Der Sicherungsrhythmus wird zur Anforderung

Das folgende Beispiel ist konstruiert.

Ein Auftragssystem wird einmal täglich gesichert. In der Dokumentation steht deshalb ein RPO von 24 Stunden. Die Zahl wurde nicht mit Vertrieb, Disposition oder Produktion abgestimmt; sie beschreibt nur den vorhandenen technischen Rhythmus.

Bei einer Notfallübung stellt sich heraus, dass ein Ausfall am Nachmittag sämtliche Änderungen seit der letzten Nacht verlieren könnte. Der Fachbereich könnte weder sicher erkennen, welche Aufträge bestätigt wurden, noch welche Liefertermine bereits geändert sind. Eine manuelle Rekonstruktion wäre möglich, aber langsam und fehleranfällig.

Die Organisation muss nun nicht reflexartig eine teure Null-Datenverlust-Architektur beschaffen. Sie muss zuerst entscheiden, welcher Verlust in welchem Prozessschritt tragbar ist, welche Daten aus anderen Quellen rekonstruiert werden können und welcher Notbetrieb die wichtigsten Vorgänge schützt. Erst danach lässt sich ein angemessener Sicherungs- oder Replikationsweg wählen.

Ein RTO beschreibt den Mindestbetrieb, nicht die perfekte Rückkehr

Ein zu allgemein formuliertes RTO führt zu unnötiger Technik oder zu Scheinsicherheit. „ERP in vier Stunden wiederherstellen“ lässt offen, welche Funktionen und Daten wirklich benötigt werden.

Für den Wiederanlauf sollte der notwendige Mindestbetrieb beschrieben werden:

• Welche Rollen müssen arbeiten können?
• Welche Kerntransaktionen müssen funktionieren?
• Welche Daten müssen lesbar und welche veränderbar sein?
• Welche Schnittstellen können vorübergehend entfallen?
• Welche manuellen Ersatzwege sind vertretbar?
• Welche Menge oder Geschwindigkeit reicht im Notbetrieb?
• Woran erkennt der Fachbereich, dass der Zustand nutzbar ist?

Ein reduzierter Notbetrieb kann wirtschaftlicher und robuster sein als der Versuch, sofort die vollständige Umgebung wiederherzustellen. Er benötigt jedoch vorbereitete Abläufe, Zuständigkeiten und Kommunikation. Ein improvisierter Excel-Export ist kein Notbetrieb, wenn niemand weiß, wie er erzeugt, verteilt, geschützt und später abgeglichen wird.

Das RPO gilt für einen konsistenten Geschäftsstand

Auch das RPO darf nicht nur pro Datenbank betrachtet werden. Ein Prozess kann Daten in ERP, Dokumentenablage, Integrationsplattform und einem externen Dienst verändern. Wenn diese Komponenten auf unterschiedliche Zeitpunkte zurückgesetzt werden, entsteht trotz formal eingehaltenem Backup-Rhythmus ein widersprüchlicher Zustand.

Deshalb sind zusätzlich zu klären:

• Welche Datenobjekte gehören fachlich zusammen?
• Welche Systeme sind führend und welche erhalten Kopien?
• Wie werden Nachrichten in Warteschlangen oder Schnittstellen behandelt?
• Können Änderungen nach dem Wiederanlauf erneut übertragen werden?
• Wie werden doppelte oder fehlende Buchungen erkannt?
• Welche Protokolle helfen bei einer Rekonstruktion?

Die CMDB als Entscheidungshilfe kann diese Abhängigkeiten sichtbar machen. Eine reine Liste von Servern reicht dafür nicht; benötigt werden Beziehungen zwischen Service, Anwendung, Datenfluss und verantwortlicher Rolle.

Abhängigkeiten setzen die tatsächliche Untergrenze

Ein kritischer Service kann nicht schneller wiederanlaufen als seine zwingenden Abhängigkeiten. Identität, Netzwerk, Namensauflösung, Datenbank, Schlüsselverwaltung, externe Anbindung und Arbeitsplätze bilden eine Kette.

Für jede Kette muss gelten:

• Das RTO der unterstützenden Ressource ist mit dem Ziel des Geschäftsprozesses vereinbar.
• Der Wiederanlauf besitzt eine sinnvolle Reihenfolge.
• Technische und fachliche Prüfschritte sind abgestimmt.
• Externe Anbieter kennen die relevante Anforderung.
• Notwendige Personen, Zugänge und Informationen stehen auch im Störfall zur Verfügung.

Ein Dienstleister-SLA mit acht Stunden Wiederherstellungsziel kann keinen Prozess mit vier Stunden RTO tragen. Ebenso wenig hilft ein schnelles Ausweichsystem, wenn der einzige Administrator keinen Notfallzugang besitzt.

Die RTO-/RPO-Entscheidungskarte

Eine schlanke Entscheidungskarte zwingt Fachbereich und IT, dieselbe Situation zu beschreiben.

Feld	Zu klärende Entscheidung
Geschäftsprozess	Welche Leistung muss fortgeführt werden?
zeitliche Wirkung	Wann werden welche Folgen nicht mehr tolerierbar?
Mindestbetrieb	Welche Rollen, Funktionen, Daten und Mengen werden zuerst benötigt?
RTO	Bis wann muss dieser Mindestbetrieb verfügbar sein?
Datenverlust	Welche Änderungen dürfen verloren gehen oder rekonstruiert werden?
RPO	Welcher letzte konsistente Datenstand wird mindestens benötigt?
Abhängigkeiten	Welche internen und externen Ressourcen bestimmen die Reihenfolge?
Strategie	Replikation, Sicherung, Ersatzsystem, manueller Weg oder Kombination
Verantwortung	Wer entscheidet fachlich, wer stellt technisch wieder her, wer nimmt ab?
Nachweis	Welcher Test belegt Zeit, Datenstand und Nutzbarkeit?

Die Karte ist keine technische Detailanleitung. Sie ist die verbindende Entscheidung zwischen Geschäftsführung, Process Owner, IT-Leitung und Betriebsteam.

Kürzere Ziele kosten nicht nur mehr Technik

Ein kleineres RTO oder RPO erhöht meist Verfügbarkeit, Automatisierung und Redundanz. Es erhöht aber auch weitere Aufwände:

• zusätzliche Plattform- und Lizenzkosten,
• Betrieb und Überwachung redundanter Komponenten,
• komplexere Konsistenz- und Umschaltverfahren,
• häufigere Tests,
• mehr Qualifikation und Rufbereitschaft,
• strengere Verträge mit Dienstleistern.

Deshalb ist „so schnell wie möglich“ keine brauchbare Anforderung. Die angemessene Zielgröße liegt zwischen erwarteter Schadenswirkung und den Kosten einer belastbaren Vorsorge. Sie kann außerdem je Betriebszeit, Saison oder Prozessphase variieren.

Erst ein Test macht die Zielwerte glaubwürdig

Ein RTO wird nicht durch eine Kalkulation erfüllt, sondern durch einen gemessenen Wiederanlauf. Ein RPO wird nicht durch eine konfigurierte Aufbewahrung belegt, sondern durch den tatsächlich nutzbaren und konsistenten Datenstand.

Ein Test sollte mindestens erfassen:

1. Auslöser und angenommene Ausfallzeit,
2. Alarmierung und Entscheidungsdauer,
3. Start und Ende der technischen Wiederherstellung,
4. erreichten Datenstand und festgestellte Lücken,
5. fachliche Abnahme des Mindestbetriebs,
6. Abweichungen, manuelle Schritte und Personenabhängigkeiten,
7. Zeit bis zur vollständigen Rückkehr in den Normalbetrieb.

Der Beitrag „Ein Backup ist erst nach einem erfolgreichen Restore belastbar“ vertieft den technischen Nachweis. Für RTO und RPO kommt die fachliche Prüfung hinzu: Die Daten müssen nicht nur vorhanden, sondern für den vorgesehenen Prozess rechtzeitig nutzbar sein.

Wann eine grobe Klassifizierung genügt

Nicht jedes kleine System braucht eine individuelle Analyse. Für wenig kritische, leicht ersetzbare Dienste können drei oder vier Schutzklassen mit vordefinierten Wiederanlauf- und Sicherungszielen ausreichen. Voraussetzung ist, dass der Service Owner die Zuordnung bewusst bestätigt und Abhängigkeiten nicht verborgen bleiben.

Eine detaillierte Betrachtung wird notwendig, wenn hohe Ausfallfolgen, stark gekoppelte Daten, regulatorische Anforderungen, knappe Zeitziele oder komplexe Lieferketten bestehen. Der Aufwand folgt dem Risiko, nicht der Größe des Servers.

RTO und RPO werden belastbar, wenn sie eine konkrete Geschäftsentscheidung ausdrücken. Dann kann die IT Technik und Notbetrieb zielgerichtet entwerfen, Kosten begründen und im Test zeigen, ob das Leistungsversprechen trägt.