Zurück zum Blog Security and Reliability

RTO und RPO für eine Geschäftsanwendung festlegen: Ein praktischer Leitfaden

Legen Sie Wiederherstellungsziele fest, indem Sie die geschäftlichen Auswirkungen von Ausfallzeiten und Datenverlust ermitteln. Prüfen Sie anschließend, ob Ihre Wiederherstellungsmaßnahmen diese Ziele unterstützen können.

Arbeitsblatt zur Wiederherstellungsplanung für eine Geschäftsanwendung mit Feldern für RTO, RPO, Arbeitsabläufe und Abhängigkeiten

RTO und RPO beantworten unterschiedliche Fragen zur Wiederherstellung

Das Wiederherstellungszeitziel (Recovery Time Objective, RTO) gibt an, wie lange ein System oder Geschäftsprozess ausfallen darf, bevor die Auswirkungen nicht mehr akzeptabel sind. Das Wiederherstellungspunktziel (Recovery Point Objective, RPO) beschreibt, wie viele der zuletzt erfassten Daten ein Unternehmen höchstens verlieren kann, ausgedrückt als Zeitraum.

Stellen Sie sich vor, eine Anwendung fällt aus, nachdem die letzte wiederherstellbare Sicherung am Vorabend erstellt wurde. Das RPO beschreibt, welcher Teil der seit diesem Wiederherstellungspunkt eingegebenen Arbeit verloren gehen könnte. Das RTO beschreibt, wie lange das Unternehmen einen Ausfall der Anwendung tolerieren kann, während sie wiederhergestellt und erneut nutzbar gemacht wird.

Diese Ziele hängen zusammen, aber das eine legt das andere nicht fest. Ein Unternehmen muss eine Anwendung möglicherweise schnell wieder verfügbar machen, kann aber einige kürzlich erfasste Daten erneut eingeben. Oder es kann einen längeren Ausfall tolerieren, möchte aber möglichst keine Transaktionen verlieren.

RTO und RPO beantworten unterschiedliche Fragen zur Wiederherstellung

Beginnen Sie mit dem Geschäftsablauf, nicht mit dem Server

Listen Sie zunächst die Aufgaben auf, die von der Anwendung unterstützt werden, bevor Sie über Wiederherstellungsziele sprechen. Ein CRM kann Vertrieb und Kundenservice unterstützen; ein Online-Shop kann Produktansichten, Bestellungen und Zahlungsabwicklung ermöglichen. Entscheidend ist, was die Mitarbeitenden nicht erledigen können, wenn die Anwendung nicht verfügbar oder ihr Datenbestand veraltet ist.

Ermitteln Sie für jeden Arbeitsablauf, wer betroffen ist, ob die Arbeit vollständig zum Stillstand kommt und welche Alternativen es gibt. Mitarbeitende können Anfragen beispielsweise vorübergehend in einem anderen genehmigten System erfassen. Diese Ausweichlösung kann jedoch langsam oder eingeschränkt und für bestimmte Daten ungeeignet sein.

Ein sinnvoller Ausgangspunkt ist eine kurze Analyse der geschäftlichen Auswirkungen: Ermitteln Sie die kritischen Prozesse, die dafür benötigten Systeme und die Folgen einer Unterbrechung. Beziehen Sie auch die Personen ein, die die Arbeit ausführen, nicht nur die für die Anwendung verantwortliche Person.

  • Benennen Sie den Arbeitsablauf und die davon abhängigen Anwendungsfunktionen.
  • Ermitteln Sie, welche Mitarbeitenden, Kunden oder Partner von einer Unterbrechung betroffen sind.
  • Halten Sie manuelle oder alternative Verfahren, ihre Grenzen und die Personen fest, die ihre Nutzung genehmigen können.
  • Notieren Sie, welche Geschäftsaktivitäten zuerst wieder aufgenommen werden müssen.
Beginnen Sie mit dem Geschäftsablauf, nicht mit dem Server

Schätzen Sie die Auswirkungen von Ausfallzeiten für verschiedene Zeiträume ein

Legen Sie kein RTO fest, nur weil eine bestimmte Zahl beruhigend klingt. Schätzen Sie die Folgen eines Ausfalls für mehrere Zeiträume ein, etwa für eine kurze Unterbrechung, einen Teil des Arbeitstags und eine längere Störung. Welche Zeiträume sinnvoll sind, hängt von der Arbeitsweise des Unternehmens ab.

Berücksichtigen Sie entgangene Verkäufe, nicht eingehaltene Servicezusagen, arbeitsunfähige Mitarbeitende, verzögerte Entscheidungen und Kunden, die sich möglicherweise an andere Anbieter wenden. Fragen Sie, ab wann die Gesamtauswirkungen die Belastbarkeit des Unternehmens übersteigen. Dieser Punkt hilft, ein RTO-Ziel zu bestimmen; er beweist nicht, dass die Wiederherstellung bis dahin abgeschlossen sein wird.

Unterscheiden Sie zwischen der Zeit, die nötig ist, um den technischen Zugang wiederherzustellen, und der Zeit, die benötigt wird, um den Geschäftsprozess wieder aufzunehmen. Eine Anwendung kann bereits laufen, während Mitarbeitende noch Datensätze überprüfen, Zugriffe bestätigen oder einen Rückstand abarbeiten müssen.

  • Beschreiben Sie die Folgen eines Ausfalls für jeden gewählten Zeitraum.
  • Berücksichtigen Sie neben direkten finanziellen Auswirkungen auch betriebliche Störungen.
  • Ermitteln Sie, ab wann eine Ausweichlösung nicht mehr akzeptabel ist.
  • Legen Sie fest, was für den Arbeitsablauf als „wiederhergestellt“ gilt – nicht nur für den Server.

Legen Sie das RPO anhand der wiederherstellbaren Daten fest

Ermitteln Sie für jeden Arbeitsablauf, welche Datensätze während der normalen Arbeit erstellt oder geändert werden, und fragen Sie, wie viele dieser Informationen sich nach einer Störung rekonstruieren ließen. Ein Produktkatalog lässt sich möglicherweise aus einer anderen Quelle wiederherstellen, während aktuelle Bestellungen, Zahlungen oder Kundenaktualisierungen nur schwer oder gar nicht korrekt rekonstruiert werden können.

Der akzeptable Zeitraum für Datenverluste kann sich zwischen verschiedenen Teilen derselben Anwendung unterscheiden. Überlegen Sie, was geschähe, wenn das Unternehmen kürzlich erledigte Arbeit erneut eingeben müsste und ob diese Eingabe vollständig, zeitnah und sicher wäre. Berücksichtigen Sie auch das Risiko doppelter oder widersprüchlicher Datensätze, wenn Mitarbeitende während eines Ausfalls eine Ausweichlösung nutzen.

Formulieren Sie das RPO als geschäftliche Toleranz, nicht als Annahme darüber, wie oft Daten gespeichert werden. Anschließend müssen Sie prüfen, ob die Wiederherstellungsmaßnahmen dieser Toleranz entsprechen.

  • Listen Sie die wichtigen Daten je Arbeitsablauf auf, darunter Transaktionen, hochgeladene Dateien und Änderungen an vorhandenen Datensätzen.
  • Ordnen Sie die einzelnen Datenarten als leicht, schwer oder gar nicht rekonstruierbar ein.
  • Fragen Sie, wie viel kürzlich erledigte Arbeit ohne unzumutbare Kosten, Verwirrung oder Risiken wiederholt werden könnte.
  • Halten Sie für jeden Arbeitsablauf das akzeptable Alter der wiederherstellbaren Daten fest.

Berücksichtigen Sie die für die Wiederherstellung benötigten Abhängigkeiten

Eine Anwendung ist nur ein Teil ihres Dienstes. Die Wiederherstellungsplanung sollte unterstützende Technologien und Dienste umfassen, die den Geschäftsprozess beeinflussen – auch wenn sie normalerweise nicht für sich allein als kritisch gelten.

Verfolgen Sie den Weg, den eine Person zurücklegt, um eine Aufgabe zu erledigen. Je nach Anwendung kann dieser Weg eine Datenbank, hochgeladene Dateien, Identitäts- oder Authentifizierungsdienste, DNS, Routing, TLS-Zertifikate, E-Mail oder andere externe Dienste umfassen. Klären Sie, welche Abhängigkeiten unverzichtbar sind, wer sie verwaltet und was geschehen muss, bevor Mitarbeitende wieder arbeiten können.

Berücksichtigen Sie auch Integrationen und externe Partner. Eine wiederhergestellte Anwendung unterstützt den Arbeitsablauf möglicherweise nicht, wenn ein unverzichtbarer verbundener Dienst nicht verfügbar ist oder seine Verbindung überprüft werden muss.

  • Listen Sie die Anwendung, die Datenbank und die für den Arbeitsablauf benötigten Dateien auf.
  • Berücksichtigen Sie bei Bedarf Abhängigkeiten für Zugriffe, Domainnamen und Verbindungen.
  • Notieren Sie externe Dienste und Partner, von denen die Anwendung abhängt.
  • Bestimmen Sie für jede Abhängigkeit eine verantwortliche Person oder Kontaktstelle und halten Sie die Wiederherstellungsreihenfolge fest.

Legen Sie unterschiedliche Ziele fest, wenn sich die geschäftliche Kritikalität unterscheidet

Ein einheitliches RTO und RPO für alle Anwendungen kann wichtige Unterschiede verdecken. Legen Sie Ziele für die jeweilige Anwendung oder den Arbeitsablauf anhand ihrer geschäftlichen Auswirkungen, der Toleranz gegenüber Datenverlusten und der verfügbaren Alternativen fest.

Der Arbeitsablauf zur Annahme von Kundenbestellungen kann beispielsweise andere Wiederherstellungsanforderungen haben als ein interner Berichtsprozess, obwohl beide dieselbe Anwendung nutzen. Dokumentieren Sie den Grund für jede Abweichung, damit die Ziele geschäftliche Prioritäten widerspiegeln und nicht auf einer informellen Rangfolge von Software beruhen.

Wenn mehrere Arbeitsabläufe von einer Anwendung abhängen, halten Sie fest, welcher davon die Wiederherstellungspriorität bestimmt. Stellen Sie sicher, dass die Verantwortlichen für diese Arbeitsabläufe den vorgeschlagenen Zielen zustimmen.

  • Gruppieren Sie Anwendungen oder Arbeitsabläufe nach geschäftlichen Auswirkungen und nicht allein aus technischen Gründen.
  • Weisen Sie jeder relevanten Gruppe oder Nutzung ein RTO und RPO zu.
  • Erläutern Sie die geschäftliche Begründung für jedes Ziel.
  • Prüfen Sie mögliche Konflikte, wenn eine Anwendung Arbeitsabläufe mit unterschiedlichen Prioritäten unterstützt.

Prüfen Sie, ob die Ziele erreichbar sind

Ein Ziel ist nur dann sinnvoll, wenn die gewählte Bereitstellungs- und Wiederherstellungsumgebung es voraussichtlich unterstützen kann. Vergleichen Sie jedes Ziel mit den tatsächlichen Möglichkeiten, die Anwendung und ihre Daten wiederherzustellen. Berücksichtigen Sie Abhängigkeiten, die Zeit für Entscheidungen, den Zugriff auf den Wiederherstellungsprozess und den Aufwand zur Überprüfung des wiederhergestellten Dienstes.

Gehen Sie nicht davon aus, dass ein Sicherungsplan dasselbe wie ein RPO ist oder dass eine verfügbare Sicherung beweist, dass das RTO eingehalten werden kann. Das Unternehmen muss wissen, was die Wiederherstellung umfasst, wie die benötigten Daten und Dienste zurückgebracht werden und wie die Betriebsbereitschaft bestätigt wird.

Airbip verwaltet Bereitstellungen von Kataloganwendungen als Docker-Workloads auf seinen Cloud-Servern, automatisiert Routing und TLS-Zertifikate über Traefik und Let’s Encrypt und bietet DNS-Prüfungen, die Verwaltung des Dienstlebenszyklus sowie konfigurierbare tägliche, wöchentliche und monatliche Sicherungen. Diese Funktionen sind keine Zusage, dass ein bestimmtes RTO oder RPO erreicht wird. Prüfen Sie die aktuellen Servicedetails und die Wiederherstellungsanforderungen Ihrer konkreten Anwendung, bevor Sie entscheiden, ob die Lösung geeignet ist.

Wenn die vorgeschlagenen Ziele durch die vorhandenen Wiederherstellungsmaßnahmen nicht unterstützt werden können, überarbeiten Sie die Ziele, die geschäftliche Ausweichlösung oder den Bereitstellungsansatz. Bezeichnen Sie ein ungeprüftes Ziel nicht als Garantie.

  • Bestätigen Sie, welche Daten und Abhängigkeiten von den Wiederherstellungsmaßnahmen abgedeckt werden.
  • Prüfen Sie, wie die Wiederherstellung eingeleitet wird und wer Zugriff und Befugnis dazu hat.
  • Vergleichen Sie Sicherungszeitpunkte und Wiederherstellungsverfahren mit den RPO- und RTO-Zielen.
  • Ermitteln Sie Lücken, Annahmen und Entscheidungen, die überprüft werden müssen, bevor Sie sich auf die Ziele verlassen.

Machen Sie aus den Zielen einen verantworteten und getesteten Wiederherstellungsplan

Dokumentieren Sie mehr als nur RTO und RPO. In einem praktischen Plan ist festgehalten, wer über den Beginn der Wiederherstellung entscheidet, wer die einzelnen Schritte ausführt, wer die Nutzbarkeit der Anwendung überprüft und wer Mitarbeitende, Kunden oder Partner informiert.

Legen Sie klare Entscheidungspunkte fest: wie ein Vorfall erkannt wird, wer eine Störung ausrufen darf, wann eine Ausweichlösung verwendet werden soll und welche Prüfungen erforderlich sind, bevor die normale Arbeit wieder aufgenommen wird. Beschreiben Sie auch die Reihenfolge für die Wiederherstellung von Abhängigkeiten und den Umgang mit Arbeiten, die während der Unterbrechung entstanden sind.

Testen Sie den Plan und dokumentieren Sie die Ergebnisse. Ein Wiederherstellungsziel muss überprüft werden; es ist kein Beleg dafür, dass die Wiederherstellung das Ziel erreicht. Übungen können unklare Zuständigkeiten, fehlende Zugriffsrechte, übersehene Abhängigkeiten oder eine Lücke zwischen dem angegebenen Ziel und dem Wiederherstellungsprozess aufdecken.

Aktualisieren Sie die Ziele und Verfahren nach einem Test oder einer tatsächlichen Störung, falls nötig. Änderungen an Arbeitsabläufen, der Bedeutung von Daten, Integrationen oder Betriebsabläufen können einen älteren Wiederherstellungsplan unzutreffend machen.

  • Benennen Sie eine entscheidungsbefugte Person, Verantwortliche für die Wiederherstellung und Verantwortliche für die Kommunikation.
  • Formulieren Sie Wiederherstellungsschritte und die Reihenfolge der Abhängigkeiten so, dass Einsatzkräfte sie umsetzen können.
  • Legen Sie Prüfungen fest, anhand derer sich erkennen lässt, ob der Dienst und der Geschäftsablauf wieder nutzbar sind.
  • Testen Sie den Plan, dokumentieren Sie die Ergebnisse und verfolgen Sie offene Lücken.
  • Überprüfen Sie die Ziele, wenn sich Geschäftsprozesse oder Anwendungsabhängigkeiten ändern.

Häufige Fragen

Worin unterscheiden sich RTO und RPO?

Das RTO gibt an, wie lange eine Anwendung oder ein Prozess akzeptabel ausfallen kann. Das RPO bezeichnet das akzeptable Alter der wiederherstellbaren Daten und zeigt damit, wie viele der zuletzt erfassten Informationen das Unternehmen möglicherweise erneut erstellen muss oder verlieren kann.

Sollten alle Geschäftsanwendungen dasselbe RTO und RPO haben?

Nicht unbedingt. Legen Sie die Ziele anhand der geschäftlichen Auswirkungen und der Toleranz gegenüber Datenverlusten für die jeweilige Anwendung oder den Arbeitsablauf fest. Auch verschiedene Prozesse, die dieselbe Anwendung verwenden, können unterschiedliche Prioritäten haben.

Bedeutet eine tägliche Sicherung, dass das RPO einen Tag beträgt?

Nicht automatisch. Ein Sicherungsplan ist nicht dasselbe wie ein bestätigter Wiederherstellungspunkt. Prüfen Sie, welche Daten erfasst werden, wann sie für eine Wiederherstellung verfügbar sind, welche Daten und Abhängigkeiten enthalten sind und ob die Lösung zur geschäftlichen Toleranz passt.

Bedeutet ein festgelegtes RTO, dass die Wiederherstellung innerhalb dieser Zeit abgeschlossen wird?

Nein. Ein RTO ist ein Ziel, keine Garantie. Der Wiederherstellungsplan muss überprüft und getestet werden, damit das Unternehmen beurteilen kann, ob die vorhandenen Maßnahmen das Ziel unterstützen.

Was sollte ein Wiederherstellungsplan für Anwendungen außer RTO und RPO enthalten?

Nehmen Sie Zuständigkeiten, Entscheidungspunkte, Verfahren, Abhängigkeiten, Kommunikationswege, Bereitschaftsprüfungen und Tests auf. Legen Sie fest, wer die Wiederherstellung einleiten darf und wie das Unternehmen beurteilt, ob die Arbeit sicher wieder aufgenommen werden kann.

Quellen und weiterführende Literatur

  1. RPO vs. RTO: Key Differences Explained With Examples — TechTarget
  2. RTO vs RPO: how to set recovery objectives that match your business — Nexcess
  3. Aligning disaster recovery to company technical direction and objectives — Oracle
  4. Disaster Recovery Playbook — JFrog
  5. RTO vs RPO Explained: How to Set the Right Recovery Targets — Wavenet