RTO, RPO und Wiederherstellungsebenen definieren

Business-Continuity-Planung (BCP) bezeichnet den Prozess, durch den sichergestellt wird, dass kritische Geschäftsfunktionen während und nach einem Notfall fortgeführt werden können. Im Cloud Computing bedeutet dies, Systeme so zu entwerfen, dass sie sich innerhalb akzeptabler Zeit- und Datenverlustgrenzen von Ausfällen erholen können. Zwei wichtige Kennzahlen – RTO und RPO – legen fest, was für die jeweilige Arbeitslast als „akzeptabel“ gilt.

Das Recovery Time Objective (RTO) ist die maximal akzeptable Zeitspanne, während der ein System nach einem Notfall offline sein darf. Es beantwortet die Frage: „Wie lange kann das Unternehmen den Ausfall dieser Anwendung tolerieren?“ Das RTO wird als Zeitangabe ausgedrückt – in Stunden, Minuten oder Sekunden. Ein System zur Zahlungsabwicklung könnte ein RTO von 15 Minuten haben, während für ein internes HR-Portal ein RTO von 24 Stunden gelten könnte.

Das Recovery Point Objective (RPO) ist der maximal akzeptable Datenverlust, gemessen als Zeitspanne. Es beantwortet die Frage: „Wie viele Daten kann das Unternehmen höchstens verlieren?“ Bei einem RPO von 1 Stunde akzeptiert das Unternehmen den Verlust von Transaktionen aus bis zu 1 Stunde. Das RPO bestimmt, wie häufig Sie Daten sichern oder replizieren müssen. Ein RPO von 0 erfordert eine synchrone Replikation, die teuer ist und die Schreibleistung beeinträchtigen kann.

Es ist wichtig, RTO und RPO nicht zu verwechseln:

• RTO bezieht sich auf die Zeit – wie lange das System ausgefallen ist
• RPO bezieht sich auf die Daten – wie viele Daten verloren gehen

Ein System kann ein kurzes RTO (schnelle Wiederherstellung), aber ein langes RPO (Akzeptieren eines erheblichen Datenverlusts) haben – oder umgekehrt. Ideal sind kurze Werte für beide Kennzahlen. Dies erfordert jedoch erhebliche Investitionen in Replikation und Kapazität für den Warm Standby.

Nicht alle Arbeitslasten sind gleich kritisch. Ein gängiger Ansatz besteht darin, Arbeitslasten anhand ihrer geschäftlichen Auswirkungen in Wiederherstellungsstufen einzuteilen:

• Stufe 1 (geschäftskritisch) – strenge RTO/RPO-Vorgaben, höchste Kosten (z. B. Zahlungsabwicklung, Handelsplattformen)
• Stufe 2 (betriebsnotwendig) – moderate RTO/RPO-Vorgaben (z. B. CRM, ERP)
• Stufe 3 (unkritisch) – großzügige RTO/RPO-Vorgaben, niedrigste Kosten (z. B. Entwicklungsumgebungen, Archive)

Verschiedene Wiederherstellungsstufen werden unterschiedlichen Azure-Funktionen zugeordnet:

• Stufe 1 – Multi-Region-Schreibvorgänge in Cosmos DB, SQL Auto-Failover-Gruppen, Active-Active-Architektur, Traffic Manager
• Stufe 2 – Azure Site Recovery in eine sekundäre Region, SQL-Georeplikation (Lesereplikat), tägliche Sicherungen mit 30-tägiger Aufbewahrung
• Stufe 3 – Azure Backup mit wöchentlichen Zeitplänen, keine Replikation, Wiederherstellung aus einem Snapshot

Um die Investition in eine Architektur mit niedrigem RTO zu begründen, berechnen Sie die Ausfallkosten der Arbeitslast. Dazu zählen entgangene Umsätze, SLA-Strafzahlungen an Kunden, Produktivitätsverluste der Mitarbeitenden und Rufschädigung. Wenn eine Stunde Ausfallzeit 500.000 $ kostet, lässt sich die Ausgabe von 50.000 $ pro Monat für eine Active-Active-Konfiguration leicht rechtfertigen. Verwenden Sie diese Zahlen, um einen Business Case für die passende Wiederherstellungsstufe zu erstellen.

Azure Site Recovery (ASR) ist der wichtigste Dienst, um RTO/RPO-Ziele der Stufe 2 in Azure zu erreichen. ASR repliziert VMs kontinuierlich in eine sekundäre Region und kann innerhalb weniger Minuten ein Failover einleiten. Die Replikationsfrequenz für Azure-VMs beträgt 30 Sekunden (absturzkonsistent) oder 1–4 Stunden (anwendungskonsistent). Je nach Konfiguration liegt das RPO typischerweise in diesem Bereich.

Für Arbeitslasten, bei denen das RPO in Stunden angegeben wird, ist Azure Backup mit einem passenden Zeitplan ausreichend. Für ein RPO von 4 Stunden ist beispielsweise mindestens ein Sicherungsintervall von 4 Stunden erforderlich. Azure Backup unterstützt erweiterte Richtlinien, die stündliche Sicherungspläne für Azure-VMs ermöglichen. Bei Datenbanken kann eine zeitpunktbezogene Wiederherstellung (PITR) mit Transaktionsprotokollsicherungen ein RPO von unter 1 Stunde zu geringeren Kosten als ASR ermöglichen.

RTO- und RPO-Ziele sollten in einer Business Impact Analysis (BIA) formal dokumentiert und sowohl von technischen als auch von geschäftlichen Stakeholdern überprüft werden. Die BIA ordnet jede Anwendung ihrer Wiederherstellungsstufe zu, dokumentiert die RTO/RPO-Ziele, benennt die Azure-Dienste, mit denen diese Ziele erreicht werden sollen, und legt den Testplan fest (wie häufig der Notfallwiederherstellungsplan durch Übungen überprüft wird).

RTO- und RPO-Ziele bleiben Wunschvorstellungen, bis sie durch DR-Tests überprüft wurden. Messen Sie während eines DR-Tests die tatsächliche Wiederherstellungszeit (wird das angegebene RTO eingehalten?) und den tatsächlichen Datenverlust am Wiederherstellungspunkt (wird das angegebene RPO eingehalten?). Wenn der Test Lücken aufzeigt, aktualisieren Sie die Architektur oder die Verfahren, bis die Ziele dauerhaft erreicht werden. Dokumentieren Sie die Testergebnisse für Compliance-Audits.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.

In dieser Lektion haben Sie gelernt: RTO ist die maximal akzeptable Ausfallzeit, während RPO den maximal akzeptablen Datenverlust als Zeitspanne angibt; Arbeitslasten werden in Wiederherstellungsstufen eingeteilt, denen bestimmte Azure-Dienste zugeordnet sind; und Tests sind unerlässlich, um zu überprüfen, ob RTO-/RPO-Ziele erreichbar sind. Als Nächstes beschäftigen wir uns mit Wiederherstellungsplänen und automatisiertem Failover mit Azure Site Recovery.