Ratgeber: Backup und Disaster Recovery im Zusammenspiel

Der Verlust unternehmenskritischer Daten bedeutet für jedes Unternehmen und jede Organisation einen enormen Schaden, wobei der Imageschaden schwer bewertet werden kann. Schätzungen gehen aber davon aus, dass jede Minute Ausfallzeit wichtiger IT-Komponenten im Schnitt mehr als 100.000 Euro pro Stunde kostet.

Datenverlust hat dabei so verschiedene Ursachen, dass ein solches Ereignis nie ganz ausgeschlossen werden kann. Aber mit einem guten und konsequenten Backup-Management lassen sich die Downtime-Kosten enorm reduzieren. Aberdeen Research hat 2011 im Rahmen einer Studie ermittelt, dass in Unternehmen und Behörden mit unzureichenden Disaster-Recovery-Maßnahmen im Schnitt 3,5 Mal pro Jahr eine solche Katastrophe auftritt. Die Ausfallzeiten von IT-Systemen summieren sich im Schnitt auf 29,4 Stunden jährlich. Das entspricht einem finanziellen Schaden von mehr als 2,9 Millionen US-Dollar.

Im Vergleich dazu verzeichnen Anwender mit optimierten Vorsorgemaßnahmen weniger als einen Vorfall pro Jahr. Dieser führt zu Stillstandzeiten von 72 Minuten und einem Schaden von nur 72.000 US-Dollar. Neuere Studien aus dem Jahr 2012 belegen, dass der Stundensatz für Downtime-Kosten im Schnitt auf 138.000 Dollar gestiegen ist.

Hardware für Backup und Disaster Recovery konfigurieren

Angesichts der Möglichkeiten, die ein gutes Backup und Disaster Recovery bietet, stellt sich die Frage, wie es in der Praxis effektiv für höchste Sicherheit sorgt. Schon eine richtige Konfiguration der Hardware kann hier helfen.

Welche Hardware in welcher Disaster-Recovery-Umgebung eingesetzt werden soll, hängt von der Größe des Unternehmens, der Zahl der Server und Clients sowie dem Umfang der Datenbestände ab, die gesichert werden müssen. Die Spannbreite ist enorm und reicht vom NAS-System bis zum kompletten Ausfallrechenzentrum. Wichtig ist aber vor allem, dass eine Backup- und Disaster-Recovery-Lösung möglichst viele Storage- und Archivierungstechniken unterstützt.

Schon bei der Wahl der Hardware können in Detailfragen die Weichen richtig gestellt werden. Wenn man SATA-Festplatten der Enterprise-Kategorie auswählt, gibt man im ersten Schritt zwar mehr Geld aus, investiert es aber in eine deutlich längere Lebenserwartung, seltenere Sektorenfehler und eine Optimierung der RAID-Controller.

Zentral ist auch die Ordnung in der Datenlandschaft. Immer wieder wird der einfache Grundsatz nicht ernst genommen, zwei separate Partitionen für Produktionsdaten und Anwendungsdaten einzurichten. Eine Vermengung erschwert die Umsetzung einer stringenten Backup- und Disaster-Recovery-Strategie. Die Partitionen für Daten werden am besten als RAID-10 konfiguriert.

Backup- und Disaster-Recovery-Software konfigurieren

Wer Datensicherheit und Performance des Unternehmensnetzes vereinbaren will, kann mit einer geschickten Konfiguration einer Disaster-Recovery-Software dazu beitragen. So sollten Datensicherungen nie zur vollen Stunde starten, sondern einige Minuten später. Das vermeidet zum Beispiel Konflikte mit etwa 25 aktiven Aufgaben, die beispielsweise in Windows Server 2008 R2 immer zu einer vollen Stunde starten.

Wichtig ist eine solche Planung, da ein professionelles Backup-Konzept möglichst kontinuierlich Daten sichern sollte. Ein Systemdatenträger sollte mindestens drei Mal pro Tag gesichert werden. Wenn das Laufwerk zudem ein Domänen-Controller ist und die SYSVOL- und NTDS-Verzeichnisse auf dem Systemdatenträger lagern, ist eine fünfmalige Sicherung pro Tag angeraten. Die Sicherungsläufe für die Datenvolumen sollten zeitversetzt erfolgen. Dazu ein Beispiel: Partition 1 startet täglich im Stundenrhythmus um 06:34 Uhr mit der inkrementellen Sicherung. Bei Partition 2 erfolgt das erste der stündlich durchgeführten Backups um 06:37 Uhr. Wer noch mehr Wert auf Datensicherheit legt, lässt automatisch im 15-Minuten-Takt Snapshots erstellen, sodass im schlimmsten Fall lediglich ein Verlust der Daten der letzten Viertelstunde eintreten kann.

Der Teufel steckt im Detail: Ein eigenes Windows-Dienstkonto nur für die Sicherung der Backups ist sinnvoll. Ebenso sollte an eine 256-Bit-Verschlüsselung der Backups gedacht werden. Außerdem hat eine intelligente Benennung der Backups nichts mit Ordnungswahn gemein, sondern ist technisch durchaus geboten. Bei zu langen Dateinamen ist Windows früher oder später nicht mehr in der Lage, die Backup-Kette zu mounten, weil der Pfad zu den Images zu lang ist.

Das Repository richtig dimensionieren

Backup-Images sollten möglichst kompakt gehalten werden, damit der Bedarf an Speicherplatz nicht explodiert. Selbst in kleineren und mittelständischen Unternehmen bewegen sich die Datenvolumina, die von Servern bereitgestellt werden, mittlerweile im zweistelligen Terabyte-Bereich. Die Menge der zu sichernden Daten steigt in zunehmend heterogenen IT-Landschaften.

Solche IT-Flickenteppiche erschweren die Entscheidung, welche Daten zu sichern sind. Sie machen eine regelmäßige Inventur der Daten und eine Homogenisierung der Serverlandschaften notwendig. Zusätzlich wird es immer wichtiger, nicht nur Daten, sondern gleich die ganze Software und individuelle Konfigurationen - sprich, ganze IT-Infrastrukturen - zu sichern.

In allen Fällen ist nur eine inkrementelle oder eine differentielle Sicherung den Anforderungen angemessen: Alle sektorbasierten Änderungen im Vergleich zur Vorabsicherung werden erfasst und in einem inkrementellen Image gesichert. Außerdem ist es ratsam, Server nicht für das Speichern großer temporärer Dateien wie ISO-Files oder nicht komprimierbare Daten heranzuziehen. Werden diese Vorgaben berücksichtigt, lässt sich die Größe eines Image Repository mithilfe dieser Formel errechnen:

Größe der Rohdaten * 60 % * 6 = Speicherplatz für Images, der ein Jahr ausreicht

Diese Formel berücksichtigt bereits eine Sicherheitsreserve von 15 Prozent.

Vom Backup-Image zum funktionsfähigen System

Der wahre Wert eines Backups zeigt sich erst im Ernstfall, wenn die Datensicherung zur möglichst schnellen Wiederherstellung eines Servers herangezogen wird. Die Wiedereinspielung der Daten beziehungsweise die Neuaufsetzung der betroffenen Systeme kann auf drei Arten erfolgen:

• als hardwareunabhängiges Restore,

• durch den Einsatz eines Stand-by-Servers oder

• durch Booten von Systemen direkt vom Backup-Image in einer virtualisierten Umgebung.

Szenario 1: hardwareunabhängige Wiederherstellung

Die hardwareunabhängige Wiederherstellung von Daten zeichnet sich durch ein Maximum an Flexibilität aus. Sie ermöglicht es, ein System auf einer anderen Hardwareplattform als der ursprünglich verwendeten wiederherzustellen. Chipsatz, Hardware-RAID oder eine andere Hypervisor-Struktur spielen keine Rolle. Dadurch eignet sich diese Technologie auch für die Migration von einer Systemplattform zu einer anderen. Außerdem können vorhandene Images auf virtualisierten Systemen wiederhergestellt werden.

Insgesamt sind folgende Kombinationen denkbar:

• physikalisch zu physikalisch (P2P),

• physikalisch zu virtuell (P2V),

• virtuell zu virtuell (V2V) und

• virtuell zu physikalisch (V2P).

Wichtig ist bei einer solchen hardwareunabhängigen Wiederherstellung, dass die richtigen Treiber verfügbar sind. Recovery-DVDs von guten Backup- und Disaster-Recovery-Lösungen bieten daher eine Wiederherstellungsumgebung (Pre-Execution Environment) mit den Treibern gängiger Hardwarekomponenten wie Chipsatz, RAID-Controller, USB-3.0-Geräten und Netzwerkadaptern. Außerdem unterstützen diese Wiederherstellungsumgebungen auch ältere Hardware für Windows Server 2012, 2008 R2 oder gar Windows Server 2003, falls ein Restore auf ein älteres System nötig wird.

Szenario 2: virtualisierte Stand-by-Server

Um die Ausfallzeiten möglichst kurz zu halten, ist es insbesondere bei Servern mit mehreren Terabyte an Daten ratsam, einen Stand-by-Server zu konfigurieren. Solche Stand-by-Server sind wesentlich günstiger als Server-Clustering-Lösungen, die zudem auf spezieller Hard- und Software aufbauen.

Ein virtualisierter Stand-by-Server - was beispielsweise die Headstart-Restore-Technologie realisiert - konfiguriert den Produktionsserver so, dass er in regelmäßigen Abständen inkrementelle Backups erstellt. Diese Images lassen sich dann in Virtual Machines mit den gängigen Formaten VMDK (Virtual Machine Disk) oder VHD (Virtual Hard Disk) überspielen. Fällt der Produktionsserver aus, können diese Images innerhalb weniger Minuten wiederhergestellt werden.

Mithilfe solcher "virtuellen" Stand-by-Server können die Risiken durch Hardwareausfälle auf ein Minimum reduziert werden. Das gilt für Fehlfunktionen sowohl von Serversystemen als auch der daran angeschlossenen Disk-Arrays.

Szenario 3: Virtualisierung

Eine besonders schnelle Wiederherstellung einer Systemumgebung direkt und ohne zeitaufwendige Umwege ist die hardwareunabhängige Realisierung einer Wiederherstellung direkt in einer virtualisierten Umgebung. Mit einem solchen VirtualBoot ist es möglich, vorhandene Backup-Dateien temporär in einem virtualisierten Zustand wiederherzustellen. Dabei wird das einfach zu konfigurierende und kostenfreie Oracle VM VirtualBox als Virtualisierungsplattform genutzt.

Der ausgefallene Server lässt sich dann innerhalb weniger Minuten als virtuelle Maschine starten und kann seine Arbeit wieder aufnehmen. In der Zwischenzeit kann der physische Server neu eingerichtet werden. Physische Stand-by-Server müssen nun nicht mehr vorgehalten werden. Während der virtualisierte Ersatzserver in Aktion ist, werden von den entsprechenden Daten weiterhin inkrementelle Sicherungen hergestellt. So lässt sich die komplette Backup-Kette zu einem beliebigen Zeitpunkt auf das neue oder reparierte System über den klassischen Bare-Metal-Restore zurückspielen, selbst wenn auf dem VirtualBoot-Ersatzsystem gerade gearbeitet wird. In der Praxis bedeutet dies eine minimale Downtime, sogar bei größeren Migrations- oder Wiederherstellungsvorgängen von großen Datenmengen.

Die Technik kann auch dazu verwendet werden, Desktop-Rechner oder die entsprechende Systemumgebung in Form einer Virtual Machine auf einer anderen Hardware bereitzustellen. Mitarbeiter, deren Client-System nicht mehr funktioniert, haben somit nach kurzer Zeit Zugriff auf ihre gewohnte Systemumgebung und die entsprechenden Daten.

Backup-Images replizieren und optimieren

Ein wichtiger Baustein eines umfassenden Disaster-Recovery- und Business-Continuity-Sicherheitsplans ist eine Softwarekomponente, mit der sich Backup-Images verwalten und replizieren lassen. Ein "Image Manager" sollte die Speicherung von Images auf lokalen Speichermedien oder Storage-Ressourcen in einem LAN, an entfernten Standorten oder in einer Cloud-Umgebung unterstützen. Dies kann eine Private Cloud im Unternehmensnetz sein oder eine Cloud-Umgebung, die ein Service-Provider bereitstellt.

Hilfreich ist eine Funktion, mit der sich festlegen lässt, welche Daten vor Ort und welche an einem anderen Standort abgelegt werden. Zudem sollte die Software die Option bieten, Backup-Dateien auf ihre Integrität zu überprüfen und diese zu konsolidieren. Wünschenswert sind auch Funktionen, mit denen sich der Bandbreitenbedarf beim Sichern über Weitverkehrsverbindungen steuern lässt und die den Speicherbedarf reduzieren, etwa indem ungenutzter Platz in Backup-Dateien eliminiert wird.

Fazit

Backup und Disaster Recovery sind kein Hexenwerk. Mit einer effektiven Lösung lassen sich optimale Datensicherheit einerseits und Performance des Netzwerks andererseits durchaus vereinbaren. Zudem schaffen entsprechende Technologien Wiederherstellungszeiten von wenigen Minuten.

Auch Cloud-Lösungen bieten eine sinnvolle Alternative und garantieren ein hohes Maß an Sicherheit, wenn eine Offsite-Speicherung ein lokales Backup zusätzlich sichert. Wichtig ist aber immer auch die kontinuierliche Überprüfung der Sicherungen. Denn nur konsistente und auslesbare Backups sind im Ernstfall eine Hilfe. (cvi)