Wie viel Downtime kann ein Unternehmen verkraften? RTO, RPO & Co. helfen Unternehmen beim Disaster Recovery

Anbieter zum Thema

Arvato Systems

Cohesity GmbH

Rubrik Germany GmbH

Adacor Hosting GmbH

Nur das nicht! Ausfälle der IT-Infrastruktur. Zwar laufen die meisten Systeme heute stabil, trotz alledem können jederzeit Ereignisse auftreten, die zu Hardware-Ausfällen oder Datenverlusten führen: Eine Schadsoftware wie „Emotet“, ein banaler Kurzschluss, ein lückenhaftes Backup oder der Ausfall eines SAP-Systems können schnell Compliance-Probleme bereiten oder ganze Organisationen lahmlegen.

Dabei ist jedem IT-Verantwortlichen klar, dass mit begrenztem Budget kein hundertprozentiger Schutz gegen alle Eventualitäten möglich ist. Das optimale Sicherheitskonzept ist immer ein Kompromiss, jedes Unternehmen muss dabei für sich entscheiden, wie viel Sicherheit es sich leisten will oder kann. Wichtige Parameter bei der Bestimmung sind die Kennzahlen Recovery Time Objective (RTO) und Recovery Point Objective (RPO).

Disaster Recovery versus Business Continuity

RTO und RPO dienen Unternehmen dazu, einen Notfallplan zur Wiederherstellung des Betriebs nach einem unerwarteten Schadensfall (Disaster Recovery) zu entwickeln und die Geschäftskontinuität (Business Continuity) aufrecht zu erhalten. Disaster Recovery umfasst Maßnahmen, die nach einem Ausfall von Komponenten eingeleitet werden, beispielsweise Aktionen zur Datenwiederherstellung oder das Ersetzen zerstörter Infrastruktur oder Hardware.

Die Beherrschbarkeit von Störfällen

Was ist Recovery Time Objective (RTO)?

Business Continuity geht darüber hinaus. Ziel sind hierbei möglichst unterbrechungsfreie Geschäftsabläufe, nicht die reine Wiederherstellung defekter Komponenten. Ein Business-Continuity-Plan dient vor allem der Vermeidung von IT-Ausfällen, die zum Ruin eines Unternehmens führen würden. Die Eckdaten dafür liefern die individuellen Toleranzgrenzen für Ausfallzeiten, die anhand einer Analyse von RTO und RPO festgelegt werden. Auf diese Weise lassen sich die maximal tolerierbaren Stunden für eine Datenwiederherstellung bestimmen, Datensicherungszyklen einrichten sowie Methoden für den Wiederherstellungsprozess definieren.

Auf Nummer sicher

Was ist Recovery Point Objective (RPO)?

Beide Kennzahlen ähneln sich, sind aber so etwas wie zwei Seiten einer Medaille. Die Recovery Time Objective misst, wie lange es sich ein Unternehmen leisten kann, dass ein für den Geschäftsprozess relevantes System ausfällt. Je kürzer diese Zeit ist, desto höher die benötigte Sicherheit. Bei einem RTO von 24 Stunden geht das Management davon aus, dass der Ausfall des Betriebs für einen kompletten Tag zu verkraften ist. Nach spätestens 24 Stunden würde das Unternehmen aber einen irreparablen Schaden erleiden.

Demgegenüber misst das Recovery Point Objective, welchen maximalen Datenverlust 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 auch diese Messgröße in Zeiteinheiten gefasst – und zwar nach der Häufigkeit, mit der Backups durchgeführt werden.

Hier gilt: Je geringer der Zeitraum zwischen zwei Datensicherungen, desto geringer ist der Datenverlust. Ist überhaupt kein Datenverlust tolerierbar, liegt der RPO bei null Sekunden. Unternehmen, die ihre Daten zum Beispiel einmal täglich um Mitternacht sichern, müssten theoretisch einen RPO von 24 Stunden akzeptieren. Sie könnten – würden die Systeme um fünf vor Zwölf zerstört – Daten im Wert von 24 Stunden verlieren. Kann ein Unternehmen jedoch nur maximal acht Stunden verkraften, muss es die Abstände zwischen den Sicherungszyklen entsprechend verkürzen.

Jedes Unternehmen hat andere Sicherheitsanforderungen

Gesetzt den Fall, RTO und RPO sind definiert, kommt im Ernstfall eine weitere Kennzahl zum Tragen, die tatsächliche Wiederherstellungszeit (Recovery Time Actual oder kurz RTA). RTA charakterisiert Zeit und Methodik, die zur Wiederherstellung von IT-Systemen nach einem Notfall benötigt werden. Dieser Wert lässt sich nicht ohne Weiteres berechnen, daher wird er für Disaster-Recovery- oder Business-Continuity-Pläne in der Regel mittels einer Notfall- oder Wiederherstellungsübung ermittelt. Ähnlich einer Feuerwehrübung testen IT-Experten an simulierten Umgebungen, wie lange es mit den definierten Maßnahmen dauert, schadhafte Systemumgebungen wiederherzustellen oder verlorengegangene Daten zu rekonstruieren. Je kürzer der RTA, desto besser.

Beim Aushandeln von Service Level Agreements (SLA) spielen RTO und RPO eine wichtige Rolle. Diese Metriken lassen sich aber nicht „on the fly“ aus einem Business-Plan oder einer Datenanalyse extrahieren, sondern müssen individuell aus den Anforderungen des jeweiligen Unternehmens abgeleitet werden.

RTO beispielsweise ist stark abhängig vom Schadensereignis und der Wahrscheinlichkeit des Eintretens. Für einen Online-Shop hat ein Serverausfall des Web-Systems in der Vorweihnachtszeit sicherlich eine andere Bedeutung als für eine Unternehmensstiftung, die ihre Website vorwiegend für Image- und Repräsentationszwecke nutzt. Es bezieht sich auf das Geschäftsmodell und auf die gesamte Unternehmensinfrastruktur, nicht nur auf die gespeicherten Daten. Die Definition ist relativ kompliziert, da alle IT-Vorgänge berücksichtigt werden müssen.

Wo hoch ist die Verfügbarkeit insgesamt?

Übrigens: die Verfügbarkeit und etwaige Ausfallzeiten in Clouds oder Infrastrukturen lassen sich einfach berechnen. Ein kleines Tool dafür, das zudem auch die Gesamtverfügbarkeit einer Elementkette berechnet, finden Sie auf der Adacor-Webseite.

Zur Bestimmung des RPO wiederum müssen Unternehmen sich ihre Daten – die Mengen, die Strukturen und die Qualitäten – genau anschauen. Welche Daten wie oft gesichert werden sollten, ist weniger kompliziert einzuschätzen als die Bestimmung des RTO. Zur Erreichung von RPO-Zielen reicht die Durchführung der Datensicherungen im richtigen Intervall. Entsprechende Maßnahmen lassen sich auch sehr gut automatisieren.

Richtig gesetzte SLAs und Business Continuity Strategie

Unabhängig davon, wie RTO, RPO und RTA aussehen, gilt es, SLAs auszuhandeln und eine Business-Continuity-Strategie zu entwickeln. Dabei sollten folgende Punkte Berücksichtigung finden:

• Was für Desaster-Szenarien sind wirklich wahrscheinlich (Anwenderfehler, Hacker-Angriffe, Elementarschäden, Diebstahl, Pandemien, sonstiges)?

• Ernstfall proben, denn wann wurde das IT-System das letzte Mal für einen Worst Case auf die Probe gestellt?

• In welchen Bereichen sollte Ersatzhardware vorgehalten werden – gerade Corona hat aufgezeigt, dass Ersatzlieferungen auch für längere Zeit ausfallen können

• Aufbau und Einhalten einer regelmäßigen Backup-Strategie

• Praktischer Test eines kompletten Restore (viele Firmen sichern nur, testen aber nie den umgekehrten Fall)

• Gibt es Übergangsszenarien, mit denen sich die Zeit bis zur vollständigen Wiederherstellung des Urzustandes überbrücken lässt?

• Prioritätenliste aufsetzen: Welche Dienste, Abteilungen oder Anwender müssen als erste nach einem Ausfall wieder an den Start gehen?

Hundertprozentige Sicherheit gibt es nicht

Bei der Planung sollte immer realistisch überlegt werden, welche Maßnahmen sinnvoll und wirtschaftlich tragbar sind. Im Idealfall liegen RTO und RPO bei Null, es gibt also keine Ausfallzeit und keinen Datenverlust. Dies wäre technisch durchaus zu realisieren – zum Beispiel durch die mehrfache Spiegelung aller Anwendungen auf Großrechnern in verschiedenen Rechenzentren – jedoch unfassbar teuer. Und auch nicht notwendig, weil in der Regel nicht alle Daten und Abläufe in einem Unternehmen gleichermaßen kritisch sind. Es gibt keine „Faustregel“ für die Festlegung der Metriken, aber es ist sicher ratsam, RTO und RPO in regelmäßigen Abständen auf den Prüfstand zu stellen.

Gemeinsam mit ihrem 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.

* Der Autor

Andreas Bachmann ist Mitgründer und CEO von Adacor Hosting. Er verantwortet unter anderem die Bereiche Software-Entwicklung, Marketing, Datenschutz und Compliance. In seinen Beiträgen beschäftigt er sich mit Datensicherheit und IT-Security. Weitere Schwerpunkte sind wichtige Methoden strategischer Managementführung und die Erfahrungen bei der Umsetzung damit einhergehender Prozessanpassungen.

(ID:46640048)