RTO und RPO: Unterschied, Beispiele und typische Zielwerte
Recovery Time Objective und Recovery Point Objective einfach erklärt
Von Reiner Rohde, Geschäftsführer der Diventus GmbH · Aktualisiert am
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 ohne Normbezug, Stand September 2026. Sie geben die Größenordnung vor, mit der Planungen in diesen Systemklassen üblicherweise starten. Die tatsächlichen Ziele müssen je Unternehmen über Prozess- und Ausfallkosten bestimmt werden.
Welches RTO und RPO liefern Backup, Replikation, HA-Cluster und Fehlertoleranz?
Die Zielwerte oben sind Anforderungen. Ob eine Architektur sie erreicht, ergibt sich aus ihrer Schutzklasse. Die Tabelle nennt je Klasse das erreichbare RTO und RPO und woher der Wert stammt.
| Schutzklasse | Erreichbares RTO | Erreichbares RPO | Herleitung |
|---|---|---|---|
| Backup und Wiederherstellung | Stunden bis Tage: Dauer der Wiederherstellung, abhängig von Datenmenge und Durchsatz | entspricht dem Sicherungsintervall, bei täglicher Sicherung bis zu 24 Stunden | RPO ist nach BSI-Standard 200-4 der maximal zulässige Datenverlust; bei reinem Backup ist das die Zeit seit der letzten Sicherung. RTO ist ein Rechenwert aus Datenmenge und Wiederherstellungsdurchsatz. |
| Asynchrone Replikation | Minuten: wie das eingesetzte Failover-Verfahren | Sekunden bis Minuten: die Replikationsverzögerung | Bei asynchroner Replikation wird ein Schreibvorgang bestätigt, bevor die Kopie ihn hat. Der Rückstand ist der mögliche Datenverlust. |
| Synchrone Replikation | Minuten: wie das eingesetzte Failover-Verfahren | 0 für bestätigte Schreibvorgänge | Bei synchroner Replikation wird erst bestätigt, wenn beide Seiten geschrieben haben. Bestätigte Daten liegen an zwei Orten. |
| HA-Cluster (zum Beispiel VMware vSphere HA, everRun Express) | Minuten: Ausfallerkennung plus Neustart der virtuellen Maschine auf einem anderen Host | Stand des gemeinsamen Speichers; Daten, die nur im Arbeitsspeicher lagen, gehen verloren | VMware-Dokumentation: nach Host-Ausfall werden die VMs auf anderen Hosts neu gestartet. Herstellerangabe everRun Express: 99,95 bis 99,99 Prozent Verfügbarkeit (Plattformangabe). |
| Fehlertoleranz (everRun Enterprise FT, ftServer, ztC Endurance) | Betrieb läuft beim Ausfall einer Komponente weiter, kein Neustart der Anwendung | kein Datenverlust durch den Komponentenausfall selbst, auch der Arbeitsspeicher ist gespiegelt | Herstellerangaben: everRun Enterprise und ftServer 99,999 Prozent, ztC Endurance bis 99,99999 Prozent. Plattformangaben, keine vertraglichen Zusagen. |
Herstellerwerte sind Plattformangaben der Hersteller, keine vertraglichen Zusagen. Sie beziehen sich auf den Ausfall einzelner Komponenten, nicht auf Standortausfall, Softwarefehler oder Bedienfehler. Quellen am Seitenende, Stand 08.09.2026.
Wie viel Ausfallzeit pro Jahr bedeutet eine Verfügbarkeit in Prozent?
Rechnung: 8.760 Stunden im Jahr mal dem Anteil, der fehlt. 99,99 Prozent Verfügbarkeit lassen 0,01 Prozent Ausfall zu, also 0,876 Stunden oder 52,6 Minuten.
| Verfügbarkeit | Ausfallzeit pro Jahr | Passende Schutzklasse |
|---|---|---|
| 99 % | 87,6 Stunden | Backup mit geplanter Wiederherstellung |
| 99,9 % | 8,76 Stunden | Backup plus Replikation |
| 99,99 % | 52,6 Minuten | HA-Cluster |
| 99,999 % | 5,3 Minuten | Fehlertoleranz (Herstellerangabe everRun Enterprise, ftServer) |
| 99,99999 % | 3,2 Sekunden | Fehlertoleranz (Herstellerangabe ztC Endurance) |
Die Ausfallzeit pro Jahr ist kein RTO. 8,76 Stunden können ein einziger Ausfall sein oder viele kurze. RTO begrenzt den einzelnen Ausfall, die Verfügbarkeit die Summe.
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.
Was kostet eine Stunde Ausfall konkret?
Ein RTO von vier Stunden klingt abstrakt, solange keine Zahl daneben steht. Die folgende Rechnung zeigt den Weg an einem durchgerechneten Fall. Die Annahmen sind frei gewählt und ausdrücklich keine Branchenwerte.
- Mitarbeitende im betroffenen Bereich120
- Durchschnittliche Personalkosten je Stunde45 Euro
- Anteil, der ohne das System nicht arbeiten kann70 Prozent
- Ausfalldauer4 Stunden
- Betroffene Personenstunden: 120 × 70 % × 4 h = 336 Stunden
- Produktivitätsverlust: 336 h × 45 Euro = 15.120 Euro
Nicht enthalten sind Umsatzausfall, Nacharbeit, Vertragsstrafen und Reputationsschaden. Diese Posten lassen sich nur mit betriebseigenen Zahlen beziffern. Wer die Rechnung mit den eigenen Werten führen möchte, findet sie im Downtime-Rechner.
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.
Welche RTO- und RPO-Werte sind für ein ERP-System üblich?
Als Richtwert zur Planung: RTO 30 bis 60 Minuten, RPO 0 bis 15 Minuten. Ein ERP steuert Aufträge, Lager und Abrechnung, ein Datenverlust von mehr als einer Viertelstunde lässt sich dort selten nachbuchen. Der konkrete Wert folgt aus den Ausfallkosten des Betriebs und muss im Wiederherstellungstest bestätigt werden.
Wie viel Ausfallzeit pro Jahr bedeutet 99,99 Prozent Verfügbarkeit?
52,6 Minuten. Rechnung: 8.760 Stunden im Jahr mal 0,01 Prozent ergibt 0,876 Stunden. 99,9 Prozent lassen 8,76 Stunden zu, 99,999 Prozent 5,3 Minuten. Die Jahresausfallzeit ist kein RTO, sie begrenzt die Summe aller Ausfälle, nicht den einzelnen.
Welches RTO erreicht ein HA-Cluster, welches Fehlertoleranz?
Ein HA-Cluster startet die virtuelle Maschine nach einem Host-Ausfall auf einem anderen Host neu, das RTO liegt damit im Minutenbereich, Daten im Arbeitsspeicher gehen verloren. Fehlertoleranz führt die Anwendung auf zwei Systemen parallel, beim Ausfall einer Komponente läuft der Betrieb ohne Neustart weiter. Die Hersteller nennen dafür 99,999 Prozent Verfügbarkeit als Plattformangabe.
Quellen und Einordnung
- Definitionen (RTO: geforderte Wiederanlaufzeit; RPO: maximal zulässiger Datenverlust): BSI-Standard 200-4, Glossar (PDF).
- Verhalten eines HA-Clusters bei Host-Ausfall: VMware vSphere Availability, Determining Responses to Host Issues.
- Herstellerangaben everRun (Express 99,95 bis 99,99 Prozent, Enterprise 99,999 Prozent): Penguin Solutions, Stratus everRun.
- Herstellerangaben ftServer (99,999 Prozent) und ztC Endurance (bis 99,99999 Prozent): Penguin Solutions, Stratus ftServer und Fault Tolerant Computing Platforms.
- Ausfallzeit pro Jahr: eigene Rechnung aus 8.760 Stunden und dem fehlenden Anteil. Abgerufen am 08.09.2026. Herstellerwerte gelten als Plattformangaben, nicht als Service Level Agreement.
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