RTO und RPO: Unterschied, Beispiele und Berechnung
Recovery Time Objective und Recovery Point Objective einfach erklärt
RTO beschreibt die maximal tolerierbare Ausfallzeit: Wie schnell muss ein System nach einem Ausfall wieder laufen? RPO beschreibt den maximal tolerierbaren Datenverlust: Auf welchen Datenstand muss das Unternehmen zurückkommen?
Kurz gesagt: RTO schützt die Betriebsfähigkeit, RPO schützt die Datenaktualität. Erst beide Werte zusammen zeigen, ob Backup, HA-Cluster, Disaster Recovery oder echte Fehlertoleranz die richtige Schutzklasse ist.
Was bedeuten RTO und RPO?
Recovery Time Objective
RTO ist die Zielzeit für den Wiederanlauf. Der Wert beantwortet die Frage: Wie lange darf ein ERP, DMS, Server, Shop oder Produktionssystem höchstens ausfallen?
Beispiel: Ein RTO von 30 Minuten bedeutet, dass das System spätestens nach 30 Minuten wieder nutzbar sein muss.
Recovery Point Objective
RPO ist die Zielgrenze für Datenverlust. Der Wert beantwortet die Frage: Wie alt darf der letzte konsistente Datenstand maximal sein?
Beispiel: Ein RPO von 15 Minuten bedeutet, dass höchstens Daten der letzten 15 Minuten verloren gehen dürfen.
RTO/RPO-Merksatz
RTO ist die Uhr für den Wiederanlauf. RPO ist die Uhr für den Datenstand. Je kleiner beide Werte werden, desto eher reichen klassische Backups nicht mehr aus.
Der Unterschied in einem Satz
RTO fragt: Wie lange darf es dauern? RPO fragt: Wie viel darf fehlen? Beide Werte sind keine IT-Wunschzahlen, sondern Business-Entscheidungen. Die Fachbereiche müssen sagen, wann ein Ausfall kritisch wird; die IT muss zeigen, welche Architektur diese Ziele realistisch erreicht.
Ein Backup kann ein gutes RPO liefern, aber ein schlechtes RTO. Ein HA-Cluster kann ein gutes RTO liefern, aber beim Failover trotzdem Daten im Arbeitsspeicher verlieren. Fehlertoleranz ist dann relevant, wenn beides extrem niedrig sein muss.
Wie werden RTO und RPO festgelegt?
RTO und RPO werden aus der geschäftlichen Auswirkung abgeleitet. Eine rein technische Zahl ist gefährlich: Ein Backup-Intervall von 24 Stunden klingt einfach, kann aber für Aufträge, Produktionsdaten oder Dokumentenprozesse zu viel Datenverlust bedeuten.
| Frage | Warum sie zählt | Typischer Output |
|---|---|---|
| Welche Prozesse hängen am System? | Nicht jedes System ist gleich kritisch. | Priorisierung nach Business Impact |
| Was kostet eine Stunde Ausfall? | Ausfallkosten begründen Investitionen. | RTO nach Minuten oder Stunden |
| Wie schnell ändern sich Daten? | Hohe Änderungsrate senkt tolerierbaren Datenverlust. | RPO nach Minuten, Stunden oder Tagen |
| Wurde Recovery getestet? | Ungetestete Ziele sind Annahmen. | Realistische Wiederanlaufzeit |
Als Einstieg hilft eine wirtschaftliche Schätzung: Der Downtime-Rechner zeigt, welche Kosten ein Ausfall verursachen kann. Daraus lassen sich sinnvolle RTO-/RPO-Ziele ableiten.
Beispiele für RTO und RPO im Mittelstand
| System | Typisches RTO | Typisches RPO | Auswirkung |
|---|---|---|---|
| ERP / Warenwirtschaft | 30-60 Minuten | 0-15 Minuten | Aufträge, Lagerbewegungen und Abrechnung geraten ins Stocken. |
| Produktionssteuerung | 0-15 Minuten | 0 Minuten | Stillstand wirkt sofort auf Maschinen, Schichten und Liefertermine. |
| Dokumentenmanagement | 30-120 Minuten | 15-60 Minuten | Freigaben, Verträge, Personal- und Rechnungsprozesse verzögern sich. |
| E-Mail / Kollaboration | 2-8 Stunden | 1-4 Stunden | Kommunikation leidet, ist aber oft temporär durch Ersatzwege möglich. |
Richtwerte zur Planung. Die tatsächlichen Ziele müssen je Unternehmen über Prozess- und Ausfallkosten bestimmt werden.
Von Recovery-Zielen zur Architektur
RTO liegt bei 0-15 Minuten
HA-Cluster kann zu langsam sein; Fehlertoleranz prüfen.
RPO liegt bei 0 Minuten
Backup allein reicht nicht; synchrone Replikation oder FT nötig.
Ausfall betrifft Kunden oder Produktion sofort
Kosten pro Minute berechnen und Schutzklasse erhöhen.
Wiederherstellung wurde nie getestet
RTO/RPO sind Annahmen, keine belastbaren Ziele.
So geht Diventus vor
- Kritische Anwendungen und Abhängigkeiten identifizieren.
- Ausfallkosten mit dem Fachbereich schätzen.
- RTO und RPO pro Anwendung festlegen.
- Ist-Zustand gegen die Ziele prüfen: Server, Internet, Backup, Monitoring.
- Schutzklasse wählen: Backup, HA, Disaster Recovery oder Fehlertoleranz.
Häufige Fragen zu RTO und RPO
Was bedeutet RTO?
RTO steht für Recovery Time Objective. Der Wert beschreibt, wie lange ein System nach einem Ausfall maximal nicht verfügbar sein darf, bevor ein spürbarer Schaden entsteht.
Was bedeutet RPO?
RPO steht für Recovery Point Objective. Der Wert beschreibt, wie viele Daten maximal verloren gehen dürfen, gemessen als Zeitspanne seit dem letzten konsistenten Datenstand.
Was ist der Unterschied zwischen RTO und RPO?
RTO begrenzt die Ausfallzeit, RPO begrenzt den Datenverlust. RTO fragt: Wie schnell muss das System wieder laufen? RPO fragt: Auf welchen Datenstand müssen wir zurückkommen?
Wie berechnet man RTO und RPO?
RTO und RPO werden nicht rein technisch berechnet. Man leitet sie aus Prozesskritikalität, Ausfallkosten, Datenänderungsrate, Kundenwirkung und gesetzlichen oder vertraglichen Anforderungen ab.