2026-04-22 · 7 Min. Lesezeit

RTO und RPO für den DACH-Mittelstand — ohne Enterprise-Theater

Wie man Recovery-Time- und Recovery-Point-Zahlen ermittelt, die einem echten Ausfall standhalten.

Wer schon einmal in einem BSI-Grundschutz-Workshop gesessen hat, kennt den Satz: „Unser RTO beträgt vier Stunden" — vorgetragen mit vollster Überzeugung. Fragt man nach der Grundlage, lautet die ehrliche Antwort: Jemand hat das vor fünf Jahren in einen Beschaffungs-Fragebogen eingetragen, und seitdem hat es niemand mehr getestet.

Zunächst die Standarddefinitionen — dann die Reduktion auf Zahlen, die im eigenen Umfeld überprüfbar sind.

Die zwei Kennzahlen

Begriff	Frage, die er beantwortet	Einheit
RTO	Wie lange dauert es von „es ist kaputt" bis „es läuft wieder"?	Minuten oder Stunden
RPO	Wie viele Daten haben wir verloren, wenn wir wiederherstellen?	Minuten an Daten

RTO betrifft Ausfallzeit. RPO betrifft Datenaktualität. Es sind zwei verschiedene Stellschrauben, die gegeneinander abgewogen werden. Ein RPO von 1 Minute kostet deutlich mehr als ein RPO von 4 Stunden, weil er üblicherweise synchrone Replikation erfordert.

Warum Enterprise-Vorlagen nicht passen

„Vier Stunden / fünfzehn Minuten" ist die kanonische Großbank-Zahl. Sie stammt aus Umgebungen mit:

• Hot-Standby-Repliken in einem zweiten Rechenzentrum, Failover vierteljährlich getestet.
• Schriftlichen Runbooks, Tabletop-Übungen, bezahlten On-Call-Rotationen.
• Einem dedizierten DR-Ingenieur, dessen Vollzeitjob darin besteht, diese Zahlen zu erfüllen.

Ein DACH-SaaS mit 20 Mitarbeitern und 400 GB PostgreSQL hat nichts davon, kann es wirtschaftlich in der Regel auch nicht rechtfertigen, und sollte nicht die Zahlen beanspruchen, die dazu gehören. Man hat kein 4-Stunden-RTO. Man hat die Zahl, die herauskommt, wenn jemand tatsächlich unter Druck versucht wiederherzustellen.

Wie man sein echtes RTO an einem Nachmittag misst

1. Ein aktuelles Backup auswählen. Irgendein Backup. Das, das man greifen würde, wenn Prod gerade gestorben ist.
2. Eine Wegwerf-Postgres auf einem Spare-Server oder via docker run postgres:16 aufsetzen.
3. Stoppuhr starten.
4. Das Backup in die Wegwerf-Instanz wiederherstellen. pg_restore wirklich ausführen. Nicht pg_restore -l.
5. Den Smoke-Test der Anwendung dagegen laufen lassen. Einloggen. Eine Seite laden. Einen bekannten Datensatz prüfen.
6. Stoppuhr stoppen.

Diese Zahl ist das RTO. Drei Vorbehalte daneben notieren:

• Man wusste, wo das Backup liegt. Im echten Ausfall um 3 Uhr morgens: ist das dokumentiert?
• Man hatte Zeit und war ruhig. Beim echten Ausfall gibt es beides nicht.
• Man musste Anwendungscode, DNS oder Secrets nicht wiederherstellen. Die kosten oft jeweils eine weitere Stunde.

Ein erstes Drill für einen Mittelstands-Stack landet typischerweise zwischen 45 Minuten und 4 Stunden, allein für die Datenbank. Wer bei 30 Minuten lag und tatsächlich 2 Stunden braucht — das ist der Befund des Audits.

Wie man den RPO misst

RPO ist vom Prinzip her einfacher:

RPO ≈ (Backup-Frequenz) + (Zeit zum Hochladen eines Backups an einen externen Ort)

Tägliches Backup, fertig um 03:00 Uhr, 20 Minuten Upload → Worst-Case-RPO beträgt 24h + 20 Minuten. Stündliche Backups → Worst-Case-RPO beträgt 60 Minuten + Upload-Zeit.

Der „+ Upload"-Anteil zählt mehr als man denkt. Wenn das Backup nur auf dem Produktions-Host existiert und der Produktions-Host das Teil ist, das gestorben ist, ist der RPO praktisch unendlich.

Es gibt einen zweiten RPO, den man separat verfolgen sollte: Replikationsverzögerung, falls eine Replica vorhanden ist. Den Primary verlieren, aber die Replica noch haben, bedeutet: der RPO entspricht der Verzögerung zum Zeitpunkt des Ausfalls — oft Sekunden, manchmal deutlich mehr unter hoher Schreiblast. Wenn eine Replica vorhanden ist, Verzögerung in Prometheus messen und das 99. Perzentil ins Runbook schreiben.

Was wirklich ins Board-Slide gehört

Drei Zahlen, alle gemessen:

1. Getestetes RTO — „Letzter Drill hat X in einem sauberen Ziel in Y Minuten wiederhergestellt, Datum Z."
2. RPO — „Wir würden maximal N Minuten Daten verlieren, begrenzt durch Backup-Frequenz und Upload-Zeit."
3. Wann zuletzt getestet — Das Datum des letzten echten Restores.

Das Board interessiert sich nicht für Technologie. Es interessiert sich dafür, dass die dritte Zahl veraltet. „Letzter getesteter Restore: vor 47 Tagen" ist eine stärkere Aussage als jeder ISO-27001-Paragraph, weil sie falsifizierbar ist.

Ein Muster, das immer wieder auftaucht: Die Präsentation sagt 4h / 15min, der letzte erfolgreiche Test-Restore liegt 18+ Monate zurück. Wenn der Drill endlich läuft, landet das tatsächliche RTO bei 4–6× des genannten Werts — und das mit dem Backup bereits auf einem Spare-Host eingehängt. Die Lücke zwischen Behauptung und Realität ist das eigentliche Geschäftsproblem.

Empfehlung für Mittelstands-Stacks

Stack-Größe	RTO-Ziel	RPO-Ziel	Was es braucht
< 50 GB, 1 DB-Host	2h	24h + Upload	Täglich verschlüsseltes Backup extern, monatlicher Test-Restore. Solo machbar.
50–500 GB, 1 Primary + Replica	1h	1h + Upload	Stündliche Backups, überwachte Replica, vierteljährlicher Drill. In der Regel mit begrenztem Engineering-Aufwand machbar.
> 500 GB oder reguliert	30 Min	15 Min	PITR, getestetes Failover, dediziertes Runbook. Erfordert typischerweise nachhaltiges Setup und regelmäßige Übung.

Was in dieser Tabelle fehlt: „Enterprise-HA über drei Availability Zones" steht hier nicht. Die meisten DACH-Mittelständler brauchen das nicht, können es sich nicht leisten, und es reduziert das Geschäftsrisiko im Vergleich zu einem gut geübten pg_restore-Drill auch nicht wirklich.

Der Test zählt mehr als das Ziel

Eine Zahl wählen, die man durch Drill verteidigen kann. Das Datum des letzten Drills auf einem Dashboard festhalten. Wenn dieses Datum veraltet, als technische Schuld behandeln und den nächsten Drill einplanen, bevor stärkere Resilienz-Behauptungen aufgestellt werden. Diese eine Regel schlägt jede Menge RTO/RPO-Dokumentation, die niemand verifiziert hat.

---

Wenn Sie Ihr RTO gemessen statt geschätzt haben möchten: ein halbtägiger Disaster-Recovery-Drill stellt ein echtes Backup mit laufender Stoppuhr in einer sauberen Zielumgebung wieder her. Sie verlassen das Meeting mit Zahlen, die Sie beim nächsten Board-Termin verteidigen können, und einem Replay-Skript für das nächste Mal.