Das Recovery Time Objective (RTO) ist die maximal tolerierbare Ausfallzeit eines Systems nach einer Störung – also die Zeitspanne, innerhalb der es wieder verfügbar sein muss. Das RTO blickt nach vorn: Es misst, wie lange der Ausfall dauern darf.
RTO und RPO: die zwei Kennzahlen der Wiederherstellung
Zum RTO gehört immer die Schwester-Kennzahl RPO (Recovery Point Objective): Sie legt fest, wie viel Datenverlust akzeptabel ist, indem sie das maximal erlaubte Alter der letzten Datensicherung angibt. Das RPO blickt nach hinten – es misst, wie weit der letzte konsistente Datenstand zurückliegen darf. Beispiel: Ein RPO von einer Stunde bedeutet, dass höchstens die letzte Stunde an Daten verloren gehen darf; Sicherungen oder Replikation müssen also mindestens stündlich laufen.
Beispiele für RTO-Werte
- Kritischer Webshop: RTO von wenigen Minuten, oft über eine Hot-Standby- oder Failover-Lösung realisiert.
- E-Mail-Server: RTO von wenigen Stunden – andere Mailserver stellen Zustellversuche ohnehin mehrere Tage lang zurück.
- Archivsysteme: RTO von mehreren Tagen, Wiederherstellung aus dem Backup genügt.
Wie entstehen RTO und RPO?
Beide Werte werden in der Business Impact Analyse ermittelt und im Disaster Recovery Plan festgeschrieben. Sie bestimmen direkt die Kosten der Absicherung: Je kleiner RTO und RPO, desto teurer müssen Replikation und Reservesysteme ausgelegt sein. RTO- und RPO-Vorgaben sind außerdem typische Bestandteile von Service-Level-Vereinbarungen.
Verwandte Grundlagen: Disaster Recovery Plan, Business Continuity, Backup.