Reicht im Notfall ein Backup in der Cloud?

Das zentrale Element eines IT-Notfallplans waren früher die Backup-Bänder, die in regelmäßigen Abständen in ein Bankschließfach oder an einen anderen sicheren Ort gebracht wurden. In nicht wenigen Firmen wird diese Tradition auch noch heute gepflegt. Wer es sich leisten konnte, hatte für den Notfall nicht nur Backups, sondern auch Backup-Systeme in einem anderen Rechenzentrum, die nach einem größeren Ausfall der Produktivsysteme den Betrieb übernehmen konnten. Je nach Betriebsbereitschaft unterscheidet man drei Typen von Backup-Standorten:

Hot Site
Alles was man braucht ist im Backup-Rechenzentrum bereits vorhanden und jederzeit betriebsbereit. Die Daten werden kontinuierlich repliziert, so dass der Ersatzstandort bei Bedarf innerhalb weniger Stunden oder noch schneller produktiv sein kann.

Warm Site
Hier sind Hardware und Netzwerk vorhanden, aber in einem ausgeschalteten, nicht direkt betriebsbereiten Zustand. Im Notfall müssen erst die Backups eingespielt und der Ersatzstandort fertig konfiguriert werden. Das kann je nach Anzahl der Systeme und Größe der Backup-Dateien einige Tage dauern.

Cold Site
Diese Variante beinhaltet kaum mehr als die Garantie, an einem alternativen Standort seine Ersatzsysteme aufbauen und betreiben zu können. In einem Notfall müssen Hard- und Software erst am Backup-Standort installiert bzw. von einem Provider bereitgestellt werden. Anschließend werden die Daten und Anwendungen aus den Backups rekonstruiert und die Netzwerkverbindungen konfiguriert.

In Zeiten von Virtualisierung und Cloud Computing haben sich auch die Möglichkeiten für Backup und Disaster Recovery verändert. Mit imagebasierten Backups werden nicht nur die Daten, sondern die virtuellen Maschinen in einer einzigen Datei gesichert. Bei Bedarf kann dann das komplette System mit allen Konfigurationen, Anwendungen und Daten mit wenig Aufwand wiederhergestellt werden. Außerdem haben Firmen heute die Möglichkeit, ihre Backups in der Cloud zu speichern und Disaster Recovery als Service zu mieten.

Backups in der Cloud

Cloud Backup hat einige Vorteile: Die Backup-Daten werden extern, also off-site gespeichert. Wenn am primären Standort etwas richtig schiefläuft und nicht nur die Produktivsysteme, sondern auch lokal gespeicherte Backups unbrauchbar werden, hat man immer noch einen Datenbestand in der Cloud, mit dem sich die Systeme wiederherstellen lassen. Anstatt Backup-Tapes durch die Gegend zu fahren, überträgt man die Daten einfach über das Internet und spart sich auch gleich die Investition in zusätzliche Speichermedien. Ein Backup in der Cloud hat aber auch Nachteile: Der größte Nachteil ist der Flaschenhals Internet.  Ein Backup, also eine Datensicherung, hat das Ziel, Daten nach einem ungewollten Verlust wiederherstellen zu können. Es geht vor allem um die kleineren Notfälle: Ein Ordner wurde aus Versehen gelöscht oder ein System funktioniert nach einem fehlerhaften Update nicht mehr. Für diesen Zweck sind moderne imagebasierte Backups von virtuellen Maschinen der ideale Notnagel. Wenn allerdings sehr große Images vollständig wiederhergestellt werden müssen, kann der Datentransfer über das Internet zu einer Geduldsprobe werden. Hier ist ein lokal gespeichertes Backup klar im Vorteil. Deshalb fahren viele Firmen eine Doppelstrategie: lokale Datensicherung plus Cloud Backup für alle kritischen Systeme.

„Ein Notfall ist ein Schadensereignis, bei dem Prozesse oder Ressourcen einer Institution nicht wie vorgesehen funktionieren. Die Verfügbarkeit der entsprechenden Prozesse oder Ressourcen kann innerhalb einer geforderten Zeit nicht wieder hergestellt werden. Der Geschäftsbetrieb ist stark beeinträchtigt. Eventuell vorhandene SLAs (Service Level Agreements) können nicht eingehalten werden. Es entstehen hohe bis sehr hohe Schäden, die sich signifikant und in nicht akzeptablem Rahmen auf das Gesamtjahresergebnis eines Unternehmens oder die Aufgabenerfüllung einer Behörde auswirken. Notfälle können nicht mehr im allgemeinen Tagesgeschäft abgewickelt werden, sondern erfordern eine gesonderte Notfallbewältigungsorganisation.“ (BSI Standard 100-4)

Doch was passiert in einem richtigen Notfall?
Es muss nicht immer gleich eine Havarie sein, oft sind es Hardwareausfälle oder eine Stromunterbrechung infolge von Bauarbeiten die zu einem Ausfall des Rechenzentrums führen. Wichtige Geschäftsanwendungen sind dann für längere Zeit nicht verfügbar. In dieser Situation sind Backups in der Cloud für zwei Szenarien hilfreich: Erstens, wenn mit ihnen Ersatzsysteme an einem anderen Standort gestartet werden können und, zweitens, wenn zum Beispiel nach einem größeren Schaden die IT-Systeme am primären Standort wiederhergestellt werden sollen. Hierfür sind Image-basierte Backups ideal, allerdings liegen sie jetzt meilenweit entfernt im Rechenzentrum des Cloud Providers. Wenn beispielsweise für eine komplette Wiederherstellung aller gesicherten Systeme 500 Gigabyte zurückgespielt werden müssen, verlängert sich die Ausfallzeit selbst mit einer Download-Rate von 10 Megabit pro Sekunde um mindestens weitere 6 Tage. Hier kann man nur hoffen, dass der Dienstleister auch einen Transfer auf physischen Speichermedien anbietet.

Um entscheiden zu können, ob ein Cloud Backup als Notfall-Lösung ausreicht, muss im Unternehmen zuerst die Frage beantwortet werden: Wie lange kommen wir ohne unsere IT-Systeme aus?  Wie gut Ausfälle toleriert werden können, hängt davon ab, wie stark die Geschäftsprozesse von verfügbaren IT-Systemen und Anwendungen abhängig sind. Während die eine Firma mit ein paar Workarounds auch mal eine Woche lang ohne Mailserver und Kundendatenbank auskommt, wird es für eine andere schon nach wenigen Stunden ohne Warenwirtschaftssystem richtig teuer, vom Image Verlust ganz zu schweigen. In einer Befragung von 300 mittelständischen Betrieben, die TechConsult in diesem Jahr für HP durchgeführt hat, wurde die maximale Ausfallzeit kritischer IT-Systeme, die der Geschäftsbetrieb verkraften kann, im Mittel mit 4,7 Stunden angegeben. Die Kosten für einen Ausfall schlugen im Schnitt mit 25.000 Euro pro Stunde zu Buche. Bei diesen Zahlen wird schnell klar, dass ein Backup als Disaster Recovery Lösung nicht reicht, auch nicht in der Cloud.

Business Continuity – Wie geht es im Notfall weiter?

Wenn die Geschäftsprozesse stark IT-abhängig sind, dienen Backup und Disaster Recovery dem übergeordneten Ziel der Business Continuity, also der Aufrechterhaltung des Geschäftsbetriebs. Entsprechende Maßnahmen sollen dann greifen, wenn unvorhersehbare Ereignisse eintreten bzw. Vorkehrungen, die eigentlich einen Ausfall verhindern sollten, versagt haben. Bei der Planung der Notfall-Maßnahmen sind ein paar Parameter besonders wichtig, die auch das BSI in seinem Standard 100-4 für das Notfallmanagement behandelt (siehe Grafik).

Wiederherstellung eines IT-Prozesses nach einem Notfall (Quelle: BSI Standard 100-4)

Wiederherstellung eines IT-Prozesses nach einem Notfall (Quelle: BSI Standard 100-4)

Recovery Time Objective (RTO) – Wiederanlaufzeit – Max. tolerierbare Ausfallzeit

Unter Recovery Time Objective (RTO) versteht man die Zeitspanne innerhalb der ein Geschäftsprozess nach einem Ausfall wiederhergestellt sein muss. Sie ist somit auch ein Service Level für Disaster Recovery Maßnahmen. Ein RTO von 4 Stunden definiert als Zielvorgabe, dass nach einem Notfall die IT-Systeme spätestens nach 4 Stunden wieder soweit funktionieren, dass auch die Geschäftsprozesse wiederhergestellt sind.

Das BSI unterscheidet zwischen der maximalen tolerierbaren Ausfallzeit (MTA), also die Zeit bis zur völligen Wiederherstellung des Normalbetriebs und der Wiederherstellungszeit. Die sogenannte Wiederanlaufzeit (WAZ) ist identisch mit der Wiederherstellungszeit, wenn nach dem Notfall direkt wieder der Normalbetrieb aufgenommen werden kann. Wenn aber – was häufig der Fall ist – erst einmal ein Notbetrieb aktiviert wird, ist die Wiederanlaufzeit die Zeitspanne zwischen dem Ausfall und der Verfügbarkeit eines Notbetriebs. Sofern man die Wiederanlaufzeit als Zielvorgabe definiert, ist sie identisch mit dem RTO.  Die Wiederherstellungszeit kann auch größer als die maximal tolerierbare Ausfallzeit sein, sofern der Notbetrieb die Geschäftsprozesse soweit unterstützt, dass keine finanziellen Schäden entstehen. Um das gewährleisten zu können, müssen auch für einen Notbetrieb Mindestanforderungen hinsichtlich Performance, Verfügbarkeit sowie Sicherheit definiert werden.

Recovery Point Objective (RPO) – Wiederanlaufpunkt

Recovery Point Objective (RPO) bezeichnet die maximale Zeitspanne innerhalb der Daten unwiederbringlich verloren gehen dürfen. In der Praxis ist es der Zeitraum zwischen zwei Datensicherungen bzw. Replikationen. RPO ist ebenfalls ein Service Level und wird als Zielvorgabe für den maximal zulässigen Datenverlust benutzt. Bei einem RPO von 1 Stunde sollte zum Zeitpunkt des Systemausfalls die letzte Datensicherung in keinem Fall länger als eine Stunde zurückliegen. Es gehen also nur maximal die Daten der letzten 60 Minuten verloren.

Disaster Recovery für virtuelle Infrastrukturen

Um entscheiden zu können, ob im Notfall ein Backup in der Cloud reicht, muss man die oben beschriebenen Zielvorgaben RTO und RPO für alle wichtigen Geschäftsprozesse definieren und in Beziehung zu den technischen Optionen für eine Systemwiederherstellung bzw. einen Notfallbetrieb setzen. Wenn eine Firma den Verlust der Daten eines ganzen Arbeitstages (der Zeitraum zwischen zwei typischen Datensicherungen) verschmerzen kann und so lange ohne ihre IT-Systeme auskommt, bis diese mit Hilfe der Backups gegebenenfalls auf neuer Hardware wiederhergestellt sind, dann kann ein Cloud Backup durchaus ausreichend sein. Alle anderen brauchen – ergänzend zum Backup – eine Disaster Recovery Lösung.

Backup und Disaster Recovery erfüllen unterschiedliche Funktionen. Wenn es darum geht, einen gelöschten Ordner wiederherzustellen oder den Systemzustand von vor 3 Tagen, ist ein Backup unverzichtbar. Wenn man aber in einem Notfall sowohl den Datenverlust als auch die Ausfallzeit geschäftskritischer Systeme minimieren will, kommt man an Datenreplikation plus Aktivierung von Ersatzsystemen an einem anderen Standort kaum vorbei.

Backup Disaster Recovery
Ziel Wiederherstellung einzelner Dateien und Ordner bzw. kompletter Systeme (VMs) auch aus früheren Versionen Wiederherstellung der für den Geschäftsbetrieb notwendigen IT-Systeme nach bzw. während eines Notfalls
Datensicherung Nach einem Full-Backup mindestens einmal täglich inkrementell Kontinuierliches Replizieren aller Daten und Änderungen
Datenspeicherung Komprimierte Backup-Dateien Betriebsbereite Kopie des Primär-Systems mit nahezu identischem Datenbestand an einem zweiten Standort
Wiederherstellungspunkte Anzahl und Speicherdauer der Wiederherstellungspunkte für ein Point-in-time Restore sind frei wählbar. Meist ist nur der jeweils letzte Stand verfügbar; einige Systeme bieten Wiederherstellungspunkte mit einer Speicherdauer von einigen Tagen.

Replikation

Mit einer Replikation sollen identische Kopien auf einem zweiten System – in der Regel an einem anderen Standort – erzeugt werden, ohne den Betrieb am primären Standort zu beeinträchtigen. Beim Disaster Recovery geht es darum, mit Hilfe der replizierten Daten wichtige Anwendungen auf den Ersatzsystemen möglichst schnell und ohne Datenverlust aktivieren zu können. Es gibt unterschiedliche technische Möglichkeiten, um Daten in virtualisierten Infrastrukturen zu replizieren. Allerdings wird eine klare Trennung immer schwieriger, da die Produkte und ihr Funktionsumfang stetig weiterentwickelt werden.

Array-basierte Replikation

Mit Array-basierter Replikation werden die Daten von einer Storage-Einheit auf eine zweite repliziert. Es wird auf Blockebene repliziert, also nicht individuelle virtuelle Maschinen (VM), sondern LUNs (logical unit number) bzw. Speichervolumina. Diese Art der Replizierung wird meist als Funktionalität von den jeweiligen Storage-Herstellern angeboten (z.B. von HP, EMC, NetApp). Die Vorteile einer Array-basierten Replikation sind, dass üblicherweise synchron repliziert wird, d.h. jeder Schreibvorgang wird gleichzeitig auf Primär- und Backup-Speicher geschrieben. Ein RPO von Null ist somit kein Problem. Außerdem braucht man kein zusätzliches Produkt installieren. Andererseits ist man an denselben Hersteller gebunden und muss in ein zweites, identisches Storage-System investieren, was doch schnell ins Geld gehen kann. Darüber hinaus setzt diese Form des Replizierens eine sehr gute und direkte Verbindung der beiden Standorte voraus; größere Entfernungen (mehr als 50 km) sind so üblicherweise nicht realisierbar.

Netzwerk-basierte Replikation

Für diese Art der Replikation wird in der Regel eine Appliance oder ein spezieller Switch im Netzwerk zwischen Host und Storage installiert. Die Appliance arbeitet wie ein Splitter: Die zu replizierenden Storagezugriffe werden kopiert und die Kopien zu einer zweiten Appliance am Zielstandort repliziert. Eine netzwerkbasierte Replikation funktioniert auch in heterogenen Umgebungen, da sie unabhängig vom Storage-System und der Host-Plattform arbeiten kann. Außerdem werden für das Replizieren der Daten keine Host Ressourcen verbraucht. Einige Produkte, zum Beispiel die NSS von FalconStor, können sowohl Daten von virtuellen als auch von physischen Servern replizieren. Das Management von netzwerkbasierten Replikationsprodukten ist allerdings recht komplex. Da es sich normalerweise um synchrone Spiegelungen handelt, stellen sie – analog der SAN-(Array)-basierten Spiegelung – sehr hohe Anforderungen an die Anbindung des Backup-Standortes an die primären Systeme.

Host-basierte Replikation

Klassische hostbasierte Replikationsprodukte arbeiten mit Agenten, die im Gast-Betriebssystem der zu replizierenden Server installiert werden. Die Software steuert die Replikation der Daten und leitet alle Änderungen zum jeweiligen Zielsystem weiter. Entsprechende Lösungen können ebenfalls mit beliebigen Storage-Systemen genutzt werden, sind aber preiswerter und einfacher zu handhaben als netzwerkbasierte Replikationsprodukte. Auf Host-Ebene kann das Replizieren der Daten und deren Wiederherstellung sehr granular gesteuert werden. Da dafür aber auch Serverressourcen verbraucht werden, kann sich das Replizieren negativ auf die Performance der Anwendungen auswirken. Firmen, die sowohl Windows als auch Linux Maschinen replizieren wollen, benötigen außerdem Produkte, die beide Betriebssysteme unterstützten.

Eine neue Gruppe von hostbasierten Replikationsprodukten kommt ohne die Installation von Agenten im Betriebssystem aus und nutzt stattdessen Schnittstellen der jeweiligen Virtualisierungssoftware bzw. arbeitet mit Agenten (virtuelle Appliances) auf den Virtualisierungshosts. Sie stehen damit für eine neue Art der Datenreplikation speziell für virtuelle Umgebungen: die Hypervisor-basierte Replikation.

Hypervisor-basierte Replikation

Hypervisor-basierte Replikation arbeitet auf der Virtualisierungsebene. An einem zweiten Standort werden exakte Kopien der virtuellen Maschinen erzeugt und kontinuierlich auf dem aktuellen Stand gehalten. Die direkte Hypervisor-Anbindung hat mehrere Vorteile: Anders als bei einer Replikation auf Storage-Ebene, können die zu replizierenden virtuellen Maschinen individuell bestimmt werden. Der Einsatz ist auch nicht auf ein bestimmtes Betriebssystem beschränkt. Dafür sind die Produkte Hypervisor-spezifisch, was aber die meisten Kunden weniger stören wird. Wie alle hostbasierten Replikationslösungen sind sie Storage-agnostisch, es spielt also keine Rolle, welche Storage-Systeme von welchem Hersteller im Unternehmen bzw. am Zielstandort eingesetzt werden.

Entsprechende Produkte bieten zum einen die führenden Hersteller für ihre eigene Virtualisierungssoftware an, wie Hyper-V Replica von Microsoft oder vSphere Replication von VMware. Zum anderen gibt es eigenständige Produkte sowohl für VMware als auch für Microsofts Hyper-V bzw. andere Systeme. Veeam Backup & Replication nutzt Snapshots und das sogenannte Change Block Tracking (CBT), eine Funktion der VMware vSphere vStorage API, um Image-basierte Backups bzw. Kopien der virtuellen Maschinen zu erstellen und Änderungen zu replizieren. Ohne Performance verbrauchende Snapshots kommt Zerto Virtual Replication aus, eine neue Disaster Recovery Lösung für VMware, die auch direkt über das vCenter Management administriert werden kann. Zerto repliziert nicht nur individuelle virtuelle Maschinen, es kann diese auch zu sogenannten „Virtual Protection Groups“ zusammenfassen und als Einheit (Konsistenzgruppe) replizieren. In einem Notfall werden die Kopien automatisch in einer definierten Boot-Reihenfolge gestartet. Selbst komplexe Anwendungen haben durch diese Gruppierung auch am Ersatzstandort einen konsistenten Datenbestand.

Die genannten Vorteile machen eine Hypervisor-basierte Replikation zur idealen Disaster Recovery Lösung für virtualisierte Infrastrukturen. Die virtuellen Maschinen können in der Regel sehr effizient über das Internet zum Ziel-Standort repliziert werden, weil nicht jedes Mal die gesamte VM, sondern nur die geänderten Blöcke kopiert werden. Da die replizierten Kopien in einem betriebsbereiten Zustand sind, geht in einem Notfall das Aktivieren der Ersatzsysteme viel schneller als eine Wiederherstellung aus einem Backup. Für das Disaster Recovery ist die Replikation aber nur die halbe Miete. Um virtuelle Maschinen an einen anderen Standort bzw. zu einem Cloud Provider zu replizieren, reichen zunächst genügend Speicherplatz und eine Datenverbindung. Sobald aber in einem Notfall die Geschäftsprozesse mittels vollwertiger Ersatzsysteme wiederhergestellt werden sollen, müssen auch noch andere Voraussetzungen erfüllt sein. Zum einen brauchen die Ersatzsysteme eine Hosting Plattform mit ausreichend Serverressourcen. Damit sie für die Anwender erreichbar sind, müssen IP-Adressen eingerichtet und andere Netzwerkparameter, möglicherweise auch VPNs konfiguriert werden. Kaum ein Unternehmen wird geschäftskritische Applikationen mit sensiblen Daten „irgendwo“ in der Cloud starten wollen, auch nicht während eines Notfalls. Ein eigenes VLAN und Firewallschutz gehören in der Regel zu den Mindestanforderungen.

Die oben genannten Replikationsprodukte unterscheiden sich deutlich in dem Aufwand, der notwendig ist, um aus den Kopien ein produktives Notfall-Rechenzentrum zu machen. Mit anderen Worten, auch mit einem Disaster Recovery aus der Cloud muss man vorab entscheiden, in welchem „Zustand“ der Backup-Standort sein soll und wie lange die Wiederanlaufzeit dauern darf. Für einzelne virtuelle Server mag die „Cold Site“-Variante, in der die Ersatzsysteme manuell gestartet und konfiguriert werden müssen, ausreichend sein. Unternehmen, die eine größere Anzahl Maschinen und kritische Anwendungen mit mehreren VMs möglichst schnell wiederherstellen wollen, werden sich eher für eine vollwertige Disaster Recovery Lösung wie Zerto Virtual Replication entscheiden. Hier können alle für den Notfall benötigten Ressourcen in der Cloud  reserviert und analog eines „Hot Site“-Backup-Standortes bereits vorab konfiguriert werden. Das Aktivieren der Ersatzsysteme und das Umschalten auf den Backup-Standort (Failover) erfordert dann nur noch wenige Mausklicks. Da das Produkt auch VMware vCloud unterstützt, können die Ersatzsysteme gleich in einem privaten virtuellen Datacenter mit Netzwerktrennung, Firewallschutz und vorkonfigurierten IP-Adressen etc. gestartet werden.

Fazit

Ein zusätzliches Backup in der Cloud mag preiswert sein, reicht aber für viele Unternehmen in einem echten Notfall nicht aus, weil wichtige IT-abhängige Geschäftsprozesse nicht schnell genug und meist auch nicht mit allen Daten wiederhergestellt werden können. Eine gut geplante IT-Recovery Lösung gibt es nicht zum Nulltarif. Im Vergleich zum physischen Backup-Rechenzentrum gibt es heute aber virtuelle Backup-Datacenter für einen Bruchteil der Kosten, die mit Hilfe moderner Replikationslösungen im Notfall sehr schnell betriebsbereit sind. Damit werden entsprechende Services auch für solche Firmen erschwinglich, die eigentlich ein Disaster Recovery mit kleinen RTO und RPO brauchen, sich das bisher aber nicht leisten konnten.

Ein Gedanke zu „Reicht im Notfall ein Backup in der Cloud?

  1. Pingback: Notfallmanagement für KMUs | Dunkel Blog

Kommentare sind geschlossen.