RPO, RTO: Wie viel Ausfall darf sich ein Unternehmen leisten?

Cyberangriffe, Ransomware, Hardwaredefekte und geopolitische Risiken gehören für Unternehmen und Organisationen seit Jahren zum Alltag. Die Frage ist nicht mehr, ob Systeme ausfallen, sondern wie gut Unternehmen darauf vorbereitet sind. RPO und RTO sind nur zwei Kürzel die dabei entscheiden, ob ein Zwischenfall „nur“ ärgerlich oder existenzbedrohend wird: RPO und RTO. Gleichzeitig verschwimmen die Grenzen zwischen klassischem Backup, Disaster Recovery, Continuous Data Protection und Business Continuity – mit erheblichen Konsequenzen für Planung, Budget und Architektur.

RPO – Wie viel Verlust ist noch akzeptabel?

Das Recovery Point Objective (RPO) definiert den maximal tolerierbaren Datenverlust, ausgedrückt als Zeitspanne zwischen dem letzten konsistenten Sicherungspunkt und dem Eintritt eines Vorfalls. Im Klartext: RPO beantwortet die Frage, wie viele Minuten oder Stunden Geschäftsdaten im schlimmsten Fall verloren gehen dürfen, ohne dass das Geschäftsmodell ins Wanken gerät.

In der Praxis hängen RPO-Werte unmittelbar von der Sicherungs- oder Replikationsstrategie ab:

• Tägliches Backup über Nacht führt zu einem RPO von bis zu 24 Stunden – für viele Kernsysteme im Jahr 2026 kaum noch akzeptabel.
• Stündliche Snapshots oder Replikation senken das RPO auf 60 Minuten oder weniger, was für zahlreiche ERP- oder Collaboration-Systeme ein realistischer Kompromiss ist.
• Near-Continuous-Replikation oder Continuous Data Protection können das RPO faktisch gegen null drücken, was vor allem bei Transaktionssystemen wie Zahlungsplattformen oder Handelssystemen entscheidend ist.

Entscheidend ist: RPO ist keine rein technische Kennzahl, sondern das Ergebnis einer bewussten Abwägung zwischen Risiko, Kosten und Compliance-Anforderungen. Wer RPO-Ziele ohne Einbindung der Fachbereiche setzt, betreibt im Grunde Blindflug.

RTO – Wie lange hält das Business ohne IT durch?

Das Recovery Time Objective (RTO) beschreibt, wie lange ein Service oder ein Geschäftsprozess im Störungsfall maximal ausfallen darf, bevor der Schaden als nicht mehr akzeptabel gilt. RTO ist damit der zeitliche Rahmen, in dem IT und Fachbereiche den Betrieb zumindest in einem definierten Notmodus wiederherstellen müssen.

RTO ist deutlich mehr als die reine technische Wiederherstellungszeit einer VM oder Datenbank. Es umfasst tatsächlich mindestens:

• Erkennung und Klassifizierung des Vorfalls.
• Eskalation und Aktivierung des Notfallteams.
• Bereitstellung der Infrastruktur im Ziel-Umfeld (z. B. enthus cloud, zweites Rechenzentrum, Public Cloud).
• Wiederherstellung von Daten, Applikationen, Schnittstellen und Identity-Services.
• Verifikation, Freigabe und Übergabe an die Fachbereiche.

Jeder dieser Schritte beeinflusst das tatsächliche RTO – und in der Realität klaffen Plan und Wirklichkeit oft weit auseinander.

Klassisches Backup – Datensicherung ist nicht gleich Verfügbarkeit

Klassisches Backup verfolgt ein klar umrissenes Ziel: Daten in konsistenten Zuständen zu sichern, um sie nach logischen Fehlern, versehentlichem Löschen, Ransomware oder Applikationsfehlern wiederherstellen zu können. Im Zentrum stehen Objekte wie Dateien, Datenbanken, VMs oder Applikationskonsistenzen – nicht zwingend der komplette Service oder Prozess.

Typische Merkmale von klassischem Backup:

• Periodische Sicherung (z. B. einmal pro Tag oder alle paar Stunden).
• Speicherung auf Disk, Tape oder in der Cloud, mit Möglichkeit zum Offsite- und Air-Gap-Schutz.
• Fokus auf Wiederherstellung einzelner Objekte oder Systeme, oft mit signifikanten Restore-Zeiten.

Damit erfüllt Backup zwar einen essenziellen Compliance- und Sicherheitszweck, löst aber weder die Frage nach der Gesamtverfügbarkeit von Services noch nach der Geschwindigkeit eines orchestrierten Wiederanlaufs. Wer „Backup“ mit „Disaster Recovery“ gleichsetzt, verwechselt Datensicherung mit betriebskritischer Resilienz.

Disaster Recovery – Wenn ganze Standorte ausfallen

Disaster Recovery (DR) setzt dort an, wo klassisches Backup endet: beim orchestrierten Wiederanlauf kompletter IT-Services nach gravierenden Ereignissen wie Brand, Überschwemmung, Stromausfall, massiver Cyberattacke oder dem Ausfall eines ganzen Rechenzentrums. DR betrachtet nicht nur Daten, sondern auch Infrastruktur, Netzwerke, Abhängigkeiten zwischen Systemen und die Reihenfolge des Wiederanlaufs.

Typische Bausteine einer modernen DR-Strategie:

• Sekundäre Standorte oder Cloud-Zielumgebung (z. B. Managed Private Cloud/enthus cloud oder Hyperscaler).
• Replikation von VMs, Containern, Datenbanken und Konfigurationen, ergänzt durch klassische Backups.
• Orchestrierte Failover-Workflows inklusive Tests, Runbooks und automatisierten Startreihenfolgen.
• Regelmäßige DR-Tests

Während Backup primär RPO adressiert („Wie viel verlieren wir?“), zielt Disaster Recovery auf die Kombination aus RPO und RTO („Wie viel verlieren wir – und wie lange stehen wir?“). Moderne DR-Szenarien richten sich stark an geschäftskritischen Services aus und priorisieren Workloads nach ihrer Bedeutung für das Business.

Continuous Data Protection – RPO fast bei null

Continuous Data Protection (CDP) schiebt die Grenze der Datensicherung noch ein Stück weiter nach vorn. Statt Daten zu festen Intervallen zu sichern, erfasst CDP-Änderungen nahezu kontinuierlich oder in sehr kurzen Abständen und versieht sie mit Zeitstempeln.

Das ermöglicht:

• Nahezu beliebige Rückspulpunkte bis kurz vor dem Vorfall, etwa auf Sekunden- oder Minutenbasis.
• RPO gegen null für ausgewählte, hochkritische Workloads wie Zahlungsverkehr, E-Commerce oder Trading.
• Schnellere, gezieltere Wiederherstellungen, weil auf einen sehr spezifischen Zeitpunkt (vor der Korruption oder Infektion) zurückgesetzt werden kann.

CDP ist jedoch kein Allheilmittel, sondern ein Werkzeug für Workloads, bei denen klassisches Backup oder selbst häufige Snapshots nicht ausreichen. Die technische Komplexität, der Speicherbedarf und die Anforderungen an Bandbreite und Latenz machen CDP typischerweise zu einem gezielt eingesetzten Instrument im DR-Portfolio, nicht zum Standardverfahren für sämtliche Systeme.

Business Continuity – Wenn IT nur ein Teil des Puzzles ist

Wo Disaster Recovery stark IT-zentriert ist, denkt Business Continuity (BC) in Ende-zu-Ende-Prozessen und Geschäftsmodellen. Business-Continuity-Management zielt darauf ab, kritische Geschäftsabläufe auch in Krisen fortzuführen – notfalls in reduzierter Form, aber ohne Kontrollverlust über Reputation, Kundenbeziehungen und regulatorische Anforderungen.

Ein Business-Continuity-Plan adressiert typischerweise:

• Kritische Prozesse (z. B. Auftragsabwicklung, Patientenversorgung, Zahlungsverkehr) und deren Abhängigkeiten.
• Alternativprozesse und Workarounds, etwa manuelle Erfassung, Umleitung von Services oder verteiltes Arbeiten.
• Ressourcen wie Menschen, Gebäude, Lieferketten, Kommunikationswege und Partner.

Disaster Recovery ist in diesem Bild der technische Backbone, der sicherstellt, dass die IT-Services rechtzeitig zur Verfügung stehen, damit die im BC-Plan vorgesehenen Maßnahmen greifen können. Ohne abgestimmte RPO-/RTO-Ziele zwischen IT und Fachbereichen bleibt Business Continuity ein Papiertiger.

Backup, DR, CDP und BC im Vergleich

Die folgenden Gegenüberstellungen machen deutlich, wie sich die Disziplinen unterscheiden und ergänzen:

Zielsetzung

• Backup: Schutz von Daten, Erfüllung von Compliance-Anforderungen, Wiederherstellung auf Datei-, Anwendungs- oder Systemebene.
• Disaster Recovery: Wiederanlauf kompletter IT-Services nach schweren Störungen, inklusive Infrastruktur, Netzwerk und Abhängigkeiten.
• CDP: Minimierung von Datenverlust und Reduktion von RPO auf nahezu null, insbesondere bei hochkritischen, transaktionalen Workloads.
• Business Continuity: Sicherstellung der Fortführung geschäftskritischer Prozesse – IT ist ein Baustein unter vielen.

Typische RPO-/RTO-Werte

• Backup: RPO im Bereich Stunden bis Tage, RTO von Stunden bis Tagen, abhängig von Datenvolumen und Infrastruktur.
• DR: RPO im Minuten- bis Stundenbereich, RTO von Minuten bis wenigen Stunden für priorisierte Systeme.
• CDP: RPO nahe null, RTO abhängig von Orchestrierung und Zielplattform, meist deutlich niedriger als bei reinem Backup.
• BC: RPO/RTO werden pro Prozess definiert, IT-Werte müssen sich an diesen geschäftlichen Vorgaben ausrichten.

Betriebliche Sicht

• Backup beantwortet: „Können wir verlorene Daten wiederbeschaffen?“
• Disaster Recovery beantwortet: „Können wir unsere Services nach einem großen Zwischenfall rechtzeitig wieder bereitstellen?“
• CDP beantwortet: „Können wir uns praktisch ohne relevanten Datenverlust von einem Vorfall erholen?“
• Business Continuity beantwortet: „Können wir unser Geschäft auch in der Krise handlungsfähig halten?“

Fazit für Entscheider: RPO und RTO gehören ins Top-Management

RPO und RTO sind keine reinen IT-Kürzel, sondern harte Steuerungsgrößen für Risiko, Investitionsentscheidungen und Resilienz. Wer sie ernst nimmt, leitet daraus eine abgestufte Strategie aus klassischem Backup, orchestriertem Disaster Recovery, selektivem Einsatz von Continuous Data Protection und einem gelebten Business-Continuity-Management ab.

Gerade mittelständische Unternehmen, die auf hybride Infrastrukturen und spezialisierte Service-Provider setzen, können hier mit einem durchdachten Design – etwa auf Basis einer Managed Private Cloud in Deutschland, wie unserer enthus cloud – ein Resilienzniveau erreichen, dass früher nur Großunternehmen vorbehalten war. Entscheidend ist, dass Technik, Prozesse und Business-Ziele konsequent aneinander ausgerichtet werden – und dass die im Krisenfall wirklich erreichbare RTA regelmäßig überprüft wird, bevor der Ernstfall diese Lücke gnadenlos offenlegt.

Sprechen Sie uns für weitere Details, eine Beratung oder ein Expertengespräch gerne auch direkt an oder wenden Sie sich formlos an hallo@enthus.de.