RTO und RPO in der Disaster Recovery: Definitionen, Beispiele und Festlegung

Die RTO (Recovery Time Objective) ist die längste Zeit, die ein System nach einer Störung ausfallen darf. Die RPO (Recovery Point Objective) ist die größte Datenmenge, die Sie sich zu verlieren leisten können, gemessen als Zeit seit der letzten brauchbaren Kopie. Eine RTO von 4 Stunden und eine RPO von 15 Minuten bedeuten: innerhalb von 4 Stunden wieder online, mit höchstens 15 Minuten Datenverlust.

Das Wichtigste in Kürze

• Die RTO blickt vom Ausfall aus nach vorn (wie lange bis der Dienst zurück ist). Die RPO blickt zurück (wie alt ist die letzte gute Kopie der Daten).
• Beides sind Geschäftsentscheidungen. Legen Sie sie pro System über eine Business-Impact-Analyse fest und wählen Sie dann die Technik, die sie erfüllt.
• Die Backup-Frequenz begrenzt Ihre RPO: Bei Backups alle 4 Stunden beträgt der Datenverlust im schlechtesten Fall etwa 4 Stunden.
• Niedrigere Ziele kosten mehr. Eine RTO/RPO nahe null erfordert Replikation und Standby-Kapazität an einem zweiten Standort.
• Ziele auf dem Papier bedeuten wenig, bis ein Test die tatsächliche Wiederherstellungszeit und den tatsächlichen Datenverlust gemessen hat.

Was ist die RTO in der Disaster Recovery?

Die RTO ist die maximal akzeptable Zeit zwischen dem Ausfall eines Dienstes und seiner Rückkehr. AWS definiert sie in seinem Whitepaper Disaster Recovery of Workloads on AWS als „the maximum acceptable delay between the interruption of service and restoration of service“, also als maximal akzeptable Verzögerung zwischen Unterbrechung und Wiederherstellung des Dienstes. NIST beschreibt sie aus Geschäftssicht: die Zeit, die ein System in der Wiederherstellung sein kann, „before negatively impacting the organization's mission or mission/business processes“, also bevor die Mission oder die Geschäftsprozesse der Organisation negativ beeinträchtigt werden.

Die RTO umfasst die gesamte Wiederherstellung, nicht nur die technische Rücksicherung. Erkennung, die Entscheidung, den DR-Plan auszulösen, Wiederherstellung der Daten, Validierung der Anwendung und Umschalten der Nutzer zählen alle dazu. Teams, die nur die Rücksicherung messen, verfehlen ihre RTO im Ernstfall meist.

Was ist die RPO in der Disaster Recovery?

Die RPO ist der maximal akzeptable Datenverlust, in Zeit ausgedrückt. AWS nennt sie „the maximum acceptable amount of time since the last data recovery point“, also die maximal akzeptable Zeitspanne seit dem letzten Wiederherstellungspunkt der Daten. Wenn Ihre RPO 1 Stunde beträgt, müssen Sie nach einem Ausfall Daten wiederherstellen können, die höchstens 1 Stunde alt sind.

Die RPO wird davon bestimmt, wie oft Sie Daten kopieren. Nächtliche Backups ergeben im schlechtesten Fall eine RPO von etwa 24 Stunden. Backups der Datenbank-Logs alle 15 Minuten ergeben ungefähr 15 Minuten. Kontinuierliche Replikation kann sie nahe null bringen, mit einer unten erläuterten Einschränkung: Die Replikation kopiert auch Korruption und Löschungen.

RTO und RPO im Vergleich auf einen Blick

Rechenbeispiele

Beispiel 1: ein Bestellsystem. Ein Webshop legt eine RTO von 4 Stunden und eine RPO von 15 Minuten fest. Die Datenbank fällt um 10:00 Uhr aus. Der Shop muss bis 14:00 Uhr wieder Bestellungen annehmen, und höchstens die zwischen 09:45 und 10:00 Uhr aufgegebenen Bestellungen dürfen fehlen. Nächtliche Backups können das nicht leisten; der Shop braucht Backups der Transaktionslogs oder Replikation mindestens alle 15 Minuten sowie einen skriptgesteuerten Weg, die Anwendungsschicht innerhalb von 4 Stunden neu aufzubauen.

Beispiel 2: einen Backup-Plan prüfen. Ein Finanzsystem wird alle 6 Stunden gesichert, und eine vollständige Wiederherstellung dauert 3 Stunden. Verlangt das Unternehmen eine RPO von 1 Stunde und eine RTO von 2 Stunden, scheitern beide Ziele: Der Datenverlust im schlechtesten Fall liegt bei etwa 6 Stunden, und die Wiederherstellung allein überschreitet die RTO. Die Lösung sind entweder häufigere Backups plus eine schnellere Wiederherstellungsmethode oder die Geschäftsentscheidung, lockerere Ziele zu akzeptieren.

Beispiel 3: ein Portfolio in Stufen einteilen. Die meisten Unternehmen gruppieren Systeme in Stufen, statt Ziele einzeln festzulegen. Die Werte unten sind Beispiele, kein Standard.

Die Spalte zur Strategie folgt den vier Ansätzen im AWS-Whitepaper, in dem Backup and Restore die Wiederherstellung in Stunden und Multi-Site Active/Active nahezu in Echtzeit liefert. Unser Leitfaden zum Disaster-Recovery-Plan erklärt jede Strategie und die Auswahl.

Wie hängen RTO und RPO mit der maximal tolerierbaren Ausfallzeit zusammen?

Die maximal tolerierbare Ausfallzeit (MTD, Maximum Tolerable Downtime) gibt an, wie lange ein Geschäftsprozess gestört sein darf, bevor der Schaden ernst wird. NIST SP 800-34 erläutert, dass die RTO „must normally be shorter than the MTD“, also normalerweise kürzer als die MTD sein muss, denn wenn die Systeme wieder laufen, braucht das Personal noch Zeit, um Rückstände aufzuholen und verlorene Daten neu zu erfassen. Die RPO ist nicht Teil der MTD. Sie beschreibt, wie viele Daten der Prozess verlieren darf (NIST SP 800-34 Rev. 1).

In der Praxis: Wenn der Bestellprozess 8 Stunden ohne Systeme überstehen kann und das Aufholen 2 Stunden dauert, muss die IT-RTO 6 Stunden oder weniger betragen.

So legen Sie RTO und RPO fest

1. Geschäftsprozesse und ihre Abhängigkeiten auflisten. Ordnen Sie jedem Prozess die Anwendungen, Datenbanken, Identitätsdienste und Dritten zu, die er braucht.
2. Die Auswirkungen von Ausfall und Datenverlust über die Zeit abschätzen. Umsatz, Vertragsstrafen, regulatorische Risiken, Sicherheit und Reputation. AWS weist darauf hin, dass die Auswirkung vom Zeitpunkt abhängen kann: Ein Ausfall der Gehaltsabrechnung kurz vor dem Zahltag wiegt weit schwerer als einer kurz danach.
3. Ziele pro Stufe vorschlagen und vom Prozessverantwortlichen im Geschäft abzeichnen lassen. Die IT sollte sie nicht allein wählen.
4. Die Optionen bepreisen. AWS rät, dass eine Wiederherstellungsstrategie, die mehr kostet als der Schaden, vor dem sie schützt, „should not be put in place unless there is a secondary driver such as regulatory requirements“, also nur eingeführt werden sollte, wenn es einen zweiten Treiber wie regulatorische Anforderungen gibt.
5. Entwerfen und testen. Bauen Sie die Mechanismen für Backup, Replikation und Failover, führen Sie dann einen Test durch und halten Sie die erreichte Wiederherstellungszeit und den erreichten Wiederherstellungspunkt fest.
6. Jährlich überprüfen und nach größeren Änderungen. Systeme wandern zwischen den Stufen, wenn sich das Geschäft ändert.

Welche Technologien erfüllen welche Ziele?

• Geplante Backups und Snapshots eignen sich für RPOs von Stunden. Sie schützen gut vor Korruption und Löschung, weil jede Kopie ein fester Zeitpunkt ist.
• Point-in-Time-Recovery (Backups der Datenbank-Logs) senkt die RPO bei Datenbanken auf Minuten.
• Asynchrone Replikation in eine andere Region liefert eine RPO von Sekunden bis Minuten, abhängig von der Replikationsverzögerung.
• Synchrone Replikation über Availability Zones hinweg liefert eine RPO nahe null, auf Kosten der Schreiblatenz. Microsofts Azure-Well-Architected-Leitfaden zur Disaster Recovery empfiehlt synchrone Replikation über Zonen hinweg für Daten mit hoher Priorität und asynchrone Replikation über Regionen hinweg für Daten mit niedrigerer Priorität.
• Standby-Umgebungen und Automatisierung (Pilot Light, Warm Standby, Infrastructure as Code, skriptgesteuerter DNS-Failover) senken die RTO.

Achten Sie auf die Replikationsfalle. AWS weist darauf hin, dass kontinuierliche Replikation „may not protect against disaster events such as data corruption or malicious attack“ so gut schützt wie Point-in-Time-Backups, also bei Datenkorruption oder böswilligen Angriffen womöglich nicht schützt. Eine von Ransomware verschlüsselte Datenbank repliziert genauso schnell wie eine gesunde, halten Sie daher neben den Replikaten Point-in-Time-Kopien vor.

So belegen Sie, dass Sie Ihre Ziele erreichen

Messen Sie, statt anzunehmen. Notieren Sie bei jedem DR-Test, wann der Ausfall begann, wann der Plan ausgelöst wurde, wann der Dienst zurückkehrte und den Zeitstempel der zuletzt wiederhergestellten Transaktion. Daraus ergeben sich Ihre erreichte RTO und RPO. Microsofts Leitfaden empfiehlt eine Mischung aus Planspielen am Tisch, Probeläufen in Nicht-Produktionsumgebungen und Übungen auf Produktionsniveau. Verfolgen Sie die Ergebnisse über die Zeit und beheben Sie zuerst den langsamsten Schritt.

Wie Opsio unterstützt

Opsio führt Business-Impact-Workshops durch, legt gemeinsam mit Ihren Prozessverantwortlichen RTO/RPO pro Stufe fest und baut und testet über seinen Cloud-Disaster-Recovery-Service das passende Wiederherstellungsdesign auf AWS und Azure. Für die SaaS-Recruiting-Plattform WorkBuster war ein Ansatz mit nahezu null Ausfallzeit eine harte Anforderung, als Opsio die Plattform auf AWS umzog. Das Design nutzt eine hochverfügbare Multi-AZ-MySQL-Datenbank auf Amazon RDS, mit in CloudFormation-Vorlagen definierter Infrastruktur.

Häufig gestellte Fragen

Was ist der Unterschied zwischen RTO und RPO?

Die RTO gibt an, wie lange ein System nach einer Störung nicht verfügbar sein darf. Die RPO gibt an, wie viele Daten, in Zeit gemessen, Sie verlieren dürfen. Die RTO betrifft die Ausfallzeit, die RPO den Datenverlust.

Was sind gute Werte für RTO und RPO?

Eine allgemeingültige Zahl gibt es nicht. Ein Zahlungssystem braucht womöglich für beide Minuten, ein internes Reporting-Werkzeug kann 24 Stunden akzeptieren. Leiten Sie die Ziele aus den Kosten von Ausfall und Datenverlust für jeden Geschäftsprozess ab und prüfen Sie dann die Kosten, sie zu erfüllen.

Kann die RPO null sein?

Nahe null, ja, mit synchroner Replikation oder Multi-Site-Active/Active-Designs. Echten Null-Datenverlust über Regionen hinweg zu garantieren, ist wegen Entfernung und Latenz schwierig, und Replikation allein schützt nicht vor Korruption.

Ist die RTO dasselbe wie ein SLA?

Nein. Ein SLA ist ein Versprechen an Kunden zu Verfügbarkeit oder Reaktion. Die RTO ist ein internes Wiederherstellungsziel für ein Katastrophenszenario. Ihre RTO sollte Ihre SLAs unterstützen, doch beide werden unterschiedlich gemessen.

Wie oft sollten Wiederherstellungsziele überprüft werden?

Mindestens einmal im Jahr und nach größeren Änderungen an Systemen, Lieferanten oder dem Geschäft. Messen Sie sie in jedem DR-Test neu, denn es zählen die erreichten Werte.