Was ist ein Recovery Point Objective (RPO)?
Neben dem Recovery Time Objective (RTO), ist das Recovery Point Objective (RPO) eines der wichtigsten Tools für die Erstellung eines Notfallwiederherstellungsplans oder eines Plans zur Datensicherung. Es ist auch ein Tool, das Unternehmen bei der Auswahl eines Datensicherungsplans hilft, der ihren Anforderungen entspricht.
RPO und RTO bilden die Basis für die Festlegung und Unterscheidung starker Einbeziehungsstrategien für den Business Continuity Plan. Diese Strategien ermöglichen eine rasche Wiederaufnahme der Geschäftsprozesse innerhalb eines Zeitrahmens, der dem RPO und RTO entspricht oder diesem nahe kommt.1
Obwohl beide in die Festlegung der Notfallwiederherstellung eingebunden sind, muss ein RPO unabhängig von einem RTO oder der geschätzten Mindestzeit für die Wiederherstellung des regulären Betriebs nach einem System- oder Netzwerkausfall bleiben.
Wie das RTO hilft auch das RPO bei der Festlegung von Wiederherstellungsrichtlinien und -verfahren. Das RPO hilft den Administratoren bei der Auswahl der besten Backup- und Wiederherstellungstechnologien, die je nach der Gesamtstrategie eingesetzt werden sollten, damit ein Datenverlust das RTO nicht verzögert.
Wie unterscheidet sich ein RPO von einem RTO?
Sowohl RPOs als auch RTOs sind Konzepte, die zur Unterstützung der Geschäftskontinuität verwendet werden. Sie eignen sich auch als Metriken für Ihr Unternehmen und können Ihnen helfen zu berechnen, wie oft Ihr Unternehmen Backups von Daten durchführen sollte.
RPOs und RTOs sind von entscheidender Bedeutung für den Disaster Recovery Plan oder den Data Protection Plan eines Unternehmens. Beide hängen mit der Analyse der Auswirkungen auf das Geschäft zusammen. Hierbei handelt es sich um einen systematischen Prozess, der dazu beitragen kann, kritische und dringende unternehmensspezifische Funktionen und Aktivitäten von nicht kritischen und nicht dringenden zu trennen. Funktionen können als kritisch angesehen werden, wenn sie gesetzlich vorgeschrieben sind.
RPO und RTO sind die beiden Werte, die für jede Funktion zugewiesen werden. Das RPO bestimmt, wie viele Daten nach einer Unterbrechung wiederhergestellt werden können. Das RTO bestimmt, wie lange es dauert, bis ein System nach einer Unterbrechung wieder normal funktioniert.
Wie wird ein RPO berechnet?
RPOs werden zeitlich zurückgerechnet. Sie reichen vom Zeitpunkt der Störung bis zum letzten Backup-Punkt, an dem die Daten noch nutzbar sind. Sie können auch ermitteln, wie oft Sie regelmäßig Backups Ihrer Daten erstellen sollten.
Die RPOs werden in der Regel in Minuten oder Stunden berechnet. Je nach Dringlichkeit können sie aber auch in Sekunden oder Tagen berechnet werden. Ein RPO legt fest, wie weit in den Datenverlauf für Backup-Speicherung zurückgesprungen werden muss, um den normalen Betrieb wieder aufzunehmen, nachdem ein Computer, ein System oder ein Netz durch einen Hardware-, Programm- oder Kommunikationsfehler unterbrochen wurde.2
Ein RPO kann auch als die maximal akzeptable Menge an Datenverlusten angesehen werden, die in Zeit gemessen wird. Außerdem kann es beschreiben, wie viel Zeit während eines Ausfalls verstreicht, bevor die Datenmenge, die dabei verloren geht, die maximal zulässige „Toleranz“ oder den Schwellenwert des Business Continuity Plan überschreitet.
Wenn ein Computersystem beispielsweise ein RPO von 30 Minuten aufweist, bedeutet das, dass das maximale Zeitfenster für einen Datenverlust nach einem Ausfall 30 Minuten beträgt. Aus diesem Grund muss alle 30 Minuten ein Backup des Systems durchgeführt werden.
Wann sollten Sie Datensicherungen für ein RPO planen?
RPOs sind oft einfacher zu erreichen als RTOs. Der Grund dafür ist, dass die Datenverwendung nur wenige Variablen enthält und in der Regel konsistent ist. Aber auch das Gegenteil kann der Fall sein, denn die Berechnung der Wiederherstellungszeiten basiert in der Regel auf dem gesamten Betrieb und nicht nur auf den Daten.
Der Zeitpunkt des Ausfalls ist ebenfalls ein Faktor für die Wiederherstellungszeit. Bei der Erstellung Ihres Backup-Zeitplans sollten Sie berücksichtigen, zu welchen Zeiten Ihr Unternehmen am meisten und am wenigsten beschäftigt ist. Hier ist ein Beispiel: Wenn Sie um 3 Uhr morgens Eastern Standard Time eine Störung haben und die IT-Abteilung die Störung bis 5 Uhr morgens behebt, haben Sie dann Daten im Wert von zwei Stunden verloren? Wenn dieser Zeitrahmen eine Zeit mit geringem Geschäftsverkehr für Ihr Unternehmen ist, dann wahrscheinlich nicht.
Nehmen wir als weiteres Beispiel an, dass Ihr Unternehmen seine Daten alle 10 Stunden sichert. Mittags tritt ein Ausfall auf, der schnell behoben ist, und um 12.30 Uhr läuft Ihr Geschäftsbetrieb wieder wie gewohnt. Da der Datenverlust nur ein 30-minütiges Zeitfenster von 12 Uhr bis 12:30 Uhr betraf, müssen Sie nicht alle Daten der letzten 10 Stunden wiederherstellen. Sie müssen nur die Daten der verlorenen 30 Minuten wiederherstellen.
Disaster Recovery und Disaster Recovery-Pläne
Diese Pläne sind nicht zu verwechseln mit Emergency Management und Disaster Response. Bei Disaster Recovery geht es um die IT-Infrastruktur und die Systeme zur Unterstützung wichtiger Geschäftsprozesse. Disaster Recovery ist ein Teilbereich der Business Continuity, die darauf abzielt, alle wichtigen Aspekte eines Unternehmens trotz eines Ausfalls aufrechtzuerhalten.
Disaster Recovery umfasst die Richtlinien, Tools und Verfahren, die für die Wiederherstellung oder Fortführung kritischer technologischer Infrastrukturen und Systeme nach einer natürlichen oder vom Menschen verursachten Katastrophe erforderlich sind.
Ein Disaster Recovery Plan (DRP) ist ein Prozess oder eine Reihe von Prozessen, der/die dazu beitragen, die IT-Infrastruktur und -Systeme eines Unternehmens nach einer Katastrophe wiederherzustellen und zu schützen.3 Dieser Prozess kann auf die Zeit vor und während eines Katastrophenfalls ausgeweitet werden.4
Ressourcen
- Jaspreet Singh. Understanding RPO and RTO, Druva, September 2019
- Recovery Point Objective (RPO), Techopedia, 11. November 2011
- Bill Abraham 5 Tips to Build an Effective Disaster Recovery Plan, Small Business Computing, 14. Juni 2012
- Geoffrey H. Wold Disaster Recovery Planning Process, Disaster Recovery Journal, adaptiert aus Band 5 #1. Disaster Recovery World Archiviert vom Original am 15. August 2012