RPO und RTO auf einen Blick
Recovery Point Objective und Recovery Time Objective verwandeln die Frage „Wie viel können wir verlieren?" in messbare Ziele. RPO misst akzeptablen Datenverlust in Zeit. RTO misst akzeptable Ausfallzeit in Zeit.
AWS definiert RPO als die maximal akzeptable Zeit seit dem letzten wiederherstellbaren Datenpunkt und RTO als die maximal akzeptable Verzögerung zwischen Dienstunterbrechung und Wiederherstellung.
Blickt rückwärts von der Störung aus. Die maximal akzeptable Lücke zwischen dem letzten nutzbaren Wiederherstellungspunkt und dem Vorfall.
Blickt vorwärts von der Störung aus. Die maximal akzeptable Verzögerung, bevor ein nutzbarer Dienst wieder verfügbar sein muss.
Ein durchgerechnetes Beispiel
Das tatsächliche Datenverlustfenster beträgt vier Stunden; die tatsächliche Wiederherstellungsdauer beträgt zwei Stunden. Wenn das Ziel-RPO vier Stunden und das Ziel-RTO zwei Stunden betrug, wurden beide Ziele erreicht. Wäre der Dienst erst um 20:00 Uhr wiederhergestellt gewesen, wäre das RTO verfehlt worden, obwohl das RPO weiterhin erreicht wurde.
Diese Ziele sollten pro Workload definiert werden — eine öffentliche Website, eine Buchhaltungsdatenbank, ein Identitätsdienst und ein Entwicklungsserver verdienen selten dasselbe Wiederherstellungsziel.
Was RPO und RTO nicht sind
RPO ist nicht einfach die Backup-Häufigkeit
Die Backup-Häufigkeit beeinflusst das RPO stark, aber beide sind nicht identisch. Ein stündliches Backup garantiert kein einstündiges RPO, wenn der Job fehlschlägt, der Wiederherstellungspunkt beschädigt ist, die Replikation verzögert ist, die Anwendung inkonsistent erfasst wurde oder das Repository nicht verfügbar ist. Ein Stundenplan schafft die Möglichkeit, ein einstündiges RPO zu erreichen — verifizierte, zugängliche Wiederherstellungspunkte machen das Ziel erst glaubwürdig.
RTO ist nicht einfach die Wiederherstellungsgeschwindigkeit
Die Wiederherstellungsgeschwindigkeit ist nur ein Teil des RTO. Die vollständige Wiederherstellungszeit kann die Erkennung des Vorfalls, Eskalation, die Entscheidung zur Wiederherstellung, den Zugriff auf Backup-Systeme, die Bereitstellung von Ersatzinfrastruktur, die Datenwiederherstellung, das Starten von Diensten, das Neukonfigurieren von Netzwerken und DNS, die Validierung von Anwendungen, die Wiederanbindung von Nutzern und die Statuskommunikation umfassen. Eine VM lässt sich vielleicht in 30 Minuten wiederherstellen, während die vollständige Anwendung sechs Stunden braucht, um nutzbar zu sein — RTO sollte den gesamten Prozess abdecken, nicht nur die Datenkopie.
RPO- und RTO-Beispiele
Ein tägliches Backup kann für private Dateien ausreichen, bei denen der Verlust eines Tages an Änderungen tolerierbar ist. Ein 15-Minuten-RPO für einen Online-Shop zu erreichen, erfordert dagegen möglicherweise Datenbank-Log-Schutz, Replikation, Automatisierung, Standby-Infrastruktur und getestetes Failover — nächtliche Backups allein würden dieses Ziel nicht erreichen.
RPO/RTO nach Workload-Stufe
Ein einfaches Klassifizierungsmodell vermeidet, jeden Workload einzeln zu gestalten. Dies sind Planungsbeispiele, keine universellen Standards.
Die NIST-Leitlinien zur Notfallplanung empfehlen, Systeme und Abläufe zu bewerten, um Wiederherstellungsanforderungen und Prioritäten zu bestimmen, statt jedes System gleich zu behandeln.
Wie Sie ein RPO definieren
Die Änderungsrate messen
Bestimmen Sie, wie viele Daten der Workload innerhalb von 15 Minuten, einer Stunde, vier Stunden, einem Arbeitstag und einer Woche erzeugt oder ändert. Ein vierstündiges RPO bedeutet für einen statischen Dateiserver etwas ganz anderes als für eine Transaktionsdatenbank.
Die Kosten der Rekonstruktion berechnen
Fragen Sie sich, ob fehlende Daten rekonstruiert werden können — Rechnungen neu erfassen, Transaktionen erneut verarbeiten, Quellsysteme neu synchronisieren. Wenn die Rekonstruktion langsam, teuer oder unmöglich ist, sollte das RPO kürzer sein.
Konsistenz berücksichtigen
Das neueste Backup ist nicht immer der beste Wiederherstellungspunkt. Eine Datenbank oder eine Multi-Service-Anwendung benötigt möglicherweise einen koordinierten, anwendungskonsistenten Wiederherstellungspunkt, der älter ist als der neueste einzelne Datei- oder Volume-Snapshot.
Erkennungsverzögerung berücksichtigen
Beschädigung und Ransomware können tage- oder wochenlang unentdeckt bleiben. RPO beschreibt akzeptablen aktuellen Datenverlust, während die Aufbewahrung bestimmt, wie weit zurück Wiederherstellungspunkte verfügbar bleiben — Sie brauchen beides.
Das Ziel validieren
Vergleichen Sie das gewählte RPO mit dem tatsächlichen Backup-Zeitplan, der Erfolgsrate der Jobs, der Replikationsverzögerung, der Verifizierungsverzögerung, der Anwendungskonsistenz und der Übertragungszeit zum externen Standort. Veröffentlichen Sie kein RPO, das das aktuelle System noch nie nachgewiesen hat.
Wie Sie ein RTO definieren
Den nutzbaren Wiederherstellungszustand festlegen
Definieren Sie, was „wiederhergestellt" bedeutet — Dateien zugänglich, VM gestartet, Datenbank nimmt Verbindungen an, Anwendung besteht Health-Checks, Nutzer können sich anmelden. Ein RTO ist ohne einen vereinbarten Wiederherstellungszustand bedeutungslos.
Jeden Wiederherstellungsschritt abbilden
Dokumentieren Sie die vollständige Abfolge: erkennen, bewerten, erklären, auf Wiederherstellungs-Zugangsdaten zugreifen, Infrastruktur bereitstellen, wiederherstellen oder failovern, neu konfigurieren, validieren, kommunizieren, in den Dienst zurückkehren.
Verantwortlichkeiten zuweisen
Erfassen Sie, wer jede Aufgabe ausführt und wer die Wiederherstellung genehmigen kann. Ein technisch schneller Prozess kann sein RTO verfehlen, weil niemand die Befugnis hat, zu beginnen.
Abhängigkeiten messen
Die Anwendung hängt möglicherweise von DNS, Identität, Netzwerk, Zertifikaten, Datenbanken, Speicher, Secrets, externen APIs und Lizenzierung ab. Das effektive Anwendungs-RTO kann nicht kürzer sein als die langsamste erforderliche Abhängigkeit.
Die vollständige Wiederherstellung testen
Führen Sie eine zeitgemessene Wiederherstellungsübung durch und erfassen Sie die Zeit für Erkennung, Entscheidung, Zugriff auf Backups, Datenwiederherstellung, Infrastrukturkonfiguration, Start der Anwendung, Validierung und Kommunikation. Das gemessene Ergebnis ist nützlicher als das erwartete.
Referenzarchitekturen
Ein praktisches Proxmox-Beispiel
Ein nächtliches VM-Backup kann ein 15-Minuten-Datenbank-RPO allein nicht erfüllen — innerhalb derselben virtuellen Umgebung sind möglicherweise unterschiedliche Schutzmethoden nötig, etwa anwendungsbewusstes Datenbank-Backup oder Transaktionsprotokoll-Schutz zusätzlich zu den häufigen inkrementellen VM-Backups des Proxmox Backup Server.
Ein praktisches Beispiel für Homelab und Kleinunternehmen
Ein Homelab könnte für einen Passwort-Manager-Dienst ein einstündiges RPO/vierstündiges RTO definieren, aber für wegwerfbare Test-VMs kein formales RPO. Ein Kleinunternehmen könnte für seine Buchhaltungsdatenbank ein vierstündiges RPO/achtstündiges RTO und für sein Kundenportal ein einstündiges RPO/vierstündiges RTO definieren. Die Ziele sollten mit den Personen abgestimmt werden, die die operativen Auswirkungen verstehen — die IT sollte nicht jedes Wiederherstellungsziel allein festlegen.
Technologie, Aufbewahrung und Verfügbarkeit
Keine einzelne Technologie erfüllt automatisch beide Ziele.
AWS gruppiert Disaster-Recovery-Ansätze in Strategien mit zunehmender Bereitschaft und abnehmender Wiederherstellungszeit — Backup and Restore, Pilot Light, Warm Standby und Multi-Site — und empfiehlt regelmäßige Tests, um festzustellen, ob die Architektur ihre Ziele tatsächlich erfüllen kann.
RPO ersetzt nicht Aufbewahrung oder Verfügbarkeit
Ein RPO von einer Stunde mit 30 Tagen Aufbewahrung bedeutet, dass das System auf wiederherstellbare Punkte im Abstand von höchstens einer Stunde abzielt, während ausgewählte Historie für spät entdeckte Probleme erhalten bleibt. Beides ist notwendig — den Aufbewahrungsteil finden Sie im Leitfaden zur Backup-Aufbewahrungsrichtlinie.
Hochverfügbarkeit und Disaster Recovery hängen zusammen, sind aber unterschiedlich: Ein hochverfügbarer Cluster kann trotzdem von Beschädigung, Ransomware oder Administratorfehlern betroffen sein, und ein starkes Backup-System kann eine Anwendung wiederherstellen, ohne durchgehende Verfügbarkeit zu bieten.
Häufige Fehler bei RPO und RTO
Systeme haben unterschiedlichen Geschäftswert und unterschiedliche Abhängigkeiten. Erstellen Sie Workload-Stufen.
Technische Teams unterschätzen möglicherweise die Kosten von Datenverlust oder überschätzen den Bedarf an sofortiger Wiederherstellung. Beziehen Sie Systemverantwortliche ein.
Null Datenverlust erfordert möglicherweise synchrone Replikation und sorgfältig konzipierte Fehlerbehandlung. Das ist teuer und schwierig.
Ein abgeschlossener Job beweist nicht, dass der Wiederherstellungspunkt nutzbar ist. Testen Sie die Wiederherstellung.
RTO umfasst normalerweise den breiteren Störungs- und Wiederherstellungsprozess. Beziehen Sie Erkennungs-, Entscheidungs- und Validierungszeit ein.
Eine Anwendung kann nicht zurückkehren, bevor Identität, Netzwerk, Speicher und Datenbanken bereit sind. Bilden Sie den gesamten Dienst ab.
Replikation kann Beschädigung, Ransomware und Löschung mitkopieren. Bewahren Sie unabhängige historische Wiederherstellungspunkte.
Ein lokales Backup kann das Ziel erreichen, während die externe Kopie um viele Stunden zurückfällt. Messen Sie beides.
Ein Vierstunden-Backup-Zeitplan kann ein 15-Minuten-RPO nicht zuverlässig unterstützen. Ändern Sie die Architektur oder das Ziel.
Geschätzte Wiederherstellungszeiten sind oft optimistisch. Führen Sie zeitgemessene Übungen durch.
RPO- und RTO-Checkliste
0 / 20Häufig gestellte Fragen
RPO misst, wie viel aktueller Datenverlust akzeptabel ist. RTO misst, wie lange der Dienst nicht verfügbar sein darf, bevor er wiederhergestellt werden muss.
Es bedeutet, dass die Wiederherstellung einen Punkt bis zu vier Stunden vor der Störung nutzen darf. Die Organisation akzeptiert die Möglichkeit, bis zu vier Stunden aktueller Änderungen zu verlieren.
Es bedeutet, dass der Dienst innerhalb von vier Stunden nach der Störung in seinen vereinbarten nutzbaren Zustand zurückversetzt werden sollte.
Nein. Die Backup-Häufigkeit hilft, das erreichbare RPO zu bestimmen, aber fehlgeschlagene, beschädigte, verzögerte oder unzugängliche Wiederherstellungspunkte können dazu führen, dass das tatsächliche RPO länger ausfällt.
Nicht immer. RTO kann Erkennung, Entscheidungsfindung, Infrastruktur-Bereitstellung, Wiederherstellung, Konfiguration, Validierung und die Rückführung der Nutzer in den Dienst umfassen.
Ein RPO von null strebt keinen Datenverlust an. Um das zu erreichen, sind möglicherweise synchrone Replikation, Transaktionsschutz auf Anwendungsebene und sorgfältig konzipiertes Failover nötig. Backups allein garantieren selten null Datenverlust.
Ein echtes RTO von null würde keine Unterbrechung bedeuten. High-Availability- und Active-Active-Architekturen können sich einem durchgehenden Dienst annähern, aber komplexe Ausfälle können trotzdem zu Störungen führen.
Beide sind wichtig. Eine schnelle Wiederherstellung mit alten Daten kann inakzeptabel sein, während ein aktueller Wiederherstellungspunkt, dessen Wiederherstellung Tage dauert, ebenfalls die Geschäftsanforderung verfehlen kann.
Replikation kann das RPO verbessern, indem sie Änderungen häufig oder kontinuierlich kopiert. Sie sollte mit aufbewahrten Wiederherstellungspunkten kombiniert werden, da Replikation auch Beschädigung oder Löschung mitkopieren kann.
Backups liefern Wiederherstellungsdaten, aber RTO hängt auch von der Wiederherstellungsgeschwindigkeit, der Infrastrukturbereitschaft, der Personalausstattung, Abhängigkeiten und Tests ab.
Kritische Workloads sollten regelmäßig und nach größeren Infrastruktur- oder Anwendungsänderungen getestet werden. Der Zeitplan sollte die geschäftlichen Auswirkungen und die Komplexität der Wiederherstellung widerspiegeln.
Nein. Wiederherstellungsziele sollten die Wichtigkeit des Workloads, Datenänderungen, Abhängigkeiten, Wiederherstellungskosten und operative Auswirkungen widerspiegeln.
Ziele setzen, die Sie belegen können
RPO und RTO verwandeln Backup und Disaster Recovery von vagen Absichten in messbare Erwartungen. RPO definiert, wie viel aktuelle Arbeit verloren gehen darf; RTO definiert, wie lange die Organisation auf die Rückkehr des Dienstes warten darf.
Der stärkste Wiederherstellungsplan wählt nicht die kleinstmöglichen Zahlen — er wählt Ziele, die reale geschäftliche Auswirkungen widerspiegeln, baut eine Architektur, die sie erfüllen kann, und belegt das Ergebnis durch Tests. Beginnen Sie mit dem wichtigsten Workload, definieren Sie, was nutzbare Wiederherstellung bedeutet, messen Sie den vollständigen Wiederherstellungsprozess, und schließen Sie die Lücke, bevor Sie eine ambitioniertere Zahl in den Plan schreiben.