RPO und RTO einfach erklärt

Warum Wiederherstellung messbare Ziele braucht

Eine Datensicherung ist kein Selbstzweck. Sie erfüllt ihren Zweck erst, wenn nach einem Ausfall oder Verlust ein Betriebszustand wiederhergestellt werden kann, der für das Unternehmen tragbar ist. Was „tragbar“ bedeutet, lässt sich nicht technisch ableiten, sondern muss aus den Anforderungen der Geschäftsprozesse bestimmt werden. Dafür haben sich in der Notfallplanung zwei Kennzahlen etabliert: das Recovery Point Objective (RPO) und das Recovery Time Objective (RTO).

Die Begriffe finden sich in Rahmenwerken zur Notfallplanung wieder, etwa im Contingency Planning Guide NIST SP 800-34, der zusätzlich die Maximum Tolerable Downtime (MTD) als Obergrenze einführt. Im deutschsprachigen Raum behandelt der BSI-Standard 200-4 das Business Continuity Management. Beide Quellen machen deutlich, dass Wiederherstellungsziele aus der Betrachtung von Geschäftsprozessen entstehen und nicht aus der Technik.

Der Nutzen der beiden Kennzahlen liegt in der Übersetzung: Sie überführen die vage Forderung „Die Daten müssen wieder da sein“ in zwei überprüfbare Fragen. Bis wann muss das System wieder laufen, und welcher Datenstand muss dann mindestens vorliegen?

Recovery Point Objective: Wie viel Datenverlust ist tragbar?

Das RPO bezeichnet den maximal tolerierbaren Zeitraum, für den Daten nach einem Ereignis verloren gehen dürfen. Es wird in Zeiteinheiten ausgedrückt und beschreibt den Abstand zwischen dem Ereigniszeitpunkt und dem Zeitpunkt des letzten wiederherstellbaren Datenstands. Ein RPO von vier Stunden bedeutet: Es ist akzeptabel, dass die Arbeit der letzten vier Stunden vor dem Ereignis neu erledigt werden muss.

Das RPO ist damit unmittelbar an das Sicherungsintervall gekoppelt. Wird ein System einmal täglich gesichert, kann im ungünstigsten Fall, wenn das Ereignis kurz vor der nächsten Sicherung eintritt, ein ganzer Tag an Änderungen fehlen. Genau genommen kommen weitere Einflussgrößen hinzu: Die Sicherung bildet den Datenstand zu Beginn des Laufs ab und nicht zu dessen Ende. Ein fehlgeschlagener Lauf verlängert die Lücke um ein weiteres Intervall. Und bei Verfahren, die Daten zunächst puffern oder asynchron übertragen, kommt die Übertragungsverzögerung hinzu.

Ein erreichbares RPO ist deshalb stets das Ergebnis aus Intervall, Laufzeit, Fehlerquote der Sicherungsläufe und Übertragungsweg. Ein eingestelltes Intervall allein ist noch keine Aussage über das tatsächlich erreichte RPO.

Recovery Time Objective: Wie lange darf der Ausfall dauern?

Das RTO beschreibt die angestrebte Zeitspanne zwischen dem Eintritt eines Ausfalls und dem Zeitpunkt, zu dem ein Dienst oder System wieder in einem definierten Zustand zur Verfügung steht. Es ist ein Zielwert und keine Zusage. Gemessen wird nicht nur die reine Kopierzeit der Daten, sondern die gesamte Strecke bis zum wieder nutzbaren Dienst. Sie setzt sich aus mehreren Phasen zusammen:

• Erkennung und Alarmierung: Wann fällt der Ausfall überhaupt auf, und wer erfährt davon?
• Bewertung und Entscheidung: Lässt sich der Fehler vor Ort beheben, oder wird wiederhergestellt?
• Bereitstellung der Zielumgebung: Hardware, virtuelle Maschine oder Cloud-Ressourcen müssen verfügbar sein.
• Datenübertragung und Wiederherstellung: Die Sicherung wird zurückgespielt.
• Anwendungsstart und Konsistenzprüfung: Datenbanken und Dienste müssen in der richtigen Reihenfolge starten.
• Fachliche Prüfung und Freigabe: Jemand muss bestätigen, dass der Datenstand brauchbar ist.

Wie stark die Datenmenge die Wiederherstellungszeit prägt

Wie stark allein die Datenübertragung ins Gewicht fällt, zeigt eine einfache Überschlagsrechnung. Zwei Terabyte entsprechen rund 16.000 Gigabit. Bei einer idealisierten, voll ausgelasteten Leitung mit einem Gigabit pro Sekunde ergibt das etwa 16.000 Sekunden, also gut vier Stunden. Dabei sind Protokollaufwand, Verschlüsselung, Lastspitzen und alle übrigen Phasen noch nicht berücksichtigt. Reale Werte liegen höher.

Die Rechnung ist ein Gedankenexperiment und keine Prognose für eine bestimmte Umgebung. Sie zeigt aber, warum Aussagen wie „Die Wiederherstellung dauert eine Stunde“ ohne Kenntnis von Datenmenge, Bandbreite und Zielumgebung nicht belastbar sind. Bei großen Datenbeständen verschiebt sich die Frage deshalb oft von der Übertragung zur Vorbereitung: Lokale Kopien, vorbereitete Zielsysteme oder der Start virtueller Maschinen direkt aus dem Backup verkürzen die Strecke, ohne dass die gesamte Datenmenge zuvor bewegt werden muss.

Wie RPO, RTO und Maximum Tolerable Downtime zusammenhängen

RPO und RTO sind voneinander unabhängige Dimensionen. Ein System kann ein sehr enges RPO haben, etwa weil jede Buchung erfasst sein muss, und dennoch ein großzügiges RTO, weil ein Ausfall von einem Tag verkraftbar ist. Umgekehrt kann ein Webauftritt ein kurzes RTO verlangen, aber ein weites RPO, weil sich seine Inhalte selten ändern. Beide Werte sind daher je System und je Prozess getrennt festzulegen.

Die Maximum Tolerable Downtime (MTD) bezeichnet die Ausfalldauer, ab der dem Unternehmen ein nicht mehr akzeptabler Schaden entsteht. Das RTO muss darunter liegen, und zwar mit Abstand: Zwischen RTO und MTD verbleibt die Zeit, die für Prüfung, Nacharbeit der Daten und die Wiederaufnahme des Betriebs gebraucht wird. Wer das RTO nahe an die MTD legt, hat keine Reserve für Störungen während der Wiederherstellung selbst.

Enge Werte sind zudem nicht kostenlos. Ein niedrigeres RPO erfordert häufigere oder laufende Sicherung und damit mehr Speicher, Bandbreite und Last auf den Systemen. Ein niedrigeres RTO erfordert vorbereitete Zielumgebungen, Automatisierung und geübte Abläufe. Die Kosten steigen mit jeder Verschärfung spürbar, weshalb ein einheitlicher Maximalwert für alle Systeme wirtschaftlich selten sinnvoll ist.

Vom Geschäftsprozess zum Zielwert: So legen Sie RPO und RTO fest

Der übliche methodische Weg führt über eine Business-Impact-Analyse. Ausgangspunkt sind die Geschäftsprozesse und nicht die Server. Für jeden Prozess wird bestimmt, welche IT-Systeme er braucht und welcher Schaden bei Ausfall mit zunehmender Dauer entsteht, etwa durch Umsatzausfall, Vertragsstrafen, Fristversäumnis oder Reputationsverlust. Daraus lassen sich die tolerierbare Ausfalldauer und der tolerierbare Datenverlust ableiten.

In der Praxis helfen die folgenden Leitfragen, für jedes System getrennt gestellt:

• Was kostet eine Stunde, ein halber Tag, ein Tag Stillstand, und wo liegt die Schwelle, an der der Schaden sprunghaft steigt?
• Lassen sich die Änderungen der letzten Stunden aus anderen Quellen rekonstruieren, etwa aus Belegen, E-Mails oder Papierunterlagen, und wie aufwendig ist das?
• Von welchen anderen Systemen hängt das System ab, etwa Verzeichnisdienst, Namensauflösung oder Datenbank, und müssen diese zuerst laufen?
• Gibt es Zeiten mit erhöhtem Bedarf, etwa Monatsabschluss, Fristen oder Saisonspitzen?
• Wer entscheidet im Ernstfall, und wer führt die Wiederherstellung durch?

Systeme nach Kritikalität einteilen

Die Antworten führen typischerweise zu einer Einteilung in Klassen. In kleinen und mittleren Unternehmen genügt oft eine dreistufige Einteilung, die als Ausgangspunkt dient und im Einzelfall anzupassen ist:

• Kritisch, zum Beispiel Auftragsabwicklung oder Warenwirtschaft: kurzes Sicherungsintervall oder laufende Erfassung, vorbereitete Zielumgebung, geübte Wiederherstellung
• Wichtig, zum Beispiel Dateiablage oder E-Mail: tägliche Sicherung genügt häufig, eine Wiederherstellung innerhalb eines Arbeitstages kann vertretbar sein
• Unkritisch, zum Beispiel Testsysteme: seltene Sicherung, längere Wiederherstellungszeit vertretbar

Ein konstruiertes Beispiel

Das folgende Beispiel ist konstruiert und dient nur der Veranschaulichung. Die Werte sind keine Empfehlung. Ein Handelsunternehmen betreibt drei Systeme: eine Warenwirtschaft mit Datenbank, einen Dateiserver und einen internen Wiki-Server.

• Warenwirtschaft: Jede Bestellung ist umsatzrelevant und nachträglich schwer zu rekonstruieren. Die Geschäftsführung wünscht ein RPO von wenigen Minuten und ein RTO von einigen Stunden. Das erfordert eine laufende Erfassung der Datenbankänderungen und eine vorbereitete Zielumgebung.
• Dateiserver: Verlorene Arbeitsstände eines Tages lassen sich meist nacharbeiten. RPO und RTO werden auf Arbeitstag-Niveau gelegt, eine nächtliche Sicherung genügt.
• Wiki-Server: Der Dienst ist bequem, aber nicht betriebsnotwendig. Eine wöchentliche Sicherung und eine Wiederherstellungszeit von mehreren Tagen sind vertretbar.

Was das Beispiel zeigt

Der Zielkonflikt wird sichtbar: Dieselbe Backup-Konfiguration für alle drei Systeme wäre entweder für die Warenwirtschaft zu schwach oder für die anderen beiden unnötig aufwendig. Die Differenzierung ist der eigentliche Gewinn der Methode.

Wie Sicherungsverfahren das RPO beeinflussen

Das erreichbare RPO hängt vom eingesetzten Verfahren ab:

• Geplante Backups in festen Intervallen: Das RPO entspricht im ungünstigsten Fall dem Intervall zuzüglich der Laufzeit. Inkrementelle Läufe verkürzen die Laufzeit und erlauben kürzere Intervalle.
• Laufende Erfassung (Continuous Data Protection): Änderungen werden zwischen den geplanten Backups mitgeschrieben, sodass sehr kurze Wiederherstellungspunkte möglich sind. Das Verfahren ist aufwendiger und wird gezielt für ausgewählte Daten eingesetzt, mehr dazu im Beitrag Kontinuierliche Datensicherung (CDP) erklärt.
• Replikation: Sie kann ein sehr kleines RPO erreichen, überträgt aber auch Fehler und Löschungen und liefert ohne zusätzliche Mechanismen keine früheren Stände. Der Unterschied ist Thema des Beitrags Backup, Snapshot, Replikation.

Wie die Wiederherstellungsart das RTO bestimmt

Das RTO wird dagegen vor allem von der Art der Wiederherstellung bestimmt. Das Zurückspielen einzelner Dateien dauert anders als die Wiederherstellung eines kompletten Servers auf neue Hardware oder der Start einer virtuellen Maschine aus dem Backup in einer Cloud-Umgebung.

Typische Fehlannahmen

Rund um RPO und RTO halten sich einige Missverständnisse, die in der Praxis zu falschen Erwartungen führen:

• „Wir sichern täglich, also haben wir ein RPO von null.“ Tatsächlich entspricht das Intervall dem möglichen Verlust und nicht dessen Abwesenheit.
• „Das RTO ist durch den Vertrag mit dem Dienstleister vorgegeben.“ Ohne ausdrücklich vereinbarte und vertraglich abgesicherte Werte ist ein RTO ein internes Planungsziel.
• „Die Erfolgsmeldung des Backup-Jobs belegt die Wiederherstellbarkeit.“ Sie belegt zunächst nur, dass der Job technisch durchgelaufen ist.
• „RPO und RTO gelten für das ganze Unternehmen.“ Sinnvoll ist die Festlegung je System und je Prozess.
• „Das RTO beginnt erst bei der Wiederherstellung.“ Erkennung, Entscheidung und Bereitstellung der Zielumgebung zählen mit.
• „Einmal festgelegte Werte bleiben gültig.“ Datenwachstum, neue Anwendungen und veränderte Prozesse verschieben sie.

Zielwerte durch Tests überprüfen

Ein Zielwert bleibt eine Behauptung, bis er gemessen wurde. Aussagekräftig ist ein Restore-Test, bei dem die Wiederherstellung unter realistischen Bedingungen durchgeführt und die Zeit für jede Phase festgehalten wird. Dabei zeigen sich die Engpässe: eine zu schmale Leitung, eine fehlende Zielhardware, ein unbekanntes Kennwort, eine nicht dokumentierte Startreihenfolge. Zu unterscheiden sind die Stufen vom Test einzelner Dateien über die Wiederherstellung einer Anwendung bis zur Übung eines vollständigen Ausfalls. Eine Anleitung finden Sie im Beitrag Restore-Test: So prüfen Sie Ihr Backup.

Dokumentieren Sie die gemessenen Zeiten und vergleichen Sie sie mit dem Zielwert. Liegt das Messergebnis darüber, bleiben zwei Wege: das Ziel anpassen, wenn die Fachseite das akzeptiert, oder das Verfahren so ändern, dass das Ziel erreichbar wird.

Umsetzung mit der Plattform

Mit der Plattform legen Sie das Sicherungsintervall im Backup-Plan selbst fest und steuern damit das RPO. Für ausgewählte Dateien und Anwendungen auf unterstützten Windows-Systemen lassen sich Änderungen zwischen den geplanten Backups zusätzlich laufend erfassen (Kontinuierliche Datensicherung). Auf die Wiederherstellungszeit wirken Funktionen wie der Start virtueller Maschinen direkt aus dem Backup, die Wiederherstellung auf abweichender Hardware und der Cloud-Failover. Welche Funktion für welches System passt, hängt von Ihrer Umgebung ab.

Verantwortung und Grenzen

Wir sagen keine festen Wiederherstellungszeiten zu. Die tatsächliche Dauer hängt von Datenmenge, Bandbreite, Zielumgebung, Systemkomplexität, Abhängigkeiten, Zustand der Sicherung und der Verfügbarkeit der handelnden Personen ab. Offen zu klären ist außerdem, wer im Ernstfall die Wiederherstellung durchführt, wer die Anwendung prüft und wer die fachliche Freigabe erteilt. Restore-Tests und die fachliche Datenprüfung liegen bei Ihnen oder werden auf Wunsch gegen Vergütung unterstützt. Wenn Sie Ihre Werte gemeinsam mit uns einordnen möchten, hilft ein Gespräch über Ihre Systeme: Zugang anfragen.