RTO und RPO
Wenn du in einem Vorstellungsgespräch zu Backup-Themen befragt wirst oder in der IHK-Prüfung sitzt, kommen früher oder später zwei Abkürzungen: RTO und RPO. Sie sind die wichtigsten Kennzahlen jeder Backup- und Disaster-Recovery-Strategie und beantworten zwei Schlüsselfragen: Wie schnell sind wir wieder online? und Wie viele Daten dürfen wir maximal verlieren?
In dieser Lektion lernst du beide Begriffe sauber zu unterscheiden, ihre Auswirkungen auf die Backup-Strategie zu verstehen und konkrete Beispiele für verschiedene Service-Tiers zu kennen. Anschließend siehst du, wie RTO/RPO mit den verwandten Kennzahlen MTBF und MTTR zusammenhängen.
1) Das Szenario: ein Disaster passiert
Stell dir vor: Donnerstag, 14:32 Uhr. Dein Datenbankserver crasht durch einen Hardware-Defekt. Daten sind weg, das System ist down. Jetzt zählen zwei Dinge:
Erstens: wie lange dauert es, bis das System wieder läuft? Eine Minute? Eine Stunde? Drei Tage? Diese Zeitspanne ist deine Recovery-Zeit. Je länger der Ausfall, desto höher die Kosten.
Zweitens: wie aktuell sind die wiederhergestellten Daten? Vom letzten Backup um Mitternacht? Von vor einer Stunde? Live? Die Lücke zwischen dem letzten gesicherten Datenstand und dem Crash-Zeitpunkt sind verlorene Daten – Bestellungen, Kundeninteraktionen, Datenbankänderungen.
Für genau diese zwei Fragen gibt es die Kennzahlen RTO und RPO. Wer eine Backup-Strategie plant, definiert zuerst diese beiden Werte – alles andere folgt daraus.
2) Die zentrale Timeline-Visualisierung
Am besten verstehst du beide Begriffe an einer Zeitleiste. In der Mitte ist der Moment des Disasters. Davor liegt der letzte Backup-Zeitpunkt, dahinter der Moment der Wiederherstellung:
Max. erlaubter Datenverlust
Max. erlaubte Ausfallzeit
3) RTO – Recovery Time Objective
Die Recovery Time Objective ist die maximal akzeptable Zeitspanne vom Eintritt eines Ausfalls bis zur Wiederherstellung des Betriebs. Sie beantwortet die Frage: „Wie lange dürfen wir maximal offline sein?"
Typische RTO-Werte aus der Praxis:
- RTO = 0 oder fast 0: Notaufnahme-Systeme, Flugverkehrskontrolle, Hochfrequenzhandel. Erfordert echte Hochverfügbarkeit, keine reinen Backups
- RTO = wenige Minuten: E-Commerce-Plattformen, Online-Banking, Telefonie
- RTO = wenige Stunden: ERP-Systeme, interne Geschäftsanwendungen, CRM
- RTO = ein Tag: Reporting-Systeme, Test-Umgebungen, Archive
- RTO = mehrere Tage: selten genutzte Spezial-Systeme, historische Daten
Wichtig: ein niedriger RTO ist teurer. Wer RTO = 0 will, braucht Hot-Standby-Systeme, geo-redundante Cluster, automatisches Failover. Das kostet sehr viel mehr als Backups mit RTO = 4 Stunden. Deshalb wird RTO pro System festgelegt – nicht pauschal für die ganze Firma.
4) RPO – Recovery Point Objective
Die Recovery Point Objective ist die maximal akzeptable Datenmenge (gemessen in Zeit), die im Falle eines Ausfalls verloren gehen darf. Sie beantwortet die Frage: „Welche Daten dürfen wir maximal verlieren?"
Typische RPO-Werte und ihre Implikationen:
- RPO = 0: kein Datenverlust akzeptabel. Erfordert synchrone Replikation (jede Transaktion wird sofort auf 2 Systeme geschrieben)
- RPO = wenige Sekunden bis Minuten: erfordert kontinuierliche Replikation (z.B. asynchrone DB-Replikation, Log-Shipping)
- RPO = 1 Stunde: stündliche Snapshots oder inkrementelle Backups
- RPO = 24 Stunden: tägliches Backup reicht – aber im Worst Case sind 23h59 Daten weg
- RPO = 1 Woche: wöchentliches Backup, akzeptabel für reine Archive
Auch hier: niedriger RPO = teurer. RPO = 0 erfordert teure Cluster-Technologie. RPO = 24h kann mit einem einfachen nächtlichen Backup-Job realisiert werden. Wieder gilt: RPO wird vom Business festgelegt, basierend auf der Frage „Was kostet uns der Verlust dieser Daten?"
5) RTO vs. RPO im Direktvergleich
Beide Werte werden oft verwechselt. Hier nebeneinander:
6) Verschiedene Service-Tiers
Nicht jedes System braucht den gleichen Schutz. In der Praxis werden Systeme in Tiers eingeteilt – nach Kritikalität fürs Geschäft. Jeder Tier bekommt eigene RTO/RPO-Vorgaben:
7) Konkrete Beispiele aus dem Alltag
Damit das nicht abstrakt bleibt – hier Szenarien aus dem echten Leben mit konkreten RTO/RPO-Werten:
8) Wie hängen RTO/RPO mit der Backup-Strategie zusammen?
Aus den Werten folgen unmittelbar konkrete technische Entscheidungen. Hier die Verbindungen:
Aus dem RPO ergibt sich die Backup-Frequenz: bei RPO = 1 Stunde brauchst du mindestens stündliche Backups. Bei RPO = 5 Minuten brauchst du Continuous Replication (Log-Shipping, Storage-Replikation, DB-Slaves). Bei RPO = 24h reicht ein nächtlicher Job. Die Backup-Art spielt ebenfalls eine Rolle – inkrementell kann häufiger laufen als Vollsicherung.
Aus dem RTO ergeben sich das Backup-Medium und die Restore-Technologie: bei RTO = 4 Stunden und 5 TB Daten brauchst du mindestens 350 MB/s Restore-Geschwindigkeit – also keine Cloud über schmale Leitung. Bei RTO = 15 Minuten brauchst du Hot-Standby-Systeme, die fertig sind und nur aktiviert werden. Bei RTO = 1 Tag reicht ein klassisches Tape-Restore.
9) Wie wird der RTO/RPO ermittelt?
Die Werte werden nicht beliebig gewählt, sondern systematisch ermittelt – das ist Aufgabe der Business Impact Analyse. Typischer Ablauf:
- Geschäftsprozesse identifizieren: welche kritischen Prozesse hat das Unternehmen?
- Abhängigkeiten ermitteln: welche IT-Systeme unterstützen welchen Prozess?
- Ausfallkosten kalkulieren: was kostet Ausfall pro Stunde? (Umsatz, Vertragsstrafen, Reputation, Personal-Idle-Zeit)
- Maximal tolerierbare Ausfallzeit (MTPD): ab wann wird's wirklich kritisch?
- RTO ableiten: RTO < MTPD, mit Sicherheitspuffer
- Datenverlust-Toleranz: welche Daten dürfen verloren gehen? (rekonstruierbar oder nicht)
- RPO ableiten: aus Datenverlust-Toleranz
- Mit Stakeholdern abstimmen: Business und IT müssen sich einig sein
- Dokumentieren: schriftlich festhalten, regelmäßig reviewen
Wichtig: RTO/RPO sind Vorgaben, keine Wünsche. Wer „RTO = 15 Minuten" verlangt, muss auch das Budget für die nötige Infrastruktur bereitstellen.
10) Die Kostenkurve: niedriger RTO/RPO = exponentiell teurer
Eine wichtige Beobachtung aus der Praxis: die Kosten für niedrigere RTO/RPO steigen nicht linear, sondern exponentiell. Ein Sprung von „1 Tag" auf „4 Stunden" ist günstig. Von „4 Stunden" auf „15 Minuten" wird's teurer. Von „15 Minuten" auf „1 Minute" extrem teuer. Von „1 Minute" auf „0" oft astronomisch.
11) Verwandte Kennzahlen: MTBF und MTTR
RTO/RPO sind Ziele. Es gibt auch Kennzahlen, die Realität messen. Die wichtigsten:
12) Verfügbarkeit und Ausfallzeit
Wenn von „99,9% Verfügbarkeit" die Rede ist, klingt das viel. Lass uns rechnen, wie viel Ausfallzeit das pro Jahr bedeutet:
| SLA | Ausfall pro Jahr | Ausfall pro Monat | Ausfall pro Woche |
|---|---|---|---|
| 99% (zwei Neunen) | 3 Tage 15 Std | 7 Std 18 Min | 1 Std 41 Min |
| 99,9% (drei Neunen) | 8 Std 45 Min | 43 Min 49 Sek | 10 Min 5 Sek |
| 99,99% (vier Neunen) | 52 Min 35 Sek | 4 Min 22 Sek | 1 Min |
| 99,999% (fünf Neunen) | 5 Min 15 Sek | 26 Sek | 6 Sek |
Die berühmten „fünf Neunen" entsprechen also nur 5 Minuten Ausfall pro Jahr. Das ist nicht mit klassischen Backups erreichbar – das ist Hochverfügbarkeit mit redundanten, automatisch failoverenden Systemen. Praktische Grenze für Backup-basierte Wiederherstellung: meist 99,9% (drei Neunen). Mehr Verfügbarkeit braucht andere Architektur.
13) Beispielrechnung: kostenoptimale Strategie
Eine kleine Übung. Du sollst die Backup-Strategie für ein E-Commerce-System empfehlen:
- Vorgaben: RTO = 1 Stunde, RPO = 15 Minuten
- Datenmenge: 500 GB Datenbank, 2 TB Files
- Tägliche Daten-Änderung: ~10 GB
Analyse: RPO = 15 min schließt klassische tägliche Backups aus. Du brauchst Continuous Backup oder Snapshot-Replikation. Optionen:
- Datenbank: DB-Replikation mit Streaming Replication (PostgreSQL) oder Galera Cluster (MySQL) → RPO ~ 0
- Files: 15-Minuten-Snapshots auf NAS, geo-redundant
- Restore-Strategie: warm standby – zweites System ist bereit, muss nur aktiviert werden
- Zusätzlich klassisches tägliches Backup für Langzeit-Recovery und Compliance
RTO = 1h ist mit Warm Standby gut machbar (Aktivierung dauert typisch 10-30 min). Das Setup ist nicht billig, aber dafür kriegt man Tier-1-Schutz.
Zusammenfassung
RPO (Recovery Point Objective) = maximal akzeptabler Datenverlust, blickt vom Disaster zurück. Bestimmt Backup-Frequenz: RPO 24h → tägliches Backup, RPO 15 min → Snapshots, RPO 0 → synchrone Replikation. RTO (Recovery Time Objective) = maximal akzeptable Ausfallzeit, blickt vom Disaster nach vorne. Bestimmt Recovery-Technologie: RTO 24h → klassisches Restore, RTO Stunden → Backup-Appliance, RTO Minuten → Warm/Hot Standby. Tier-Modell mit Tier 0 bis Tier 4 staffelt Systeme nach Kritikalität mit eigenen RTO/RPO-Werten. Wert-Ermittlung über Business Impact Analyse. Kosten steigen exponentiell mit sinkendem RTO/RPO. Verwandte Kennzahlen: MTBF (Zeit zwischen Ausfällen), MTTR (gelebte Recovery-Zeit), MTPD (Schmerzgrenze des Business), SLA (Vertrag). „Fünf Neunen" = 5 Min Ausfall/Jahr, nicht mit Backups allein erreichbar – braucht HA-Architektur (siehe K59). RTO/RPO sind die Brücke zwischen Geschäftsanforderung und IT-Umsetzung.