Recovery Time Objective (RTO) und Recovery Point Objective (RPO) sind relevante Messgrößen. Sie helfen Unternehmen einen geeigneten Notfallwiederherstellungsplan zu entwickeln, um die Geschäftskontinuität nach einem unerwarteten Ereignis aufrecht zu erhalten. Mit Unterstützung der Metriken lassen sich die maximal tolerierbaren Stunden für eine Datenwiederherstellung bestimmen, Datensicherungszyklen einrichten sowie die Methoden für den Wiederherstellungsprozess definieren. RTO und RPO dienen derselben Sache, sie sind jedoch zwei unterschiedliche Kennzahlen. Erfahren Sie in diesem Artikel, wie Sie RTO und RPO erheben und richtig interpretieren.
Disaster Recovery (DR) und Business Continuity (BR)
Stellen Sie sich vor: Eine Schadware-Attacke setzt Ihre Unternehmenswebsite außer Gefecht. Oder ein Wasserschaden verursachte ein Kurzschluss mit anschließendem Stromausfall in Ihrem Serverraum. Außerdem ist das Backup der Datensicherung lückenhaft. Wie wirken sich solche Szenarien auf Ihr Unternehmen aus? Was bedeutet es, wenn Ihr SAP® für eine Stunde ausfällt? Oder für einen Tag? Oder sogar noch länger?
Der englische Begriff Disaster Recovery (frei übersetzt: Notfallwiederherstellungsplan) umfasst Maßnahmen, die nach einem Ausfall von Komponenten in der Informationstechnik eingeleitet werden. Dazu zählen Aktionen zur Datenwiederherstellung ebenso wie das Ersetzen zerstörter Infrastruktur oder Hardware. Weiter gefasst ist der Begriff der Business Continuity. Hierbei geht es um möglichst unterbrechungsfreie Geschäftsabläufe, nicht um die Wiederherstellung der „defekten“ Komponenten.
Nun können Unternehmen sich nicht gegen jede Eventualität absichern. Aber sie können einen Business-Continuity-Plan entwerfen, der ihren Bedürfnissen und Ansprüchen gerecht wird. Das Ziel, das im Mittelpunkt steht, lautet: Die Vermeidung von IT-Ausfällen, die schlimmstenfalls zum Ruin eines Unternehmens führen würden. Die Eckdaten für einen solchen Business-Continuity-Plan liefern die individuellen Toleranzgrenzen für Ausfallzeiten. Deren Bestimmung gelingt mittels der Analyse von Recovery Time Objective (RTO) und Recovery Point Objective (RPO).
Was ist ein Recovery Time Objective (RTO)?
Wie lange kann es sich ein Unternehmen leisten, dass ein für den Geschäftsprozess relevantes System ausfällt? Die Wiederherstellungszeit (RTO) wird in Minuten, Stunden oder Tagen gemessen. Dabei gilt die Regel: Je kürzer, desto besser. Beträgt eine RTO zum Beispiel 24 Stunden, ist das Management überzeugt, dass der Ausfall des Betriebs für einen kompletten Tag zu verkraften ist. Erst nach spätestens 24 Stunden würde das Unternehmen einen irreparablen Schaden erleiden.
Was ist ein Recovery Point Objective (RPO)?
Wie groß ist der maximale Datenverlust, den ein Unternehmen verkraften kann, wenn ein wichtiges IT-System ausfällt? Der Wiederherstellungspunkt (RPO) bestimmt die maximale Datenmenge, die in einem Katastrophenszenario verloren gehen darf. Da Bits und Bytes nichts über die Qualität von Daten aussagen, wird diese Messgröße in Zeiteinheiten gefasst – und zwar nach der Häufigkeit, mit der Backups durchgeführt werden. Hier gilt: Je kleiner, desto besser. Je geringer der Zeitraum ist, der zwischen zwei Datensicherungen liegt, desto geringer ist der Datenverlust. Ist überhaupt kein Datenverlust tolerierbar, liegt ein RPO bei null Sekunden. Unternehmen, die ihre Daten zum Beispiel einmal täglich um Mitternacht sichern, müssten theoretisch einen RPO von 24 Stunden zugrunde legen. Denn sie können – würden die Systeme um fünf vor Zwölf zerstört – Daten im Wert von 24 Stunden verlieren. Kann ein Unternehmen jedoch maximal acht Stunden verkraften, sollte es schnellstmöglich die Sicherungszyklen verkürzen.
Der Unterschied zwischen RTO und RPO einfach erklärt
Die tatsächliche Wiederherstellungszeit (RTA) bestimmen
Schließlich definieren Disaster-Recovery- oder Business-Continuity-Pläne auch die RTA, die tatsächliche Wiederherstellungszeit (Recovery Time Actual): Diese Kennzahl charakterisiert Zeit und Methodik, die zur Wiederherstellung von IT-Systemen nach einem Notfall benötigt werden. Der tatsächliche RTA wird häufig mittels einer Notfall- oder Wiederherstellungsübung ermittelt. Ähnlich einer Feuerwehrübung testen IT-Experten an simulierten Umgebungen, wie lange es mit welchen Maßnahmen dauert, schadhafte Systemumgebungen wiederherzustellen oder verlorengegangene Daten zu rekonstruieren. Die RTA ist ebenfalls eine Zeiteinheit. Auch hier gilt: Je kürzer, desto besser.
Adacor Cloud Adoption Framework
Mit dem Cloud Adoption Framework brechen wir IT-Projekte in überschaubare Arbeitspakete auf.
Mehr als 50 Tools, Vorlagen und geführte Workshops
In 5 Min verschafft Ihnen Adacor CEO Andreas Bachmann mit seinem Video einen Überblick
Individuelle Analysen sind erforderlich
Beim Aushandeln von Hosting-Rahmenverträgen – Service Level Agreements (SLA) – spielen die Kennzahlen RTO und RPO für Adacor eine wichtige Rolle. Diese Metriken lassen sich aber nicht „mal eben“ aus einem Businessplan oder aus einer Datenanalyse extrahieren. Sie müssen individuell aus den Anforderungen des jeweiligen Kundenunternehmens abgeleitet werden.
RTO bezieht sich dabei auf die allgemeinen Geschäftsanforderungen. Und RTO ist nicht gleich RTO! Die Kennziffer ist stark abhängig vom Schadensereignis. Wie ist ein Serverabsturz zu verkraften? Welche Auswirkungen hat es, wenn eine Festplatte „crasht“? Wie geht man mit einem lückenhaften Backup um? Und welche Schadensereignisse sind wahrscheinlich? Für einen Onlineversandhändler hat ein Serverausfall des Websystems in der Vorweihnachtszeit eine andere Bedeutung als für eine Unternehmensstiftung, die ihre Website nur für Image- und Repräsentationszwecke nutzt. Hier wird deutlich: RTO bezieht sich auf das Geschäftsmodell und auf die gesamte Unternehmensinfrastruktur, nicht nur auf die gespeicherten Daten. Die Bestimmung des RTO ist relativ kompliziert, da alle IT-Vorgänge in den Fokus rücken.
Zur Bestimmung des RPO müssen Unternehmen sich ihre Daten – die Mengen, die Strukturen und die Qualitäten – genau anschauen. Welche Daten sollten wie oft gesichert werden? Dies zu beurteilen ist weniger kompliziert als die Bestimmung des RTO. Zur Erreichung von RPO-Zielen reicht die Durchführung der Datensicherungen im richtigen Intervall. Aus diesem Grund lassen sich Maßnahmen zur Erreichung der RPO-Ziele sehr gut automatisieren.
So geht Adacor bei SLAs und Business-Continuity-Strategie vor
Bei Adacor unterstützen wir unsere Kunden bei der Ermittlung von Kennzahlen wie RTO. Zusätzlich beraten wir Sie im Hinblick darauf, welche Sicherungsmaßnahmen sich aus den Metriken ableiten lassen. Dabei rückt in den Blick, welche Maßnahmen sinnvoll und wirtschaftlich tragbar sind. Sicher! Der Idealwert für RTO und RPO liegt bei Null: keine Ausfallzeit und kein Datenverlust. Dies technisch zu realisieren – zum Beispiel durch die mehrfache Spiegelung aller Anwendungen auf Großrechnern in verschiedenen Rechenzentren – wäre jedoch unfassbar teuer und wirtschaftlich nur in den seltensten Fällen tragbar. Das ist auch nicht notwendig, da nicht alle Daten und Abläufe in einem Unternehmen gleichermaßen sensibel sind.
Wir berücksichtigt beim Aushandeln von SLA und dem Entwurf einer sinnvollen Business-Continuity-Strategie folgende Punkte:
- Welche Desaster-Szenarien sind wahrscheinlich (zum Beispiel Hackerangriffe, Elementarschäden durch Feuer, Wasser oder Sturm, der Verlust von Systemen oder Daten durch Diebstahl oder Anwenderfehler)?
- Für welche Bereiche macht das Vorhalten von Ersatzhardware oder eine garantiert vereinbarte Lieferzeit für Ersatzgeräte Sinn?
- Welche Backup-Strategien und -Zyklen müssen erstellt, eingerichtet und überwacht werden?
- Lässt sich die Wiederherstellungszeit einer vollständigen Datensicherung optimieren? Wann wurde das letzte Mal das IT-System für den Worst Case auf die Probe gestellt?
- Hat ein Unternehmen Übergangsszenarien entwickelt, mit denen sich die Zeit bis zur vollständigen Wiederherstellung des Urzustandes überbrücken lässt?
- Ist sich das Unternehmen über Prioritäten im Klaren? Welche Dienste, Abteilungen oder Anwender müssen als erste nach einem Ausfall wieder an den Start gehen?
Fazit: RTO und RPO individuell bestimmen
Um einen IT-Wiederherstellungsplan zu erstellen, der das Überleben eines Unternehmens im Notfall gewährleistet, und der zudem kostengünstig ist, ist es am besten RTO als auch RPO zu bestimmen. Dies kann nur individuell auf das jeweilige Unternehmen abgestimmt geschehen: Es gibt keine „Faustformel“ für die Festlegung der Metriken. Zudem sollten RTO und RPO in regelmäßigen Abständen auf den Prüfstand kommen. Gemeinsam mit einem Managed Service Provider oder qualifizierten IT-Sicherheitsexperten können Unternehmen einen strukturierten Reaktionsplan entwerfen, der im Fall eines ungeplanten Vorfalls abgerufen werden kann. Überdimensionierte Investitionen in die RTO- und RPO-Absicherung lassen sich vermeiden, wenn nicht Angst oder übertriebenes Sicherheitsbedürfnis, sondern eine realistische Einschätzung von Risiken und Toleranzgrenzen das Management leiten. Denn in der IT gilt das Gleiche wie im „echten“ Leben: Hundertprozentige Sicherheit gibt es nicht.
Sie möchten mehr Informationen zum Thema Business Continuity?
Dann lesen Sie weitere spannende Artikel in unserem Blog!