Recovery Time und Recovery Point – Was RTO und RPO für Software-Projekte bedeuten

Wer Anwendungen entwickelt, beschäftigt sich täglich mit Features, Performance und sauberem Code. Im produktiven Betrieb entscheidet jedoch oft etwas anderes über den Erfolg eines Systems: Wie gut kommt es nach einem Ausfall wieder zurück?

Zwei Kennzahlen helfen dabei, diese Frage realistisch zu beantworten:

RTO und RPO. Sie beschreiben, wie lange ein System ausfallen darf und wie viel Datenverlust akzeptabel ist. Und sie gehören nicht nur in Strategiedokumente, sondern direkt in die technische Planung – damit auch in den Verantwortungsbereich der Entwicklung.

Typische Ausfälle, bei denen RTO und RPO plötzlich relevant werden

In der Praxis sind es selten theoretische Szenarien, sondern sehr konkrete Situationen:

• Ein fehlerhaftes Deployment legt eine API oder einen zentralen Service lahm.
• Eine Datenbank ist nach einer Migration inkonsistent.
• Ein Object-Storage-Bucket wird versehentlich überschrieben oder gelöscht.
• Ransomware verschlüsselt produktive Daten und versucht, Backups zu sabotieren.
• Eine Cloud-Region oder ein Rechenzentrum ist temporär nicht erreichbar.

In all diesen Fällen reicht es nicht zu wissen, dass ein Backup existiert. Entscheidend ist, wie schnell ein System wieder läuft und auf welchen Datenstand man zurückkehren kann.

Was bedeuten RTO und RPO genau?

RTO (Recovery Time Objective) beschreibt die maximale Zeitspanne zwischen einem Ausfall und dem Zeitpunkt, zu dem das System wieder nutzbar sein muss.
Ein RTO von einer Stunde bedeutet: Spätestens nach 60 Minuten müssen alle relevanten Komponenten wieder laufen – nicht nur einzelne Services.

RPO (Recovery Point Objective) gibt an, wie alt die Daten im schlimmsten Fall sein dürfen, auf die zurückgegriffen wird.
Ein RPO von 15 Minuten bedeutet, dass maximal 15 Minuten an Daten verloren gehen dürfen. Je kleiner dieser Wert ist, desto häufiger müssen Daten gesichert oder repliziert werden.

Backup, Replikation und Verfügbarkeit – eine wichtige Abgrenzung

Gerade in Cloud-Umgebungen werden diese Begriffe oft vermischt:

• Replikation und Hochverfügbarkeit verbessern die Verfügbarkeit und können das RTO verkürzen.
• Backups ermöglichen die Wiederherstellung auf einen definierten Zeitpunkt zurück.
• Replikation ersetzt kein Backup: Fehlerhafte oder manipulierte Daten werden sonst lediglich vervielfältigt.

Für die technische Umsetzung ist diese Unterscheidung zentral, weil sie bestimmt, welche Massnahmen notwendig sind, um ein definiertes RTO oder RPO zu erreichen.

Warum RTO und RPO für Entwickler:innen relevant sind

RTO und RPO beeinflussen Architekturentscheidungen direkt. Sie bestimmen nicht nur die Backup-Strategie, sondern auch:

• ob Deployments reproduzierbar sind,
• ob Konfigurationen versioniert und gesichert werden,
• ob Datenkonsistenz im Fehlerfall gewährleistet ist,
• ob ein System automatisiert wieder gestartet werden kann.

Ein niedriges RTO erfordert standardisierte Abläufe, Infrastructure as Code und klar dokumentierte Wiederherstellungsprozesse.
Ein niedriges RPO erfordert Mechanismen wie Point-in-Time-Recovery, Write-Ahead-Logging oder häufige Snapshots – abhängig von Datenbank und Workload.

RTO und RPO definieren – wer entscheidet was?

RTO und RPO werden nicht willkürlich festgelegt. Sie entstehen aus einer Kombination von fachlichen Anforderungen und technischer Machbarkeit.

In der Praxis gilt:

• Fachseite oder Produktverantwortliche definieren, wie lange ein Ausfall akzeptabel ist.
• Entwicklung und Betrieb setzen diese Vorgaben technisch um oder zeigen Grenzen auf.

Beispielhafte Richtwerte aus der Praxis:

• Interne Tools: RTO mehrere Stunden, RPO 1–24 Stunden
• Geschäftskritische Web-Anwendungen: RTO 30–60 Minuten, RPO 5–15 Minuten
• Finanz- oder Bestellsysteme: RTO unter 15 Minuten, RPO nahe null

Für die Entwicklung ist wichtig zu verstehen: Je kleiner RTO und RPO, desto höher der technische Aufwand.

Praxisbeispiel aus der Softwareentwicklung

Eine Web-Anwendung nutzt PostgreSQL und speichert Dateien in einem Object Storage.

• RPO 15 Minuten
  → Point-in-Time-Recovery über Write-Ahead-Logs oder häufige Snapshots
• RTO 60 Minuten
  → Automatisierte Infrastruktur, standardisierte Deployments, dokumentierter Restore-Ablauf

Entscheidend ist nicht nur die Konfiguration, sondern der Test: Ein Restore muss regelmässig durchgeführt werden, inklusive Zeitmessung. Nur so lässt sich überprüfen, ob die Zielwerte erreichbar sind.

Was Entwickler:innen konkret tun können

Datenverluste vermeiden
In asynchronen Systemen muss klar definiert sein, wann Daten als gespeichert gelten. Commit-Punkte, Acknowledgements und Retry-Mechanismen sind entscheidend.

APIs fehlertolerant gestalten
Idempotente Endpunkte und eindeutige Request-IDs verhindern doppelte Einträge und Datenverlust bei Wiederholungen.

Datenbankänderungen absichern
Vor Migrationen gehört ein aktuelles Backup ebenso dazu wie ein getesteter Rollback-Plan.

Restore-Tests fest einplanen
Ein Backup ist nur dann wertvoll, wenn es sich wiederherstellen lässt. Restore-Tests zeigen, ob das definierte RTO realistisch ist.

Backup-Strategien als Grundlage für RTO und RPO

RTO und RPO lassen sich nur erreichen, wenn Backups konsistent, geschützt und überprüfbar sind. Gerade als Schutz gegen Ransomware oder Fehlbedienung spielen unveränderbare Backups eine zentrale Rolle. Wie sich diese theoretischen Anforderungen in der Praxis umsetzen lassen, zeigt unter anderem das Angebot von Backup ONE.

Ein weiteres praxisnahes Beispiel ist Disaster Recovery as a Service von Backup ONE. Hier wird das Zusammenspiel von RTO und RPO besonders deutlich: Während definierte Wiederanlaufzeiten sicherstellen, dass Systeme innerhalb eines festgelegten Zeitfensters wieder verfügbar sind, bestimmt der gewählte Wiederherstellungspunkt, auf welchen Datenstand zurückgegriffen wird. Gerade in produktiven Umgebungen zeigt sich so, wie eng beide Kennzahlen miteinander verzahnt sind.

Für die Entwicklung bedeutet das:

RPO-Vorgaben lassen sich nicht nur definieren, sondern auch zuverlässig einhalten, ohne zusätzliche Komplexität in der Anwendung selbst.

Weitere Informationen zum Swiss S3 Storage von Backup ONE.

Mini-Glossar

RTO (Recovery Time Objective)
Maximale Zeit, bis ein System nach einem Ausfall wieder verfügbar sein muss.

RPO (Recovery Point Objective)
Maximal erlaubter Datenverlust, gemessen in Zeit.

PITR (Point-in-Time-Recovery)
Wiederherstellung eines Systems auf einen exakten Zeitpunkt.

WAL (Write-Ahead-Log)
Mechanismus, bei dem Datenbankänderungen zuerst in ein Log geschrieben werden, um Konsistenz und Wiederherstellung zu ermöglichen.

Weitere Informationen dazu finden sich in der offiziellen PostgreSQL-Dokumentation.

Fazit

RTO und RPO sind keine theoretischen Kennzahlen, sondern bestimmen, wie robust eine Anwendung im Ernstfall ist.

Für die Entwicklung bedeutet das, dass sich RPO-Vorgaben nicht nur definieren, sondern auch zuverlässig einhalten lassen – ohne zusätzliche Komplexität in der Anwendung selbst.