Recovery Time Objective (RTO)
Recovery Time Objective (RTO) lässt sich auch als Wiederherstellungszeit-Vorgabe bezeichnen und ist die maximal tolerierbare Zeitspanne, die ein Computer, ein System, ein Netz, eine Infrastruktur oder eine Anwendung nach einem Störfall oder einer Katastrophe ausfallen kann.
RTO ist eine Funktion des Ausmaßes, in dem die Unterbrechung den normalen Betrieb stört, und der Höhe des Umsatzes, der pro Zeiteinheit aufgrund der Katastrophe verloren geht. Diese Faktoren hängen wiederum von den betroffenen Geräten und Anwendungen ab.
Ein RTO wird in Sekunden, Minuten, Stunden oder Tagen gemessen. Es ist ein wichtiger Faktor in einem Disaster-Recovery-Plan (DRP).
Sobald eine Organisation das RTO für eine Anwendung definiert hat, können Administratoren entscheiden, welche Disaster Recovery (DR)-Technologien für die jeweilige Situation am besten geeignet sind. Beträgt das RTO für eine bestimmte Anwendung beispielsweise eine Stunde, kann eine redundante Datensicherung auf externen Laufwerken die beste Lösung sein. Liegt das RTO bei fünf Tagen, ist eine Bandsicherung oder eine externer Cloud-Speichermöglicherweise praktischer.
In zahlreichen Studien wurde versucht, die Kosten von Ausfallzeiten für verschiedene Anwendungen im Unternehmensbetrieb zu ermitteln. Aus diesen Studien geht hervor, dass die Kosten sowohl von langfristigen und immateriellen Auswirkungen als auch von unmittelbaren, kurzfristigen und greifbaren Faktoren abhängen.
Wie berechnet man die RTO?
Die Berechnung des RTO ist ein mehrstufiger Prozess, der aus verschiedenen Blickwinkeln betrachtet werden muss, darunter die Business Impact Analysis (BIA), die DR-Strategie und die Planung der Business Continuity (BC). Das Hauptziel des RTO ist die Bestimmung der Zeitspanne, die in einem Wiederherstellungsprozess nach einem größeren Vorfall benötigt wird, um den normalen Geschäftsbetrieb wieder aufzunehmen.
Der erste Schritt im RTO-Prozess ist die vollständige Inventarisierung aller Systeme, geschäftskritischen Anwendungen, virtuellen Umgebungen und Daten. Ohne eine genaue Bestandsaufnahme ist es nicht möglich, ein RTO genau zu bestimmen.
Nach Abschluss der Bestandsaufnahme ist der nächste Schritt die Bewertung des Wertes jedes Dienstes und jeder geschäftskritischen Anwendung im Hinblick darauf, wie sehr sie zum Betrieb und zur Abwicklung der Geschäfte eines Unternehmens beitragen. Dieser Wert sollte auf der Grundlage der Zeitdauer und auf einer möglichst granularen Ebene bestimmt werden. Der Wert der Anwendung kann auch mit bestehenden Service-Level-Vereinbarungen verknüpft werden, in denen festgelegt ist, wie verfügbar ein Dienst sein muss, und die möglicherweise Strafen für den Fall vorsehen, dass diese Service-Level nicht eingehalten werden.
Wenn man weiß, was in Betrieb ist, und wie hoch der Wert aller laufenden Systeme und Anwendungen ist, kann man das RTO berechnen. Beachten Sie jedoch, dass es unterschiedliche RTO-Anforderungen geben kann, die auf der Anwendungspriorität basieren, die durch den Wert der Anwendung für das Unternehmen bestimmt wird.
Bei der Berechnung des RTO muss ermittelt werden, wie schnell der Wiederherstellungsprozess für eine bestimmte Anwendung, einen bestimmten Dienst, ein bestimmtes System oder bestimmte Daten nach einem schwerwiegenden Vorfall ablaufen muss, und zwar auf der Grundlage der Verlusttoleranz, die das Unternehmen für diese Anwendung, diesen Dienst, dieses System oder diese Daten im Rahmen seiner BIA festgelegt hat. Bei der Definition der Verlusttoleranz geht es darum, wie viel Betriebszeit eine Organisation nach einem Vorfall verlieren kann (oder bereit ist zu verlieren), bevor der normale Geschäftsbetrieb wieder aufgenommen werden muss.
Beispiele für RTO
Auf der Grundlage der BIA für einen Anwendungs- oder Serviceausfall kann das Ziel für das RTO variabel sein. So haben geschäftskritische Anwendungen ein niedrigeres RTO, während weniger kritische Dienste oft ein höheres RTO aufweisen, da die Dauer eines Ausfalls - und die damit verbundene Verlusttoleranz - höher ist.
Hier sind einige RTO-Beispiele:
- Transaktions-/Finanzdienste. Diese gehören zu den kritischsten Diensten, bei denen das RTO so nahe wie möglich bei Null liegt (während das RTO in anderen Bereichen bis zu mehrere Stunden betragen kann).
- E-Mail. E-Mail ist zwar für viele ein kritischer Dienst, kann aber eine RTO von bis zu vier Stunden für die Wiederherstellung haben. E-Mail-Ausfälle stehen nicht immer in direktem Zusammenhang mit Umsatzeinbußen, wie dies bei Ausfällen von Finanzdiensten der Fall ist.
- Der Ausfall eines Druckers ist eine Unannehmlichkeit, die zu finanziellen Verlusten führen kann. Diese Verluste sind wahrscheinlich deutlich geringer als bei einem Ausfall von Finanzdiensten oder sogar bei einer Unterbrechung der E-Mail-Kommunikation. In einigen Fällen kann das RTO für Druckserver bis zu 24 Stunden betragen.
RTO bei der DR-Planung
Die Festlegung des RTO ist eine wichtige Komponente eines DRP, da das Ziel des Disaster Recovery darin besteht, eine Strategie zu entwickeln, die dem Unternehmen hilft, sich zu erholen und den normalen Geschäftsbetrieb wiederherzustellen. Mit einer RTO als oberstem Ziel kann ein Unternehmen seine Datensicherungs- und Failover-Richtlinien abstimmen und das erforderliche Maß an zusätzlichen Services für die Bereitstellung verfügbar machen, um sicherzustellen, dass die gewünschte Wiederherstellungsgeschwindigkeit tatsächlich erreicht werden kann.
Ohne ein RTO weiß ein Unternehmen nicht, wie schnell die Wiederherstellung nach einem größeren Vorfall oder Datenverlust erfolgen kann. Bei der Disaster-Recovery-Planung geht es darum, auf unerwartete Ausfälle vorbereitet zu sein, und um vorbereitet zu sein, muss man eine Vorstellung davon haben - oder einen Plan - um zu wissen, wie lange die Wiederherstellung dauern wird.
Als Teil des Disaster-Recovery-Planungsprozesses sollten Organisationen über einen klaren Business-Continuity-Plan verfügen, in dem das Unternehmen eine Reihe von Zielen definiert hat. Diese Ziele sollten die RTO und das so genannte Recovery Point Objective (RPO) umfassen, um eine erwartete Wiederherstellungsrate zu gewährleisten.
RTO vs. RPO: Was ist der Unterschied?
Recovery Time Objective und Recovery Point Objective sind zwar beides Kernkomponenten der DR- und BC-Planung, dienen jedoch jeweils einem anderen Zweck.
- Beim Recovery Time Objective geht es darum, Richtlinien und Technologien einzusetzen, die es einem Unternehmen ermöglichen, seine Prozesse innerhalb einer bestimmten Zeitspanne wiederherzustellen.
- Beim Recovery Point hingegen geht es darum, im Vorfeld sicherzustellen, dass die Datenwiederherstellungs- und Backup-Funktionen vorhanden sind, um die Datenmenge zu minimieren, die bei einem Zwischenfall verloren gehen könnte.
RTO und RPO arbeiten zusammen, um ein Unternehmen wieder in den normalen Geschäftsbetrieb zurückzuführen. Sie definieren die Auswirkungen auf den Geschäftsbetrieb: Ersteres die Zeit, die für die Wiederherstellung der Dienste benötigt wird, und Zweiteres die maximal akzeptablen Menge an verlorenen Daten.
