Die Einschätzung der Cyber Academy
RTO ist die maximal tolerierbare Ausfallzeit eines Geschäftsprozesses, bevor ein nicht hinnehmbarer Schaden entsteht. RPO ist der maximal akzeptable Datenverlust, gemessen in Zeit vor dem Ausfall. Beide Werte werden aus der BIA abgeleitet. Die Kennzahlen, die der CIO ohne Rücksprache mit dem Fachbereich in das BCP schreibt, sind genau die Kennzahlen, die im Ernstfall versagen.
Zwei Uhren, die unterschiedliche Dinge messen
RTO und RPO sind die beiden Wiederherstellungsziele, die ein vages Resilienzversprechen in überprüfbare Zahlen verwandeln. Sie sind leicht zu verwechseln, weil beide in Zeiteinheiten ausgedrückt werden, aber sie messen unterschiedliche Dinge und verweisen auf unterschiedliche Lösungen. Das recovery time objective betrifft, wie lange Sie ausfallen können. Das recovery point objective betrifft, wie viele Daten Sie sich leisten können zu verlieren. Verwechseln Sie sie, kaufen Sie die falsche Wiederherstellungsarchitektur.
Stellen Sie sich die Störung als einen einzelnen Moment auf einer Zeitachse vor. Das RTO blickt von diesem Moment nach vorn: Es ist das maximale Zeitfenster zwischen dem Ausfall und dem Moment, in dem der Prozess wieder nutzbar ist, bevor der Schaden inakzeptabel wird. Das RPO blickt von diesem Moment zurück: Es ist das maximale Alter der letzten gültigen Datenkopie, auf die Sie wiederherstellen können, was den jüngsten Daten entspricht, die Sie zu verlieren bereit sind. Ein RTO von vier Stunden mit einem RPO von fünfzehn Minuten bedeutet, dass der Dienst innerhalb von vier Stunden wieder verfügbar sein muss und nicht mehr als fünfzehn Minuten an Transaktionen verlieren darf.
| RTO | RPO | |
|---|---|---|
| Misst | Akzeptable Ausfallzeit | Akzeptabler Datenverlust |
| Richtung auf der Zeitachse | Nach vorn ab der Störung | Zurück ab der Störung |
| Beantwortete Frage | Wie schnell müssen wir wieder verfügbar sein? | Wie viele Daten dürfen wir verlieren? |
| Hauptsächlich bestimmt durch | Wiederherstellungsprozess, Failover, Personal | Häufigkeit von Backup und Replikation |
| Quelle | Business-Impact-Analyse | Business-Impact-Analyse |
Woher die Zahlen kommen und warum Verantwortung zählt
Beide Ziele sind Ergebnisse der Business-Impact-Analyse, keine im Serverraum getroffenen Vermutungen. Die BIA untersucht jede kritische Aktivität, misst, wie der Schaden eines Ausfalls im Laufe der Zeit wächst, und erzeugt Wiederherstellungsziele, die der Prozessverantwortliche validiert. Genau diese Verantwortung ist der entscheidende Punkt. Ein RTO und ein RPO, die ein Technikteam isoliert festlegt, beschreiben, was die Infrastruktur leisten kann, nicht, was das Geschäft braucht, und die Lücke zwischen beiden zeigt sich erst während eines echten Vorfalls, dem schlechtesten Zeitpunkt, um sie zu entdecken.
Die Ziele müssen auch mit den Kosten abgewogen werden. Ein RPO gegen null zu treiben bedeutet kontinuierliche oder synchrone Replikation. Ein RTO gegen wenige Minuten zu treiben bedeutet Hot-Standby-Kapazität, die ungenutzt bereitsteht. Beides ist teuer, daher erzwingt die BIA ein ehrliches Gespräch darüber, welche Prozesse diese Ausgabe wirklich rechtfertigen und welche ein längeres Zeitfenster tolerieren können. Aktivitäten in Stufen einzuteilen ist normal: Die Zahlungs-Engine und die Marketing-Website verdienen selten dieselben Ziele.
Wie RTO und RPO in die Standards passen
Diese Ziele sind zentrales Vokabular in Kontinuitäts- und Resilienzrahmenwerken. ISO 22301, der internationale Standard für Business-Continuity-Managementsysteme, behandelt recovery time und recovery point objectives als Ergebnisse der Impact-Analyse, die Kontinuitätsstrategie und -lösungen steuern. Sie fließen direkt in das Design der Notfallwiederherstellung, in Backup-Zeitpläne und in die Wahl der Wiederherstellungsstandorte ein. In regulierten Sektoren werden sie zunehmend geprüft statt vorausgesetzt: Die EU-Verordnung DORA legt Kontinuitäts- und Testerwartungen für Finanzunternehmen fest, und die NIS-2-Richtlinie verlangt von wesentlichen und wichtigen Einrichtungen Maßnahmen zur Geschäftskontinuität und zum Backup.
Praktiker tun drei Dinge mit diesen Zahlen. Sie leiten sie gemeinsam mit den Geschäftsverantwortlichen aus der BIA ab. Sie gestalten Backup, Replikation und Failover so, dass die Architektur sie tatsächlich erreichen kann. Dann beweisen sie es durch Tests, denn ein ungetestetes RTO ist eine Absichtserklärung. Das Ziel gewinnt erst Vertrauen, wenn eine Wiederherstellungsübung gezeigt hat, dass das Team es unter realistischen Bedingungen erreichen kann.
Frequently asked questions
01Was ist der Unterschied zwischen RTO und RPO?
Das RTO ist die maximale Zeit, die ein Prozess ausfallen kann, bevor der Schaden inakzeptabel wird, gemessen nach vorn ab der Störung. Das RPO ist der maximale Datenverlust, den Sie tolerieren können, gemessen zurück ab der Störung als das Alter der letzten wiederherstellbaren Kopie. Das eine bestimmt die Wiederherstellungsgeschwindigkeit, das andere die Backup-Häufigkeit.
02Woher kommen die Werte für RTO und RPO?
Sie sind Ergebnisse der Business-Impact-Analyse. Die BIA stuft jede Aktivität danach ein, wie der Schaden einer Störung im Laufe der Zeit wächst, und erzeugt Ziele, die der Prozessverantwortliche validiert, statt Zahlen, die die IT isoliert festlegt.
03Erfordert ein niedriges RPO kontinuierliche Backups?
In der Regel ja. Das RPO kann nicht kürzer sein als das Intervall zwischen wiederherstellbaren Kopien, daher benötigt ein RPO nahe null eine häufige oder kontinuierliche Replikation. Das RPO zu senken erhöht somit die Kosten, weshalb die BIA die strengsten Ziele den Aktivitäten vorbehält, die sie rechtfertigen.
04Was passiert, wenn unsere Wiederherstellung länger dauert als das RTO?
Sie haben eine Resilienzlücke. Das RTO ist das tolerierbare Ziel; die Zeit, die die Wiederherstellung tatsächlich braucht, ist die recovery time achieved, gemessen in einem Test. Übersteigt die erreichte Zeit das Ziel, schließen Sie die Lücke, indem Sie den Wiederherstellungsprozess verbessern, oder Sie akzeptieren ein dokumentiertes Risiko, aber Sie lockern das Ziel nicht stillschweigend.
05Geht es bei RTO und RPO nur um IT-Systeme?
Sie werden am häufigsten auf Daten und IT-Dienste angewandt, gehören aber zu den Geschäftsprozessen. Ein Prozess kann seine Systeme innerhalb des RTO wiederhergestellt haben und dennoch nicht arbeitsfähig sein, wenn Menschen, Räumlichkeiten oder ein kritischer Lieferant fehlen, weshalb die Ziele gegen die gesamte Aktivität validiert werden, nicht nur gegen die Anwendung.