RTO/RPO

Was ist der Unterschied zwischen RTO und RPO?

Die RTO und die RPO messen beide in Zeit, schauen aber in entgegengesetzte Richtungen. Die RPO beginnt beim Ausfall und zählt rückwärts bis zum letzten Stand, den Sie wiederherstellen können. Eine RPO von 24 Stunden heißt, dass die Arbeit eines ganzen Tages verloren gehen darf, und daraus folgt direkt der Sicherungszyklus von mindestens einer Sicherung pro Tag. Die RTO zählt vorwärts, bis das System wieder läuft, und bestimmt damit das Verfahren. Reicht das Zurückspielen eines Backups, oder muss ein vorbereitetes Ersatzsystem bereitstehen? Beide Werte legen Sie unabhängig voneinander fest. Ein Wiki mit Betriebsanleitungen ändert sich selten und verträgt eine RPO von einer Woche, muss im Störfall aber nach einer Stunde lesbar sein, weil dort das Runbook steht.

Wie hängen RTO, RPO und MTPD zusammen?

Die RTO leitet sich aus der maximal tolerierbaren Ausfallzeit ab, englisch Maximum Tolerable Period of Disruption (MTPD). Die MTPD sagt, wie lange ein Geschäftsprozess ausfallen darf, bevor der Schaden nicht mehr tragbar ist, und sie entsteht in der Business-Impact-Analyse (BIA). Der BSI-Standard 200-4 von 2023, der auf die ISO 22301 abgestimmt ist, verlangt, dass die RTO kürzer ist als die MTPD. Bis zum Ausrufen des Notfalls vergeht nämlich schon Zeit. Diese Reaktionszeit zieht der Standard von der MTPD ab und empfiehlt zusätzlich einen Puffer. Nutzen mehrere Prozesse dieselbe Ressource, gilt für sie die kleinste RTO. Für einen Build-Server, an dem fünf Produktlinien hängen, entscheidet also die anspruchsvollste Linie.

Seit Dezember 2025 sind Backup und Wiederherstellung für viele Unternehmen gesetzliche Pflicht. Das BSI-Gesetz in der Fassung vom 2. Dezember 2025 verlangt von besonders wichtigen und wichtigen Einrichtungen in § 30 Maßnahmen zur Aufrechterhaltung des Betriebs, ausdrücklich Backup-Management und Wiederherstellung nach einem Notfall. RTO und RPO nennt das Gesetz nicht. Ohne sie lässt sich aber kaum belegen, dass ein Backup-Konzept zum Geschäft passt. Der Prüfstein ist der Wiederherstellungstest. Eine Sicherung, die nie zurückgespielt wurde, liefert eine Annahme über die RPO und gar keine Aussage über die RTO. Der BSI-Standard 200-4 sieht vor, die RTO in Übungen zu verifizieren. Die tatsächlich erreichbare Zeit nennt er Recovery Time Actual (RTA), und erst der Vergleich mit der RTO zeigt, ob das Konzept trägt.

Für eine CI/CD-Plattform lohnt es sich, RTO und RPO getrennt nach dem zu bestimmen, was verloren gehen kann. Konfiguration, Jobs und Zugangsdaten braucht der Betrieb. Die Workspaces braucht er nicht, nach einer Wiederherstellung checkt die Pipeline den Code ohnehin frisch aus. Build-Historie und archivierte Artefakte sind eine eigene Frage, die Ihre Release- und Nachweispflichten beantworten. Liegt die Controller-Konfiguration als Jenkins Configuration as Code (JCasC) im Repository und liegen die Pipelines als Jenkinsfile daneben, schrumpft die RTO auf die Zeit, die ein frischer Controller mit Plugin-Liste und Secrets bis zum ersten Build braucht. In der Fertigung wird diese Rechnung schnell konkret. Steht der Build-Server ausgerechnet dann, wenn eine Linie auf einen Hotfix wartet, verlängert jede Stunde seines Ausfalls den Stillstand.