Disaster Recovery: RTO und RPO ohne Fachjargon

Zwei Fragen, die am Anfang stehen müssen

Ein Gespräch darüber, wie ein Unternehmen gegen Ausfälle abgesichert werden soll, beginnt fast immer bei den Werkzeugen. Jemand fragt nach Software für Datensicherungen, jemand anderes nach einem Speichersystem oder der Cloud. Das ist die falsche Reihenfolge. Ohne zwei geschäftliche Entscheidungen lässt sich weder beurteilen, ob ein Werkzeug überhaupt das richtige ist, noch wie viel es kosten sollte.

Es lohnt sich, von Anfang an drei Dinge voneinander zu trennen, die in Gesprächen meist miteinander vermischt werden. Eine Datensicherung ist eine Kopie der Daten. Sie hilft, wenn eine Datei gelöscht wurde oder ein Datenträger ausgefallen ist. Disaster Recovery bedeutet, den Betrieb nach dem Verlust der gesamten Umgebung wiederaufzunehmen, etwa nach einem Brand, einer Überschwemmung oder einem Angriff, bei dem die Server verschlüsselt wurden. Ein Business-Continuity-Plan ist noch umfassender, denn er beschreibt auch, wie das Unternehmen arbeitet, solange die Systeme noch nicht wieder verfügbar sind.

Diese Entscheidungen beantworten zwei Fragen. Wie viele Stunden kann das Unternehmen ohne ein bestimmtes System auskommen, und wie viel der zuletzt geleisteten Arbeit darf verloren gehen? Die erste Zahl heißt RTO, die zweite RPO. Die Abkürzungen klingen technisch, doch die Antworten kennt nicht der Administrator. Sie kommen von der Person, die weiß, was im Unternehmen geschieht, wenn keine Bestellungen mehr eingehen.

Erst aus diesen beiden Zahlen ergibt sich alles Weitere: wie oft Datensicherungen erstellt werden müssen, wo sie aufbewahrt werden, ob eine Ausweichumgebung erforderlich ist und welches Budget dafür sinnvoll ist. Wer in umgekehrter Reihenfolge vorgeht, erhält entweder eine teure Lösung, die die Erwartungen trotzdem nicht erfüllt, oder eine günstige Lösung, von der alle annehmen, dass sie ausreicht.

RTO oder wie viele Stunden das Unternehmen ohne ein System auskommt

RTO steht für Recovery Time Objective. Das US-amerikanische NIST beschreibt den Begriff in seinem Leitfaden zur Notfallplanung als die Zeit, die ein System in der Wiederherstellungsphase verbringen kann, bevor der Betrieb der Organisation beeinträchtigt wird. Vereinfacht gesagt bezeichnet RTO die Zahl der Stunden, die ein bestimmtes System ausfallen darf und die das Unternehmen noch verkraften kann.

Der häufigste Fehler besteht darin, eine einzige Zahl für das gesamte Unternehmen zu suchen. Das RTO wird für jedes System separat festgelegt. Ein Geschäft kann ohne sein Verkaufssystem überhaupt nicht arbeiten. Ein Archiv mit Dokumenten aus früheren Jahren kann zwei Tage lang nicht verfügbar sein, ohne dass es jemand bemerkt. Beide Fälle dürfen nicht auf dieselbe Weise abgesichert werden, weil das bei einem davon Geldverschwendung wäre.

Die zweite Falle besteht darin, nur die eigentliche Wiederherstellung zu zählen. Das RTO beginnt nicht erst, wenn jemand die Wiederherstellung startet. Es beginnt im Moment des Ausfalls und umfasst alle Schritte bis zur Rückkehr: das Erkennen des Problems, die Entscheidung zur Aktivierung des Plans, den Zugang zur Hardware, die Wiederherstellung, die Prüfung der Daten und die Rückkehr der Mitarbeitenden an ihre Arbeitsplätze. Wenn am Wochenende niemand Rufbereitschaft hat, muss auch die Zeit bis Montag in das RTO eingerechnet werden.

Man muss außerdem berücksichtigen, dass kein System für sich allein arbeitet. Eine Anwendung benötigt eine Datenbank, Authentifizierung und das Netzwerk, häufig auch den Datenaustausch mit der Buchhaltung oder dem Lager. Das RTO umfasst diese gesamte Kette. Maßgeblich ist daher die Wiederherstellungszeit des schwächsten Glieds, nicht die Zeit für die Wiederherstellung der Anwendung allein.

RPO oder wie viel Arbeit verloren gehen darf

RPO steht für Recovery Point Objective. NIST definiert es als den Zeitpunkt, bis zu dem Daten nach einem Ausfall wiederhergestellt werden müssen. In der Praxis beantwortet das eine Frage. Wie weit wird das Unternehmen nach einem Ausfall in die Vergangenheit zurückversetzt?

Eine Uhr macht es am deutlichsten. Wird einmal täglich um zwei Uhr nachts eine Datensicherung erstellt und fällt der Server um sechzehn Uhr aus, gehen vierzehn Arbeitsstunden verloren. Dabei geht es nicht um abstrakte Daten. Es geht um die an diesem Tag eingegangenen Bestellungen, die ausgestellten Rechnungen, die Notizen aus Kundentelefonaten und die Änderungen an Dateien, an denen das gesamte Team gearbeitet hat.

Ein Teil dieser Arbeit lässt sich aus dem Gedächtnis und anhand von Papierunterlagen rekonstruieren. Ein anderer Teil ist endgültig verloren, weil sich niemand daran erinnert, was ein Kunde am Telefon genau gesagt hat. Deshalb sollte das RPO gemeinsam mit den Personen festgelegt werden, die die Daten eingeben, und nicht nur mit der Geschäftsleitung. Sie wissen, wie lange es dauert, die Arbeit eines ganzen Tages erneut einzugeben.

Das RPO unterscheidet sich ebenso wie das RTO von System zu System. Die Bestelldatenbank und der Ordner mit Fotos vom Firmenpicknick benötigen keine Datensicherungen in derselben Häufigkeit.

Ein einfaches Beispiel, das die Kosten sichtbar macht

Nehmen wir ein Unternehmen, das Bestellungen über ein eigenes System entgegennimmt. Zwanzig Personen arbeiten damit. Jede Bestellung führt zu einem Versand und einer Rechnung. Die Geschäftsleitung legt ein RPO von einer Stunde und ein RTO von vier Stunden fest. Sehen wir uns an, was daraus folgt.

Aus dem RPO ergeben sich die Häufigkeit und die Art der Datensicherung. Eine tägliche Datensicherung erfüllt diese Vorgabe nicht, da dabei die Daten eines ganzen Tages verloren gehen können. Eine stündliche Datensicherung erfordert ein anderes Verfahren für die Datenbank, mehr Speicherplatz und eine stärkere Auslastung der Verbindung, wenn die Daten das Unternehmen verlassen. Verkürzt man den Abstand auf wenige Minuten, ist meist bereits Replikation erforderlich. Dabei wird eine zweite Kopie des Systems laufend aktuell gehalten. Jede dieser drei Varianten verursacht andere Kosten und erfordert einen anderen Aufwand für den laufenden Betrieb.

Das RTO bestimmt, auf welcher Infrastruktur das System mit diesen Daten wieder gestartet wird. Vier Stunden reichen nicht, um auf die Lieferung eines Servers zu warten und das System von Grund auf neu zu installieren. Deshalb muss eine Umgebung bereitstehen, in der das System gestartet werden kann. Das können freie Kapazitäten auf dem bestehenden Hypervisor, eine Ersatzmaschine oder eine vorab vorbereitete Cloud-Umgebung sein. Das ist der Teil der Kosten, an den meist niemand denkt, weil er mit Datensicherung in Verbindung gebracht wird. Tatsächlich geht es dabei um ganz gewöhnliche Kosten für Hardware und Platz.

Ändert sich eine dieser Zahlen, ändern sich auch die Lösung und der Preis. Bei einem RTO von einem Tag kann die Wiederherstellung auf neuer Hardware in Ruhe erfolgen. Ein RTO von einer Stunde erfordert fast immer eine zweite Umgebung, die zur Übernahme des Betriebs bereitsteht. Die ehrliche Frage lautet daher nicht, welche Lösung die beste ist, sondern welche Zahl das Unternehmen tatsächlich benötigt.

Der häufigste Fehler ist ein RTO ohne Kostenrechnung

Auf die Frage, wie viel Zeit bis zur Wiederherstellung eines Systems vergehen darf, antworten fast alle, dass es sofort wieder verfügbar sein müsse. Das ist verständlich, aber vollkommen unbrauchbar, denn sofort ist die teuerste Antwort überhaupt. Sinnvoller ist es, zunächst eines zu berechnen. Was kostet eine Stunde Stillstand das Unternehmen?

In diese Berechnung fließen mehrere Posten ein:

• die Anzahl der Personen, die in dieser Zeit nicht arbeiten können, sowie ihre Kosten pro Stunde
• was in dieser Zeit weder verkauft noch aus dem Lager versandt noch in Rechnung gestellt werden kann
• die Arbeit, die später nachgeholt werden muss, einschließlich der Überstunden
• die in dieser Zeit versäumten Fristen und die dadurch anfallenden Vertragsstrafen
• die Kosten für Gespräche mit Kunden, denen mitgeteilt wurde, dass das System ausgefallen ist

Das Ergebnis muss nicht exakt sein. Eine belastbare Schätzung reicht aus, um sie den Kosten der Lösung gegenüberzustellen. Das ist der Zweck einer Business-Impact-Analyse. NIST beschreibt sie als Untersuchung der betrieblichen Funktionen und der Auswirkungen, die eine Unterbrechung auf sie haben könnte.

Oft gibt es auch eine Überraschung in die andere Richtung. Bei manchen Systemen zeigt die Berechnung, dass das Unternehmen zwei Tage Stillstand ohne größeren Schaden verkraftet. Das ist eine sehr gute Nachricht, denn dadurch wird Geld für das eine System frei, das innerhalb einer Stunde wieder verfügbar sein muss.

Eine Datensicherung ist noch kein Business-Continuity-Plan

Eine Datensicherung ist eine Kopie der Daten. Ein Business-Continuity-Plan ist die Fähigkeit, nach einem Ausfall weiterzuarbeiten. Der Unterschied besteht in mehreren Punkten, die eine Software für Datensicherungen allein nicht abdeckt.

Zu den Datensicherungen müssen mindestens folgende Punkte hinzukommen:

• eine Umgebung, auf der die Daten überhaupt bereitgestellt werden können, also freie Ressourcen, Ersatzhardware oder vorbereitete Kapazitäten in der Cloud
• die Reihenfolge, in der die Dienste wiederhergestellt werden, denn eine Anwendung, die vor der Datenbank und der Authentifizierung wiederhergestellt wird, startet schlicht nicht
• die beteiligten Personen und ein Verfahren, das festlegt, wer den Ausfall feststellt, wer die Entscheidung trifft und wer wen anruft
• Konnektivität und Fernzugriff, wenn die Beschäftigten von einem anderen Ort als gewöhnlich arbeiten sollen
• einen Test, also eine probeweise Wiederherstellung mit Zeitmessung und nicht nur einen Bericht darüber, dass eine Datensicherung durchgeführt wurde

Diese Liste ist nicht frei erfunden. Der NIST-Leitfaden zur Notfallplanung setzt einen Plan aus genau solchen Elementen zusammen: von der Business-Impact-Analyse über die Wahl eines Ausweichstandorts und die Aufteilung der Verantwortlichkeiten bis hin zu Tests und zur Schulung der Personen, die den Plan umsetzen sollen.

Der letzte Punkt ist der wichtigste und wird am häufigsten übergangen. Eine Datensicherung, die nie wiederhergestellt wurde, bleibt nur eine Annahme. Nur eine probeweise Wiederherstellung zeigt, wie lange sie tatsächlich dauert. Dabei treten Lücken am leichtesten zutage, die kein Bericht über eine durchgeführte Datensicherung erkennen lässt, etwa die Abhängigkeit von einem anderen System oder ein Passwort, an das sich niemand mehr erinnert.

Wie Sie prüfen, ob der Plan wirklich existiert

Einige Fragen zeigen schnell, wie die Lage aussieht. Sie können sie der eigenen IT-Abteilung oder dem Unternehmen stellen, das die Infrastruktur betreut:

• wann zuletzt Daten aus einer Datensicherung wiederhergestellt wurden und wie lange es gedauert hat
• worauf sie wiederhergestellt wurden, denn eine Datei auf denselben Server zurückzuspielen, belegt nichts
• welche RTO- und RPO-Werte für jedes betriebsnotwendige System gelten
• ob es eine Datensicherung gibt, auf die aus dem Unternehmensnetzwerk nicht zugegriffen werden kann
• wer an einem Sonntag um fünf Uhr morgens entscheidet, den Plan zu aktivieren

Wenn die Antworten lauten, dass die Datensicherungen durchgeführt und überwacht werden, hat das Unternehmen eine Datensicherung. Einen Plan hat es noch nicht. Das ist kein Vorwurf, sondern lediglich eine Information darüber, wie viel Arbeit noch zu erledigen ist.

Bei C4PL führen wir Wiederherstellungstests tatsächlich durch und beschränken uns nicht auf die Einrichtung und den Betrieb der Datensicherungen. Den Umfang des Supports, einschließlich der Rufbereitschaft rund um die Uhr, legen wir im Vertrag fest, denn davon hängt ab, welches RTO nachts und am Wochenende realistisch ist.

Womit Sie beginnen

Am Anfang stehen nicht die Werkzeuge. Zuerst entsteht eine Liste der Systeme, ohne die das Unternehmen nicht arbeiten kann. Sie ist meist kürzer als gedacht. Für jedes System werden zwei Zahlen und ein Satz dazu notiert, was geschieht, wenn es ausfällt.

Für das Ausfüllen einer solchen Tabelle ist kein Audit erforderlich. Ein einziges Gespräch mit den Verantwortlichen für Vertrieb, Produktion, Lager und Buchhaltung genügt. Der technische Teil beginnt erst danach und ist dann deutlich einfacher, weil klar ist, welche Anforderungen erfüllt werden müssen.

Sind beide Zahlen festgelegt, sollten sie schriftlich festgehalten werden. Solange RTO und RPO nur im Gespräch bestehen, bleiben sie ein Wunsch. Werden sie in den Vertrag mit dem Unternehmen aufgenommen, das die Infrastruktur betreibt, werden sie zur Verpflichtung. Erst dann lassen sich Reaktionszeit und Umfang der Rufbereitschaft darauf abstimmen.

Wenn Sie dies mit jemandem durchgehen möchten, der Wiederherstellungstests in der Praxis durchführt, rufen Sie unter +48 662 036 615 an oder schreiben Sie an [email protected]. Ein Gespräch über diese beiden Zahlen dauert eine Viertelstunde und zeigt meist sofort, wo die größte Lücke besteht.

IT-Service ansehen