Ein Backup hilft Ihnen fast gar nichts

Der heutige Beitrag richtet sich eher an die Geschäftsführung. Es geht um Geschäftsprozesse und nicht um Technik. Was ist Ihr erster Gedanke bei einem Ausfall Ihrer IT? Lautet der vielleicht

Haben wir ein aktuelles Backup?

Ist das bei Ihnen auch so? Dann sieht es vermutlich gar nicht gut bei Ihnen aus. Denn kein Mensch braucht ein Backup. Warum vermute ich, das es nicht so richtig gut bei Ihnen aussieht?

Alleine die Tatsache, dass Sie die Frage nach dem Backup stellen, lässt mich vermuten, dass Sie eine Reihe von Folgefragen noch nicht bearbeitet haben. Die nächsten Schritte in einer solchen kritischen Situation sind aller Wahrscheinlichkeit nach nicht zu Ende geplant. In besten Fall haben Sie einen Baustein in der Hand. Die Frage sollte lauten.

Bis wann haben wir das Backup vom geforderten Zeitpunkt in der notwendigen Zeit wieder eingespielt?

Jemand, der die zweite Frage stellt weiß, dass für den betroffenen Zweig der IT ein Plan erstellt worden ist und ist sich sicher das dieser aufgrund durchgeführter Tests auch funktionieren wird. Dieser Mensch ist eher wie ein Trainer. Er prüft ob die trainierte Zeit für eine Leistung auch eingehalten wird. Was Sie also brauchen, ist ein funktionierenden und erprobten Wiederherstellungsprozess.

Was müssen wir also für Fragen stellen, um in diesen Zustand der Gelassenheit zu kommen? Die notwendigen Fragen haben auch wenig mit Technologie, sondern mit Aspekten der Unternehmensführung zu tun. Sie drehen sich vor allem um die Begriffe Recovery Point Objective (RPO) und die Recovery Time Objective (RTO).

Die wichtigste Frage für ein katastrophales Ereignis ist:

Welche Datenmenge dürften verloren gehen?

Grob gesagt entspricht dies der Anzahl der Betriebsstunden, deren Daten sie zur Not wieder manuell restaurieren könnten oder für die sie keine vertragliche Verpflichtung eingegangen sind.

Wenn eine Organisation jeden Tag ein vollständiges Backup durchführt, beträgt ihr Ziel für den Datenwiederherstellungspunkt etwa 24 Stunden. Im Extremfall haben sie also 24 Stunden Arbeit verloren. Können Sie sich das für alle ihre Anwendungen leisten? Oder sollten das nicht eher für die unterschiedlichen Anwendungen und Dienste spezifisch festgelegt werden. In den meisten Fällen ist der nämlich nicht für alle Anwendungen gleich.

Lange Zeit war dieser RPO Wert der entscheidende Faktor. Organisationen waren es gewohnt, dass ihre Computersysteme im Notfall nicht funktionierten. Man hat sich einfach durch gewurstelt, bis die Systeme wieder in Betrieb waren. Dies ist für fast alle Unternehmen oder Organisationen heute nicht mehr realistisch. Wenn IT-Systeme ausfallen, wird der Arbeitsablauf der Organisation in der Regel vollständig gestoppt. Es ist wichtig, diese Auswirkungen aus geschäftlicher Sicht zu verstehen.

Zu der Frage, welche Daten verloren gehen können, ist daher festzulegen, wie lange die unterschiedlichen IT-Systeme und Daten nicht verfügbar sein dürfen.

Dies wird als Recovery Time Objective (RTO) bezeichnet.

Die Recovery Time Objective (RTO) ist die Zeit, die es dauert, bis Ihre Geschäftsprozesse nach einer Katastrophe wiederhergestellt werden sollten. Mit anderen Worten, RTO ist die Antwort auf die Frage:

Wie lange dauert es, bis wir uns von einer Störung erholt haben?

Nehmen wir ein Beispiel. Sie sichern täglich die Daten auf einen Cloudspeicher. Das ist kein Problem, wenn sie nachts sichern. Über die Jahre haben Sie zweistellige Terrabyte an Daten im Backup. Wie lange würde es dauern, diese Datenmengen wieder aus der Cloud auf die lokalen Server zu ziehen? Schaft Ihre Internetanbindung das in der geforderten Zeit?

Betrachten wir diese beiden Werte jetzt in einem realen Szenario.

Ein kleines Ingenieurbüro hat nur einen Server auf dem alle laufenden Arbeiten gespeichert werden. Auf dem Server werden auch Messdaten von Baustellen gespeichert. Aus gesetzlichen und vertraglichen Anforderungen könnte sich daraus ein RPO von 5 Minuten ergeben. Mehr als 5 Minuten Daten dürfen nicht verloren werden. Was passiert, wenn der Festplattenconroller in diesem Server ausfällt? Nehmen wir an, dass die Festplatten selbst nicht beschädigt sind, aber das Dateisystem ist korrupt. Wir haben also ein defektes Bauteil und verlorene Daten.  Realistischerweise wird unser Unternehmen mindestens einen ganzen Arbeitstag benötigen, um den defekten Kontroller zu diagnostizieren, zu erwerben und zu installieren. Aber nur, wenn es gut läuft. Das kann auch deutlich länger dauern.

Da in diesem Büro aber die Daten von Menschen überwacht werden, um in Alarmfällen sofortige Reaktionen anstoßen zu können, kann man auch nicht Stunden oder Tage warten bis die neue Hardware bereitgestellt und das Backup restauriert wird.

Und dann betrachten wir die Kosten. Wenn Sie die durchschnittlichen Lohnkosten Ihre Mitarbeiter nehmen, die für einige Tage nicht produktiv sein können, dann kommen da schnell einige Tausend Euro zusammen. Nicht nur das, das Unternehmen verlor auch potenzielle Einnahmen und beschädigte seinen Ruf und sein Image. Das Geld könne Sie auch besser in eine getestete Umgebung für den Notfall investieren.

Wie müsste also eine Lösung aussehen? Der lokale Server erstellt alle 5 Minuten Snapshots, die auf einen Server in der Cloud repliziert werden. Im Fall der Fälle wird im DNS die Adresse des Servers geändert und der Cloud Server aktiviert. Vielleicht ist der Server in der Cloud etwas kleiner dimensioniert und die das Arbeiten dauert etwas länger, aber ein schnelles Weiterarbeiten des Ingenieurbüros ist möglich. So ein Setup ist durch die Nutzung von Opensource Technologien wie dem ZFS Filesystem kostenlos verfügbar und bereits in Terabyte großen Umgebungen erprobt. Und das ganze dauert dann weniger als eine Stunde.

Bei Ihren Vorbereitungen auf einen Ransomwareangriff oder den notwendigen Desasterrecovery Planungen gilt es also aus den Anforderungen des Geschäfts die Anforderungen an den akzeptablen Datenverlust festzulegen. Daraus wird dann die erforderliche Wiederherstellungszeit abzuleiten. Dann lassen sie akzeptable Kosten festlegen und die notwendige technologische Plattform einrichten.

Damit sie im Fall der Fälle nicht unvorbereitet da stehen.