RTO und RPO: Unterschied, Beispiele und typische Zielwerte
Recovery Time Objective und Recovery Point Objective einfach erklärt
RTO beschreibt, wie lange ein System maximal ausfallen darf. RPO beschreibt, wie viel Datenverlust maximal tolerierbar ist. Wer Wiederanlauf, Backup oder Hochverfügbarkeit plant, muss beide Werte gemeinsam festlegen.
| Begriff | Bedeutung | Praxisfrage |
|---|---|---|
| RTO | Recovery Time Objective | Wie schnell muss das System wieder laufen? |
| RPO | Recovery Point Objective | Wie viele Minuten Datenverlust sind akzeptabel? |
Was ist RTO?
RTO steht für Recovery Time Objective und beschreibt die maximal tolerierbare Ausfallzeit: Wie lange darf ein System nach einem Ausfall höchstens nicht verfügbar sein, bevor ein spürbarer Schaden entsteht?
Beispiel: Wenn ein ERP-System spätestens nach 15 Minuten wieder verfügbar sein muss, liegt das RTO bei 15 Minuten.
Was ist RPO?
RPO steht für Recovery Point Objective und beschreibt den maximal tolerierbaren Datenverlust, gemessen als Zeitspanne seit dem letzten konsistenten Datenstand: Wie alt darf der letzte gesicherte Stand höchstens sein?
Beispiel: Wenn höchstens 5 Minuten Datenverlust akzeptabel sind, liegt das RPO bei 5 Minuten.
Unterschied zwischen RTO und RPO
RTO fragt: Wie lange darf es dauern? RPO fragt: Wie viel darf fehlen? RTO begrenzt die Ausfallzeit, RPO den Datenverlust. Beide Werte sind keine IT-Wunschzahlen, sondern Business-Entscheidungen — und sie werden gemeinsam festgelegt.
| Frage | RTO | RPO |
|---|---|---|
| Fokus | Zeit bis Wiederanlauf | tolerierter Datenverlust |
| Einheit | Minuten / Stunden | Minuten / Stunden |
| Typische Maßnahme | Failover, HA, DR-Runbook | Replikation, Backup-Frequenz |
RTO/RPO-Beispiele für typische Systeme
| System | Typisches RTO | Typisches RPO | Auswirkung |
|---|---|---|---|
| ERP / Warenwirtschaft | 30-60 Minuten | 0-15 Minuten | Aufträge, Lagerbewegungen und Abrechnung geraten ins Stocken. |
| Fileserver | 1-4 Stunden | 15-60 Minuten | Teams finden Dokumente nicht, parallele Bearbeitung und Ablagen stocken. |
| E-Mail / Kollaboration | 2-8 Stunden | 1-4 Stunden | Kommunikation leidet, ist aber oft temporär durch Ersatzwege möglich. |
| Produktionssystem / Leitstand | 0-15 Minuten | 0 Minuten | Stillstand wirkt sofort auf Maschinen, Schichten und Liefertermine. |
Richtwerte zur Planung. Die tatsächlichen Ziele müssen je Unternehmen über Prozess- und Ausfallkosten bestimmt werden.
Welche Zielwerte sind realistisch?
RTO und RPO für Standard-IT
Für viele Office-, Datei- und Kollaborationssysteme sind RTO von einigen Stunden und RPO von bis zu einer Stunde oft vertretbar. Klassisches Backup mit geplanter Wiederherstellung reicht hier in der Regel aus.
RTO und RPO für kritische Systeme
Bei ERP, Produktions- oder Leitsystemen rücken die Werte Richtung Minuten oder null. Dann sind HA-Cluster, Replikation oder Fehlertoleranz nötig, weil ein langsamer Wiederanlauf sofort Schaden verursacht.
Wann Backup nicht mehr reicht
Sobald RPO gegen null geht, reicht ein Backup-Intervall nicht mehr — es braucht synchrone Replikation oder Fehlertoleranz. Geht das RTO gegen null, ist auch ein Failover mit Neustart oft zu langsam.
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.
Welche Technik beeinflusst RTO und RPO?
RTO und RPO sind Ziele — erreicht werden sie über die passende Schutzarchitektur. Vier Bausteine prägen die Werte:
| Baustein | Wirkung auf RTO und RPO |
|---|---|
| Backup | Bestimmt, auf welchen Datenstand zurückgesetzt werden kann — prägt vor allem das RPO. |
| Replikation | Synchron oder asynchron — senkt den möglichen Datenverlust und damit das RPO deutlich. |
| Cluster-HA | Übernimmt nach Ausfall auf einem anderen Host — verbessert das RTO, mit kurzer Unterbrechung. |
| Fehlertoleranz | Hält den Betrieb ohne spürbare Unterbrechung — bringt RTO und RPO praktisch gegen null. |
Welche Schutzklasse zu Ihren Zielen passt, zeigt der Vergleich von Fehlertoleranz vs. Hochverfügbarkeit. Wer ohnehin die Plattform wechselt, sollte RTO/RPO bei der Wahl der VMware-Alternative direkt mitbewerten und die Kosten mit dem Downtime-Rechner gegenrechnen.
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 ist wichtiger: RTO oder RPO?
Keiner der beiden Werte ist grundsätzlich wichtiger. Sie beantworten unterschiedliche Fragen: RTO begrenzt die Ausfallzeit, RPO den Datenverlust. Welcher Wert kritischer ist, hängt vom System ab — bei Produktionssystemen zählt oft das RTO, bei datenintensiven Systemen das RPO.
Was ist ein gutes RTO?
Ein gutes RTO ist eines, das zum Geschäftsrisiko passt. Für unkritische Systeme können mehrere Stunden ausreichen, für ERP oft 30-60 Minuten, für Produktions- oder Leitsysteme eher 0-15 Minuten. Entscheidend ist, dass der Wert aus Ausfallkosten abgeleitet und im Recovery-Test bestätigt wurde.
Was ist ein gutes RPO?
Ein gutes RPO orientiert sich daran, wie viel Datenverlust ein Prozess verkraftet. Für viele Standardsysteme sind 15-60 Minuten vertretbar, für Transaktions- oder Produktionsdaten oft nur wenige Minuten oder null. Je kleiner das RPO, desto eher braucht es Replikation statt reiner Backups.
Wie hängen RTO, RPO und Hochverfügbarkeit zusammen?
RTO und RPO sind die Zielwerte, Hochverfügbarkeit ist eine der Maßnahmen, um sie zu erreichen. Ein HA-Cluster verbessert vor allem das RTO. Für ein sehr niedriges RPO braucht es zusätzlich Replikation, für ein RTO und RPO nahe null Fehlertoleranz.
Wann brauche ich Fehlertoleranz statt Backup oder HA?
Fehlertoleranz ist nötig, wenn sowohl RTO als auch RPO praktisch null sein müssen. Backup schützt den Datenstand, ein HA-Cluster verkürzt die Ausfallzeit, lässt aber einen Neustart und möglichen Verlust von Daten im Arbeitsspeicher zu. Bei Produktions- oder Leitsystemen reicht das oft nicht.
Realistische RTO- und RPO-Ziele festlegen
Wir helfen Ihnen, für Ihre kritischen Systeme realistische RTO- und RPO-Ziele festzulegen und die passende Schutzarchitektur abzuleiten.
+49 30 802020990