Das Recovery Time Objective (RTO) in der DR-Planung verstehen

Das Recovery Time Objective (RTO) in der DR-Planung verstehen

Das Festlegen Ihrer Ziele für die Wiederherstellungszeit ist entscheidend, insbesondere wenn Netzwerk-Hacks und Ransomware-Angriffe zunehmen. Man weiß nie, wann man das nächste Opfer ist. Wie würden Sie zu diesem Zeitpunkt einen Datensicherungs- und Wiederherstellungsplan erstellen, wenn Ihr Wiederherstellungszeitziel nicht definiert ist?

Dieser Beitrag führt Sie durch die Grundlagen von RTO und die Faktoren, die Sie beim Festlegen Ihres RTO berücksichtigen sollten.

Was ist das Erholungszeitziel?

Das Recovery Time Objective (RTO) ist definiert als die maximal akzeptable Zeitspanne, die eine Anwendung ausfallen kann, oder der maximal tolerierbare Ausfall, den das Unternehmen ertragen kann, ohne dem Unternehmen erheblichen Schaden zuzufügen, nachdem eine Katastrophe, ein Ausfall oder ein anderes inakzeptables Ereignis eintritt.

Die RTO-Zeit gibt die Zeit an, die für die Wiederherstellung und den Abschluss der Systemwiederherstellung eines ausgefallenen Systems benötigt wird, wie in der Service-Level-Vereinbarung definiert. Das Service-Level-Ziel berücksichtigt die Wiederherstellungszeit, die von der Organisation festgelegt wurde, um ihre unternehmenskritischen IT-Prozesse/-Operationen nach dem Eintreten einer Katastrophe wiederherzustellen/zu normalisieren, um die Geschäftskontinuität sicherzustellen.

Pro Tipp: Sie sollten immer darauf abzielen, die niedrigstmögliche RTO zu erreichen, um die Auswirkungen einer Katastrophe zu minimieren. Um Ihre RTO zu bestimmen, müssen Sie zunächst die Auswirkungen der Dauer auf Ihr Unternehmen ermitteln, in dem die Daten nicht verfügbar sind.

Beispielsweise:

  • Wenn 10 % der Daten innerhalb von 24 Stunden verfügbar sein müssen,
  • Und nach einem kompletten Verlust der Datenbank müssen 50% der Daten innerhalb von 2 Tagen verfügbar sein,
  • Die restlichen 40 % der Daten müssen innerhalb der nächsten 5 Tage verfügbar sein, dann

Ihre gesamte RTO beträgt = 8 Tage.

Um ein weiteres Beispiel zu nennen:

Angenommen, der Exchange-Server ist heruntergefahren. Wenn Ihre RTO bei 5 Stunden liegt, beträgt die maximal tolerierbare Ausfallzeit, die Ihr Unternehmen überstehen kann, 5 Stunden, und Ihre RTO für den Exchange Server muss weniger als 5 Stunden betragen. Ihre Notfallwiederherstellungsrichtlinie muss die notwendigen Schritte enthalten, die von der IT-Abteilung zum Sichern und Wiederherstellen der Daten unternommen werden.

Daher gibt es beim Festlegen des Ziels für die Zeit bis zur Wiederherstellung keine Einheitslösung für a Business Continuity Plan. RTOs können so eingestellt werden, dass Daten nach einem Notfall wiederhergestellt werden. Sollte jedoch ein Vorfall eintreten, hängt die praktische Umsetzung Ihres Disaster-Recovery-Plans auch von bestimmten Tools und Technologien ab, die für die Wiederherstellung eingesetzt werden. Die Fähigkeit, RTO zu erreichen, variiert also, da verschiedene Technologien und DR-Tools in ihren Fähigkeiten variieren. Die RTO wird bereits vor Beginn des Ausfalls gemessen und umfasst die Zeit, die für die Reparatur der Server, die Installation vorrangiger Anwendungen und die Wiederherstellung von Daten benötigt wird. Es enthält auch die Wiederherstellungsmethoden und die gesicherten Daten, die wiederhergestellt werden müssen.

Was bestimmt RTO?

Das Wiederherstellungszeitziel ist eine angestrebte Dauer, in der Anwendungen, Systeme und/oder Prozesse Ausfallzeiten überstehen und nicht funktionieren, bevor die Störung beginnt. Die RTO ist von größter Bedeutung, um die Zeitspanne für die Priorisierung von Anwendungen und Prozessen innerhalb der RTO-Parameter zu bestimmen. Im Datenschutzplan und in der Disaster-Recovery-Strategie beantwortet RTO die Frage: „Was ist die Zielzeit, die für die Wiederherstellung von Diensten nach einer Benachrichtigung über eine Dienstunterbrechung festgelegt wurde?“

RTOs können Folgendes bestimmen:

  • Die einzustellende Echtzeitdauer für die Wiederherstellung eines Standorts ab dem Zeitpunkt, an dem der Vorfall den normalen Betriebsablauf bis zur Wiederherstellung unterbricht
  • Welche IT-Vorbereitungen sollten für die Umsetzung des Disaster-Recovery-Plans getroffen werden?
  • Das akzeptable Risikoniveau für Datenverlust, wenn das System oder wichtige Anwendungen offline gehen.

Wie berechnet man die RTO für die Disaster-Recovery-Planung?

Eine RTO-Metrik legt die Zielerwartung für das IT-Team im Voraus fest, da sie den Schwellenwert bestimmt, wie schnell das System oder die Anwendung nach der Ausfallzeit wiederhergestellt werden kann und Ihr System wieder online bringt. Nachdem Sie diese Maßnahme in Bezug auf die Menge an „Echtzeit“ für die Wiederherstellung des Systems definiert haben, können Sie Ihre Wiederherstellungsstrategie planen, um den Dienst wieder betriebsbereit zu machen. Um die RTO zu berechnen, müssen Sie die Verluste berücksichtigen, die mit einer Unterbrechung des Wiederherstellungszeitziels (BCP) des Business Continuity Plans verbunden sind. Fügen Sie auch eine Auswirkungsanalyse hinzu, die die kurz- oder langfristigen Auswirkungen einer Betriebsunterbrechung von Diensten erläutert. Dazu gehören Risiken, Umsatzeinbußen, Ausgaben, kundenorientierte Anwendungen, unternehmenskritische Anwendungen und Anwendungen mit geringerer Priorität, die betroffen sind oder nicht mehr verfügbar sein werden. RTO befasst sich mehr mit den Ausfallzeiten und Zeitbeschränkungen für den Datenwiederherstellungsprozess.

Um eine RTO zu ermitteln, benötigen Sie möglicherweise mehrere RTO-Kategorien, da bestimmte Ausfälle möglicherweise nicht viel Wiederherstellungszeit benötigen, während andere möglicherweise andere langfristige Schutzlösungen erfordern. Beispielsweise kann die RTO für weniger geschäftskritische Anwendungen (die nicht häufig verwendet werden) viel länger sein. Je nach Komplexitätsgrad mehrerer in Betrieb befindlicher Sicherheitssysteme müssen Sie die RTO möglicherweise auf Backups in kurzen und langen Intervallen einstellen. Dies kann aufgrund eines Ransomware-Ereignisses oder eines anderen massiven Katastrophenvorfalls geschehen.

Bei der Berechnung der RTO zu berücksichtigende Hauptfaktoren

  • Kosten-Nutzen-Gleichung für Wiederherstellungslösungen
  • Bevorzugte Anwendungen einzelner Systeme und Daten
  • Schritte, die von der IT-Abteilung basierend auf den Prozessen, automatisierten Techniken oder Technologien zur Wiederherstellung der IT-Infrastruktur durchgeführt werden müssen
  • Ausfall- und Minderungskosten
  • Die Komplexität des Wiederherstellungsverfahrens 

RTO-Abtastintervalle

Das Erreichen einer RTO von nahezu Null ist für die meisten IT-Unternehmen kostspielig, aber es ist möglich, wenn Sie Anwendungen und Daten priorisieren. Bei weniger geschäftskritischen Anwendungen kann die RTO-Uhr längere objektive Zeiten als gewöhnlich verbrauchen. Bei RTO-Plänen von nahezu null für unternehmenskritische Anwendungen müssen Sie möglicherweise eine sofortige Failover-Fähigkeit in Betracht ziehen. 

Abhängig von der Schwere des Ausfalls können Sie die erreichbare Ziel-RTO-Zeit festlegen. Die RTO-Wiederherstellungszeit hängt jedoch auch von den Einschränkungen der IT-Organisation ab. Wenn beispielsweise die Wiederherstellung aller IT-Funktionen und -Operationen 3 Stunden dauert, muss die RTO mindestens 3 Stunden betragen.

Note: Aus der Perspektive der Notfallwiederherstellung (DR) beginnt die RTO-Uhr genau dann, wenn die Wiederherstellungsprozesse beginnen.

Berücksichtigen Sie bei der Berechnung des RTO (Recovery Time Objective) für Ihre Geschäftsbereiche die folgenden Beispielintervalle:

1 Stunden

Dieses Intervall dient der redundanten Datensicherung auf externen Festplatten.

5 Tage

In diesem Fall wäre die kostengünstigste Lösung die Datensicherung auf einer CD, einem Band oder einem externen Plattenspeicher.

Erreiche RTO, den Zmanda-Weg

Recovery Time Objective (RTO) und Wiederherstellungspunktziel (RPO) sind unglaublich wichtige Ziele und bilden die Grundlage eines Wiederherstellungsplans. Wie bestimmen Sie die Reihe von Schritten praktischer Wiederherstellungsziele? Hier können wir helfen!

Mit dem DRaaS-Plan und den benutzerdefinierten Service-Level-Vereinbarungen von Zmanda können wir Ihnen unabhängig von der Größe Ihres Unternehmens dabei helfen, Ausfallzeiten zu verkürzen und den Schmerz von Ausfallzeiten zu vermeiden, je nach Ihren Geschäftsanforderungen. Abgesehen von Hybrid-Backups zur Unterstützung des Übergangs und zum Erreichen relativ schnellerer RTOs kombiniert unsere Unternehmenslösung Amazon Glacier mit einer 20-mal niedrigeren Kosten für die Langzeitdatenarchivierung, die eine robuste Hochverfügbarkeit bietet und die Geschäftskontinuität gewährleistet. 

Unsere Enterprise-Backup-Lösung vereint Backup, Disaster Recovery und langfristige Speicherarchivierung, die speziell auf die Bedürfnisse der Kunden zugeschnitten sind. Dies bietet Sicherheit, Zuverlässigkeit, Skalierbarkeit und Verfügbarkeit bei der Wiederherstellung Ihrer Umgebung selbst bei einem Totalausfall des Servers.

Überzeugen Sie sich selbst! Beginnen wir mit a die kostenlose Testversion. um Ihre Datensicherung zu planen oder anzufordern a Demo. Haben Sie Fragen? Bitte wenden Sie sich an uns hier.


Entdecken Sie weitere Themen