RTO und RPO richtig festlegen: Wie viel Ausfall und Datenverlust verträgt Ihr Betrieb?

Fachlich geprüft von Robin Roeder, Geschäftsführer der SCREENUS GmbH · zuletzt geprüft am 13.09.2026.

Ein tägliches Backup beantwortet noch nicht die entscheidenden Fragen eines Ausfalls: Wie viele Arbeitsstände dürfen verloren gehen und wann muss welcher Geschäftsprozess wieder nutzbar sein? Mit RPO und RTO werden diese Erwartungen messbar – und erst dadurch lassen sich Sicherung, Wiederanlauf und Kosten sinnvoll planen.

RPO: Der tolerierbare Rücksprung der Daten

Die Recovery Point Objective legt fest, wie viel Datenverlust ein Unternehmen zeitlich akzeptieren kann. Ein RPO von einer Stunde bedeutet beispielsweise nicht automatisch, dass jede Stunde ein Backupjob genügt. Jobdauer, Replikationsverzug, fehlgeschlagene Sicherungen und der Zeitpunkt des Ausfalls beeinflussen den tatsächlich erreichbaren Wiederherstellungspunkt.

Das BSI leitet aus der RPO den notwendigen Datensicherungszyklus ab. Für Daten mit hoher Änderungsrate kann deshalb eine häufigere Sicherung oder Replikation nötig sein als für ein weitgehend unverändertes Archiv. Entscheidend ist die geschäftliche Wirkung: Können Aufträge erneut erfasst werden? Lassen sich Maschinenzustände rekonstruieren? Sind Buchungen oder Dokumente aus anderen Quellen wiederherstellbar?

RTO: Die Zeit bis zum nutzbaren Betrieb

Die Recovery Time Objective ist die geforderte Wiederanlaufzeit. Nach BSI-Standard 200-4 wird sie aus der maximal tolerierbaren Ausfallzeit eines zeitkritischen Geschäftsprozesses abgeleitet und muss kürzer als diese sein. Sie umfasst nicht bloß das Zurückkopieren von Dateien, sondern den Weg bis zu einer ausreichend nutzbaren Lösung.

Dazu können Alarmierung, Entscheidung, Bereitstellung einer Ersatzumgebung, Wiederherstellung, technische Prüfung und die Freigabe durch den Fachbereich gehören. Der genaue Start- und Endpunkt muss im Notfallplan eindeutig beschrieben werden. Sonst misst die IT nur die Dauer eines Restorejobs, während der Betrieb noch auf Anmeldung, Netzwerk, Lizenzen oder eine abhängige Anwendung wartet.

Warum ein einziger Wert für das ganze Unternehmen nicht funktioniert

Geschäftsprozesse besitzen unterschiedliche Folgen bei Ausfall und Datenverlust. Das Bestellsystem, die Produktionssteuerung, die Telefonie und ein historisches Archiv brauchen daher nicht automatisch dieselben Ziele. Microsoft weist ebenfalls darauf hin, dass einzelne Arbeitsabläufe innerhalb einer Lösung unterschiedliche RTO- und RPO-Anforderungen haben können.

Zwei rein illustrative Beispiele zeigen den Unterschied: Ein laufender Auftragsprozess könnte nach einer betrieblichen Bewertung höchstens 30 Minuten Daten verlieren und innerhalb von vier Stunden wieder anlaufen müssen. Für ein selten genutztes Archiv könnten 24 Stunden Datenverlust und zwei Tage Wiederanlauf noch vertretbar sein. Diese Zahlen sind keine Empfehlung; echte Werte entstehen ausschließlich aus der Auswirkungsanalyse des jeweiligen Unternehmens.

RTO und RPO in sieben Schritten festlegen

1. Geschäftsprozesse erfassen. Beginnen Sie bei Verkauf, Leistungserbringung, Produktion, Kommunikation und gesetzlichen beziehungsweise vertraglichen Pflichten – nicht bei Servernamen.
2. Auswirkungen über die Zeit bewerten. Halten Sie fest, wann ein Ausfall zu nicht mehr vertretbaren finanziellen, operativen oder vertraglichen Folgen führt.
3. Notbetriebsniveau bestimmen. Definieren Sie, welche Mindestleistung nach dem Wiederanlauf nötig ist. Ein Prozess muss nicht sofort mit voller Kapazität starten, aber der reduzierte Betrieb muss stabil und sinnvoll sein.
4. RTO mit Puffer ableiten. Planen Sie die Wiederanlaufzeit kürzer als die maximal tolerierbare Ausfallzeit. Berücksichtigen Sie Erkennung, Eskalation, Entscheidungen und Übergaben.
5. RPO aus Datenfolgen bestimmen. Fragen Sie, wie viele Änderungen tatsächlich rekonstruiert werden können und ab wann der Verlust geschäftlich nicht mehr akzeptabel ist.
6. Abhängigkeiten zuordnen. Verbinden Sie Prozesse mit Anwendungen, Datenbanken, Identitäten, Netzwerk, Internet, Strom, Endgeräten, Dienstleistern und verantwortlichen Personen.
7. Technik und Verfahren auswählen. Erst jetzt werden Backup-Intervalle, unveränderbare Kopien, Replikation, Ersatzsysteme, manuelle Übergangslösungen und Wiederanlaufreihenfolge festgelegt.

Typische Denkfehler

„Der Backupjob war grün, also ist die RPO erfüllt“

Ein erfolgreicher Job zeigt zunächst nur, dass Daten geschrieben wurden. Ob der Sicherungsstand vollständig, lesbar, ausreichend aktuell und in einer sauberen Umgebung wiederherstellbar ist, muss separat geprüft werden.

„Eine Replikation ersetzt das Backup“

Replikation kann Ausfallzeiten verkürzen, überträgt aber je nach Verfahren auch versehentliche Löschungen, beschädigte Daten oder Angriffe. Versionierte und vom Produktivsystem getrennte Sicherungen bleiben für solche Fehlerbilder wichtig.

„Die schnellste Datenbank bestimmt die RTO“

Ein Geschäftsvorgang funktioniert oft erst, wenn Identitäten, Namensauflösung, Netzwerk, Anwendung, Datenbank, Schnittstellen und Arbeitsplätze gemeinsam bereitstehen. Der langsamste kritische Pfad und die menschlichen Entscheidungen bestimmen den realen Wiederanlauf.

„Null Ausfall und null Datenverlust sind immer das beste Ziel“

Nahezu unterbrechungsfreie Architekturen können technisch aufwendig und teuer sein. Microsoft empfiehlt, Ziele zwischen Fachbereich, Technik und Verantwortlichen realistisch abzuwägen. Zu hohe Anforderungen verschwenden Ressourcen; zu niedrige Anforderungen gefährden den Betrieb.

So wird aus einem Ziel ein belastbarer Restore-Test

Ein Test braucht einen klaren Startzeitpunkt, messbare Abnahmekriterien und eine dokumentierte Zielumgebung. Die Wiederherstellung sollte nicht unkontrolliert in das Produktivsystem erfolgen. Benötigt werden neben Nutzdaten oft Konfigurationen, Konten, Schlüssel, Zertifikate, Installationsmedien, Lizenzen und nachvollziehbare Wiederanlaufanweisungen.

1. Szenario und betroffene Prozesse festlegen. Ein versehentlich gelöschter Ordner erfordert einen anderen Ablauf als ein verschlüsseltes Netzwerk oder der Verlust eines Standorts.
2. Wiederherstellungspunkt auswählen. Prüfen Sie, ob dessen Alter innerhalb der RPO liegt und ob abhängige Datenstände zusammenpassen.
3. Zeit vollständig messen. Erfassen Sie nicht nur die Kopierdauer, sondern auch Alarmierung, Freigabe, Aufbau, Prüfung und Übergabe an den Fachbereich.
4. Funktion fachlich bestätigen. Anwender müssen einen repräsentativen Geschäftsablauf durchführen können. Eine gestartete virtuelle Maschine allein erfüllt die RTO noch nicht.
5. Abweichungen nachverfolgen. Passen Sie Runbook, Technik, Zuständigkeiten oder Ziele an und wiederholen Sie den Test nach wesentlichen Änderungen.

CISA empfiehlt, Verfügbarkeit und Integrität von Sicherungen regelmäßig in einem Wiederherstellungsszenario zu testen und kritische Dienste in priorisierter Reihenfolge zurückzubringen. Das macht aus einem theoretischen Ziel einen überprüfbaren Betriebsprozess.

Wie SCREENUS unterstützen kann

Wir unterstützen Unternehmen dabei, Geschäftsprozesse und technische Abhängigkeiten zusammenzuführen, realistische RTO- und RPO-Ziele zu dokumentieren und daraus Backup-, Wiederanlauf- und Testverfahren abzuleiten. Bestehende Sicherungen prüfen wir nicht nur auf Jobstatus, sondern anhand kontrollierter Wiederherstellungen und nachvollziehbarer Abnahmekriterien.

Backup & IT-Notfallvorsorge ansehen Wiederanlaufziele besprechen

Häufige Fragen

Dieser Beitrag dient der allgemeinen technischen Information und ist keine Rechts-, Vertrags- oder Compliance-Beratung. Konkrete Wiederanlaufziele müssen anhand der Prozesse, Verpflichtungen, Risiken und verfügbaren Ressourcen des jeweiligen Unternehmens festgelegt werden.