Starnberg, 27. April 2015 - Geeignete Planungsgrößen zur Sicherstellung eines kontinuierlichen Geschäftsbetriebes aus Sicht der IT-Organisation (ITO)...
Um was es hier geht: Maßnahmen im Bereich des Disaster Recovery werden für geschäftskritische Applikationen wichtiger. 84 Prozent der im Rahmen einer im letzten Jahr veröffentlichten IDC-Studie (1) befragten Organisationen haben RPOs von unter einer Stunde und 78 Prozent RTOs von unter vier Stunden angegeben. Ungeplante Ausfallzeiten von Anwendungen verursachen laut einer weiteren Untersuchung jährliche Kosten in Höhe von 1,4 bis 2,3 Millionen US-Dollar durch verloren gegangene Umsätze, verringerte Produktivität und versäumte Chancen (2).
Recovery Time Objective (RTO) und Recovery Point Objective (RPO) stehen somit bei jeder Disaster Recovery (D/R), Datensicherungs-/Business Continuity Planung (B/C) im Mittelpunkt der Überlegungen; dies gilt für on-premise wie (hybrid) Cloud – Umgebungen. Auf den ersten Blick sind die Begriffe jedoch sehr ähnlich, so dass es sich lohnt, nochmals kurz darauf einzugehen:
RPO - Recovery Point Objective
- Definiert die Zeitspanne, die im Business Continuity Plan den gerade noch maximal zulässige Grenzwert darstellt. Beispiel: Wenn die letzte intakte Kopie von Daten 12 Stunden alt ist, während die RPO dafür 14 Stunden beträgt, dann entspricht der RPO-Parameter dem des Business Continuity Plans.
RTO - Recovery Time Objective
Die Recovery Time Objective (RTO) ist die Zeit die benötigt wird, um den Geschäftsprozess nach einem Ausfall im Rahmen der SLAs wieder zu unterstützen. Mit anderen Worten: die RTO ist die Antwort auf die Frage: "Wie viel Zeit steht zum Recovery nach einer Geschäftsprozessunterbrechung zur Problembeseitigung zur Verfügung?
RTO + RPO + detaillierte Analysen zum Einfluss von Ausfällen auf den Geschäftsbetrieb liefern eine fundierte Grundlage zum Aufbau einer praxistauglichen Strategie im Rahmen der Business Continuity-Planung.
Datenreplikation
Data Replication liefert aus RPO-Sicht effektivere Werte, denn das Zielsystem repräsentiert exakt das gespiegelte Image der Quelle. Der jeweilige RPO-Wert hängt davon ab, wie schnell die Änderungen übernommen werden können und ob asynchron oder synchron gespiegelt wird.
Entscheidend für RPO ist letztlich die Tatsache, wie schnell sich die Daten auf der Zielseite den jeweiligen Applikationen zur Verfügung stellen lassen.
Fazit: Es gibt in der Praxis wohl immer einen Unterschied zwischen den beschriebenen Zielen und den tatsächlich erreichten Werten, da je nach Komplexitätsgrad verschiedene manuelle bzw. automatisierte Prozesse, Organisationen & Systeme daran beteiligt sind (Personal, Dokumentation, Software). Deshalb ist ein möglichst regelmäßiger D/R-Test mit Simulation einer Unterbrechung mit entsprechender potentieller Auswirkung auf den Geschäftsbetrieb wichtig; liefert er doch reale Zahlen und Werte zur Optimierung der geplanten Ziele und Vorgaben.
(1) Mehr zum Thema RTO/RPO und RZ-Netzwerke finden Sie unter diesem Link...
(2) Veeam Studie zu den Kosten auf Grund mangelnder Datenverfügbarkeit