Artikel vom 1. Juni 2026
RTO und RPO richtig definieren: Praxisanleitung
Die Definitionen #
Recovery Time Objective (RTO) #
RTO ist der maximale akzeptable Ausfallzeitraum eines Systems/Prozesses.
Beispiele:
- “Unser ERP hat RTO 4 Stunden” = Wenn das ERP down geht, müssen wir es in maximal 4 Stunden wieder hochfahren.
- “Unsere Fileserver haben RTO 8 Stunden” = Nach 8 Stunden sind die Auswirkungen zu groß; wir müssen sie online haben.
- “Unser CRM hat RTO 2 Stunden” = Sales-Team kann maximal 2 Stunden ohne CRM arbeiten.
RTO ist eine geschäftliche Entscheidung, nicht technisch.
Recovery Point Objective (RPO) #
RPO ist der maximal akzeptable Datenverlust eines Systems.
Beispiele:
- “Unser ERP hat RPO 1 Stunde” = Wir können bis zu 1 Stunde an Transaktionen verlieren.
- “Unsere Datenbank hat RPO 15 Minuten” = Wir testen stündliche Backups, akzeptieren bis zu 15 Minuten Datenverlust.
- “Unsere E‑Mail hat RPO 24 Stunden” = E‑Mail-Verlust von bis zu 24 Stunden ist akzeptabel (nicht ideal, aber geschäftsverträglich).
RPO ist auch eine geschäftliche Entscheidung — wieviel Datenverlust können Sie wirtschaftlich tolerieren?
Beziehung zu anderen Begriffen #
Es gibt zwei weitere Begriffe, die oft verwechselt werden:
Mean Time To Recover (MTTR): Die durchschnittliche Zeit, die es tatsächlich dauert, ein System zu recovered.
Recovery Time Objective (RTO): Die maximale Zeit, die wir uns leisten können.
Die Differenz ist der Puffer. Wenn RTO = 4 Stunden und MTTR = 3 Stunden (aus Tests), haben Sie 1 Stunde Puffer. Das ist knapp.
Maximum Tolerable Downtime (MTD): Der größten Schaden, den das Unternehmen tolerieren kann (in Geldwert).
RTO ist die Zeit-Dimension von MTD.
BIA-Workshop Methodik: Wie man RTO/RPO ableitet #
Das ist die richtige Reihenfolge:
Schritt 1: Kritische Prozesse identifizieren #
Laden Sie ein: CFO, COO, Abteilungsleiter, IT-Leiter.
Gehen Sie durch jede Geschäftsabteilung:
- Sales: “Ohne CRM können wir wie lange arbeiten?”
- Operations: “Ohne Produktions-Steuerung können wir wie lange arbeiten?”
- Finance: “Ohne Buchhaltungs-System können wir wie lange arbeiten?”
Schritt 2: Impact qualifizieren #
Für jeden Prozess: “Was passiert, wenn dieser Prozess für X Stunden down ist?”
Sales-Beispiel:
- 1 Stunde down: “Wenig Auswirkung; Offline-Verkauf im CRM nachholen.”
- 4 Stunden down: “Bedeutsamer Einfluss; wir verlieren mehrere wichtige Deals.”
- 8 Stunden down: “Kritischer Impact; Kunden kontaktieren Konkurrenz.”
Produktion-Beispiel:
- 30 Minuten down: “Kein Problem; Fertigungs-Puffer absorbiert.”
- 2 Stunden down: “Wir geraten in Verzug bei einzelnen Aufträgen.”
- 4 Stunden down: “Lieferverzögerungen, Kunden unzufrieden, Strafkosten.”
Schritt 3: RTO-Schwellwert festlegen #
Die RPT-Schwelle ist der Punkt, nach dem Geschäftsimpakt zu groß wird.
Beispiel:
- Sales CRM: “Nach 4 Stunden verlieren wir signifikante Deals. Deshalb RTO = 4 Stunden.”
- Produktion: “Nach 2 Stunden geraten wir in Liefer-Schwierigkeiten. Deshalb RTO = 2 Stunden.”
Das ist nicht theoretisch — das ist Geschäfts-Tatsache.
Schritt 4: RPO-Threshold festlegen #
Für jeden Prozess: “Wie aktuell müssen die Daten sein?”
Sales CRM-Beispiel:
- “Salespeople machen täglich neue Deals. Datenverlust von mehr als einer Stunde ist problematisch. Deshalb RPO = 1 Stunde.”
Produktions-Datenbank-Beispiel:
- “Wir erfassen Produktionslose real-time. Datenverlust von mehr als 15 Minuten bedeutet, dass wir nicht wissen, was gerade produziert wurde. Deshalb RPO = 15 Minuten.”
E‑Mail-Beispiel:
- “E‑Mail ist wichtig, aber nicht kritisch. Datenverlust von bis zu 24 Stunden ist wirtschaftlich tolerierbar. Deshalb RPO = 24 Stunden.”
Schritt 5: Abhängigkeiten dokumentieren #
Welche anderen Systeme braucht dieses System um zu funktionieren?
“ERP braucht Active Directory.” “Fileserver braucht Netzwerk-Zugang.” “Database braucht Backup-Storage.”
Das bestimmt die Recovery-Reihenfolge: AD muss vor ERP wiederhergestellt werden.
Typische RTO/RPO Werte nach Systemkategorie #
Dies sind Richtlinien, nicht Regel:
| System | Kategorie | Typischer RTO | Typisches RPO |
|---|---|---|---|
| **Active Directory** | kritisch | 1 – 2 Std | 15 Min |
| **ERP** | kritisch | 4 Std | 1 Std |
| **E‑Commerce Website** | kritisch | 1 Std | 15 Min |
| **E‑Mail** | wichtig | 8 – 24 Std | 1 – 24 Std |
| **CRM** | wichtig | 4 Std | 1 Std |
| **Fileserver** | wichtig | 8 Std | 1 Std |
| **Database** | kritisch | 2 – 4 Std | 15 Min — 1 Std |
| **Development-Tools** | niedrig | 48 Std | 1 Tag |
Die Begründung: Kritische Systeme, auf die Kunden oder Produktion abhängig sind, haben aggressive RTO/RPO. Interne oder non-Customer-facing Systeme können entspannter sein.
RTO-Messung: Geschätzt vs. Getestet #
Ein häufiger Fehler: “Unser RTO ist 4 Stunden” — aber das ist eine Schätzung, nie getestet.
Geschätzte RTO: “Unser Backup-System kann 2 Stunden Restore-Zeit pro 100GB. Unser ERP ist 500GB. Also RTO ≈ 10 Stunden.”
Getestete RTO: “Wir haben einen echten Recovery-Test durchgeführt. Backup wurde in 2 Stunden wiederhergestellt. Das ist unsere tatsächliche RTO.”
Die Differenz kann enorm sein. Backups, die nicht getestet wurden, sind oft nicht wiederherstellbar. RPT von 4 Stunden ist nur valide, wenn sie getestet wurden.
Häufige Fehler #
Fehler 1: Unrealistische RTO “Unser ERP-RTO ist 30 Minuten” — aber ihr Recovery-Prozess dauert 2 Stunden. Das ist kein RTO, das ist Traum.
Die Lösung: RTO muss mit tatsächlichen Recovery-Zeiten aligned sein, oder Sie müssen mehr in Infrastruktur investieren (bessere Backups, Failover, etc.).
Fehler 2: Abhängigkeiten vergessen “Unser ERP-RTO ist 4 Stunden — aber wir haben nicht geprägt, dass AD auch recovered werden muss, was weitere 2 Stunden dauert.”
Recovery-Reihenfolge ist wichtig.
Fehler 3: RPO größer als RTO “RTO 4 Stunden, RPO 1 Woche” — das ergibt keinen Sinn. Wenn Sie den Server nach 4 Stunden wiederherstellen, aber nur Wochenalter Daten haben, haben Sie zu viel Datenverlust.
Typischerweise: RPO ≤ RTO.
Dokumentation #
RTO/RPO sollte dokumentiert und genehmigt sein:
System: ERP (SAP)
RTO: 4 Stunden
RPO: 1 Stunde
Begründung: Produktion und Sales hängen davon ab. Nach 4 Stunden Ausfall entstehen Lieferverzögerungen. Nach 1 Stunde Datenverlust ist Tagesabschluss beeinträchtigt.
Getestet: Ja (Letzter Test: 15.02.2026 — tatsächliche Recovery-Zeit: 2.5 Stunden)
Approver: CIO, CFO
Gültig bis: 15.02.2027 (Jährliche Überprüfung)
Dieses Dokument ist dein Beweis gegenüber Auditoren, dass du RTO/RPO rational definiert hast.
Häufige Fragen #
Wer bestimmt RTO/RPO? Die Geschäftsseite (CFO, Abteilungsleiter) bestimmt, was sie brauchen. IT sagt, ob das technisch machbar ist und zu welchem Kosten.
Können RTO/RPO sich ändern? Ja. Jährlich sollten sie reviewed werden. Nach signifikanten Geschäftsveränderungen sofort.
Was ist, wenn RTO technisch nicht machbar ist? Dann müssen Sie investieren (bessere Infrastruktur) oder Sie müssen den RTO-Erwartung reduzieren.