RTO und RPO sind die beiden Kennzahlen, an denen sich jede Notfall- und Backup-Planung ausrichtet: Die Recovery Time Objective (RTO) definiert, wie lange ein System nach einem Ausfall maximal stillstehen darf. Die Recovery Point Objective (RPO) definiert, wie alt der letzte wiederherstellbare Datenstand höchstens sein darf — also wie viel Arbeit im schlimmsten Fall verloren geht.
Beide Werte sind Geschäftsentscheidungen, keine IT-Werte: Sie leiten sich aus den Kosten von Stillstand und Datenverlust je Prozess ab — und bestimmen dann, welche Backup-Frequenz, Replikation und DR-Strategie technisch nötig und wirtschaftlich vertretbar ist.
Was die beiden Kennzahlen bedeuten
Die RTO läuft ab dem Ausfall: Erkennung, Entscheidung, Wiederherstellung, Test, Freigabe — alles muss in die Zeitspanne passen. Eine RTO von vier Stunden bedeutet nicht vier Stunden Restore-Zeit, sondern vier Stunden bis zum nutzbaren System. Die RPO blickt zurück: Bei einer RPO von einer Stunde darf die letzte Sicherung höchstens eine Stunde alt sein — alles danach ist potenziell verloren.
Beide Werte skalieren die Kosten gegenläufig zur Toleranz: RPO nahe null verlangt synchrone Replikation statt nächtlicher Backups; RTO nahe null verlangt laufende Standby-Systeme statt Wiederherstellung aus der Sicherung. Deshalb werden RTO und RPO je Anwendung gestaffelt — nicht pauschal fürs ganze Unternehmen.
Typische Staffelung in der Praxis
- Kritische Kernsysteme (ERP, Produktionssteuerung): RTO Minuten bis wenige Stunden, RPO Minuten — Replikation und Standby.
- Wichtige Fachanwendungen: RTO wenige Stunden bis ein Tag, RPO Stunden — häufige Backups oder Snapshots.
- Unkritische Systeme (Archiv, Test): RTO Tage, RPO 24 Stunden — klassisches tägliches Backup.
- Messen statt hoffen: Restore-Tests belegen die tatsächliche Zeit (RTA) gegen das Ziel.