skip to Main Content

Was sind RTO und RPOIn der Technologie passieren Dinge manchmal einfach so. Und inwiefern sich dies auf uns auswirkt, hängt ebenso damit zusammen, wie wir uns auf das Unvermeidliche vorbereitet haben, wie mit dem, was wir getan haben, um Ausfallzeiten zu vermeiden. Was passiert also, wenn die Lichter ausgehen? Stellen Sie sich vor, was passiert, wenn Ihre Unternehmenssysteme ausfallen. Und ich würde behaupten, dass dies eher eine Frage der Zeit als der Wahrscheinlichkeit ist. Welche Auswirkungen hat es auf Ihr Unternehmen, wenn Ihr SAP für eine Stunde ausfällt? Einen Tag? Länger? Was als Nächstes passiert, hängt wahrscheinlich von Ihrem Business-Continuity-Plan (BC-Plan) ab. Und der Kern Ihres BC-Plans hängt von Ihrer Toleranz für Ausfallzeiten ab und daraus ergibt sich die Frage, was RTO und RPO sind.

Was ist ein RTO?

Wir haben dies bereits zuvor besprochen, aber es lohnt sich, noch ein bisschen genauer darauf einzugehen. RTO steht für „Recovery Time Objective“ (Wiederherstellungszeitziel). Das RTO ist die Zeit, die Sie bereit sind, zu warten, bis Ihre Sicherungssysteme online sind. RTOs sind in der Geschäftswelt sehr unterschiedlich. Bei nicht kritischen Systemen können RTOs in Stunden oder sogar Tagen bemessen werden. Bei Kernsystemen können RTOs eine Frage von Sekunden sein.

Das RTO hängt davon ab, wie dringend Sie die Wiederherstellung des Systems benötigen. Im Fall von SAP ERP möchten die meisten Unternehmen, dass Systeme relativ schnell auf Sicherungsinstanzen umgestellt werden. Es kommt jedoch auf den Geschäftsbereich an. Wenn Ihr Unternehmen alle drei Wochen Container verschickt, wird ein 15-minütiges RTO Ihren Betrieb wahrscheinlich nicht sehr belasten. Die Mitarbeiter können einfach eine Kaffeepause einlegen, während die IT-Abteilung die SAP-Backup-Landschaft in Schwung bringt.

Schnellere und transaktionsintensivere Unternehmen erfordern im Allgemeinen kürzere RTOs. Die extremsten Beispiele finden sich im Finanzbereich, wo Sekunden zählen. Ein Aktienhandel oder eine Überweisung, die durch einen Ausfall verzögert wird, kann eine kostspielige Angelegenheit sein. Dies kann sich auch auf den Ruf der betreffenden Firma auswirken.

Was ist ein RPO?

Das RPO ist das „Recovery Point Objective“ (Wiederherstellungspunktziel). Es gibt den gewünschten Zeitpunkt und Zustand an, bis zu dem die Wiederherstellung erfolgen soll, wenn Sie Ihre Backup-Systeme starten. Nehmen wir zur Veranschaulichung an, Herr Schmidt kauft um 11:00 Uhr ein Produkt von Ihnen und Herr Müller kauft um 11:01 Uhr ein Produkt. Ihr SAP-System zeichnet die Transaktionen zu den jeweiligen Zeitpunkten auf. Stellen Sie sich vor, Sie haben um 11:02 Uhr einen Ausfall. Wie weit soll die Wiederherstellung reichen? Möchten Sie die Transaktion von Herrn Müller von vor einer Minute oder von Herrn Schmidt von vor zwei Minuten wiederherstellen können? Ihr RPO bestimmt, wie weit die Wiederherstellung zurückreicht, d. h bis zu welchem Zeitpunkt Sie alles wiederherstellen möchten.

Warum RTO und RPO für die Business Continuity von Bedeutung sind

RTO und RPO sind wichtige Elemente jedes BC-Plans. Sie sind die spezifischen Kennzahlen, die Backup und Wiederherstellung, Verfügbarkeit und Failover-Prozess betreffen. Und wie Sie sich vorstellen können, sind die Implementierungskosten umso höher, je schneller das RTO und je kürzer das RPO ist. Wenn Sie beispielsweise ein RTO in Sekunden messen möchten, müssen Sie Ihre Architektur entsprechend aufbauen. Eine gebräuchliche Methode wird als „Mirror-Standort“ bezeichnet.

Ein Mirror-Standort ist eine identische Kopie Ihrer vorhandenen SAP-Landschaft, die an einem separaten (hoffentlich sicheren) Ort ausgeführt wird. Wenn Sie in New York sind, könnte sich Ihr „Mirror“ (Spiegel) in Arizona befinden. Sie können Ihre SAP-Landschaft so konfigurieren, dass innerhalb von Sekunden ein Failover an den Mirror-Standort erfolgt, und Transaktionen so innerhalb des definierten RTO weiterlaufen.

Mirror-Standorte sind teuer, weil sie eine zweifache Herausforderung darstellen. Sie müssen sie in perfekter Abstimmung mit dem Primärsystem ausführen. Das stellt eine operative Aufgabe dar. Schlimmer ist jedoch, dass Sie die beiden Systeme administrativ exakt parallel halten müssen. Wenn Sie eine Software in einem System aktualisieren, müssen Sie die andere aktualisieren und so weiter. Dabei handelt es sich um einen zeit- und ressourcenintensiven Prozess.

Weniger kostspielige, langsamere RTOs umfassen möglicherweise „warme“ Backup-Sites, die zusammen mit der Wiederherstellung von Datenbank-Backups, die regelmäßig in regelmäßigen Abständen repliziert wurden, neu gestartet werden müssen. Wenn Sie beispielsweise jede Stunde replizieren, ist Ihr RPO bis zu einer Stunde lang. Noch günstiger sind „kalte Sites“, an denen Sie Ihre SAP-Landschaft von Grund auf installieren müssen. Das kann Tage dauern. Abhängig von Ihrem Geschäft spielt dies jedoch möglicherweise keine Rolle.

Bewährte DR-Vorgehensweisen

Es gibt nützliche Kenntnisse zu bewährten Vorgehensweisen, die Sie auf Ihre DR-Anforderungen anwenden können. Lernen Sie von den bewährten Vorgehensweisen (und Fehlern) Anderer. Im Folgenden sehen Sie eine allgemeine Übersicht. Für weitere Einzelheiten empfehlen wir die Disaster Recovery Planning-Arbeitsmappe.

DR-Prioritäten mithilfe eines risikobasierten Ansatzes zuweisen

Die meisten unserer Kunden verfolgen einen mehrstufigen Ansatz für RTO und RPO. Für ihre kritischsten Systeme investieren sie in schnelle RTOs und kurze RPOs. Für weniger wichtige Systeme, wie zum Beispiel Dateispeicherdatenträger, rechnen sie mit einer kostengünstigeren, aber langsameren RTO. Die Frage, die sich natürlich stellt, ist, welche Vermögenswerte und Bedrohungen die höchsten DR-Investitionen verdienen und welche nicht.

Ein risikobasierter Ansatz ermöglicht es Ihnen, die Auswirkungen von Bedrohungen zu quantifizieren und DR entsprechend zu planen. Es besteht ein gewisses Maß an Subjektivität, aber es ermöglicht Ihnen, zwischen der Wahrscheinlichkeit und den Auswirkungen von weniger schweren bzw. schwerwiegenderen Katastrophenszenarien zu unterscheiden. Hier finden Sie eine vereinfachte Version des Prozesses. Gehen Sie für jeden digitalen Vermögenswert, z. B. Ihr SAP ERP, E-Mail-System usw. wie folgt vor:

  • Identifizieren Sie die Bedrohung und Dinge, die den Geschäftsbetrieb stören können, wie Naturkatastrophen und Cyberangriffe.
  • Schätzen Sie die Wahrscheinlichkeit der Katastrophe ab, z. B. indem Sie die Wahrscheinlichkeit der Bedrohung mit einem Wert zwischen 0 und 1 ausdrücken.
  • Schätzen Sie die Auswirkungen ab, indem Sie eine Bewertung zwischen 0 und 1 vergeben, die angibt, wie stark die Bedrohung/das Ereignis Ihren Geschäftsbetrieb beeinflussen würde.
  • Weisen Sie eine Risikobewertung zu, den Wert, der durch Multiplizieren der Wahrscheinlichkeit mit der Auswirkung der jeweiligen Bedrohung abgeleitet wird.

Wie die folgende Tabelle zeigt, haben verschiedene Systeme unterschiedliche Risikoeinstufungen, basierend auf den Auswirkungen eines Ausfalls. Je höher die Risikoeinstufung, desto höher ist die Notwendigkeit eines hohen RTO.

Bedrohung Betroffenes System Wahrscheinlichkeit Auswirkung Risikobewertung Auswirkungen für RTO/RPO
Hurrikan SAP-Landschaft 0.1 0.9 0.09 Am schnellsten
Hurrikan E-Mail-Server 0.1 0.7 0.07 Schnell

 

Auswahl geeigneter DR-Technologien

Nach der Auswertung der Risikobewertungen müssen Technologien oder Werkzeuge ausgewählt werden, mit denen RTO, RPO und andere Aspekte des DR-Plans erreicht werden können. Es stehen viele Auswahlmöglichkeiten zur Verfügung. Dazu gehören die SAP Hypervisor-Replikation, sekundäre Backups des Rechenzentrums, Datenbankreplikation, Speicherreplikation usw. Jede Technologielösung für DR hat ihre Vor- und Nachteile. Ein erfahrener DR-Partner kann Ihnen dabei helfen, die optimale Vorgehensweise aus betrieblicher Kontinuität und aus Kostensicht zu ermitteln.

Disaster-Recovery-as-a-Service (DRaaS) in Erwägung ziehen

DR ist u. U. so komplex, dass es sinnvoll sein kann, es an einen Anbieter auszulagern, der das Ganze als Service ausführen kann. Wir können in dieser Hinsicht helfen. Unser Disaster-Recovery-as-a-Service ist nur ein Teil einer umfassenden Cloud- und IT-Infrastruktur-Lösung. Wir arbeiten mit unseren Partnern zusammen, um Ressourcen zuzuweisen, basierend auf:

  • RTO und RPO
  • aktuellen Computeranforderungen
  • zukünftigem Wachstum
  • speziellen Projekten

Eine erschwingliche Monatsrate gibt Ihnen Zugriff auf die Ressourcen, die Sie verwenden. Gleichzeitig profitieren Sie von der Skalierbarkeit von DRaaS in unserer verwalteten Cloud. Im Notfall können Sie schnell eine Wiederherstellung und Skalierung durchführen, die vorgegebenen RTOs und RPOs entspricht. Dies gewährleistet die Geschäftskontinuität ohne die Kosten für Investitionen in die DR-Infrastruktur.