Praxisbeispiel: Umstieg auf Backup-to-Disk

Backup-to-Disk und Deduplikation sind in aller Munde. Kosten sollen sinken, der Gebrauchsnutzen steigen und die Wiederherstellungszeiten schrumpfen. Doch wie gelingt die Umstellung auf die neuen Technologien? Welche Fallstricke sind zu beachten, wo lauern versteckte Kosten? speicherguide.de betrachtet einen Beispielfall.

Bild: Quantum

Die Backup-Ausgangssituation

Für die einzelnen Backups finden sich in den Produktionsabteilungen und im Rechenzentrum unterschiedliche Lösungen. Die Linux-Server sichern mit Hilfe von »tar« und anderen Bordmitteln auf direkt angeschlossene Bänder, meist preiswerte DAT-Einzellaufwerke. Die Novell-Umgebungen bedienen sich ebenfalls ihres integrierten Werkzeuges »SBACKUP«, um auf lokal angeschlossene LTO-3-Laufwerke zu sichern. Allein die Windows-Server außerhalb des Rechenzentrums werden bereits mit Agenten einer Backup-Suite über das Netzwerk auf dem zentralen Bandroboter mit LTO-4-Technik und vier Laufwerken gesichert. Auch alle anderen Server im Rechenzentrum nutzen dieses System zur Sicherung ihrer Daten. Die gesamten Server verfügen über lokale Festplatten, daher existiert kein Speichernetzwerk wie ein Storage-Area-Network (SAN). Insgesamt gilt es eine Datenmenge von 15 TByte zu sichern, mit einer Zuwachsrate von 25 Prozent pro Jahr. Zum Ablauf der Nutzungsfrist der zu planenden Umgebung sollte die IT-Abteilung also mit knapp 30 TByte rechnen.

Anforderungskatalog für optimiertes Backup

Der IT-Leiter analysiert diese Landschaft und zieht die folgenden Schlüsse:

1. Alle Backups sollen in Zukunft nicht mehr verstreut, sondern zentral auf einem neuen System durchgeführt werden, welches sowohl von seiner Sicherungsgeschwindigkeit als auch seiner Kapazität den neuen Anforderungen gewachsen ist.
2. Einige Produktionsstandorte befinden sich nicht auf dem Firmengelände, sondern in entfernten Niederlassungen. Dort werden künftig vor Ort die Daten zunächst dedupliziert und erst dann zentral gesichert.
3. Es wird ein zentrales Plattensystem für die Server über 10-Gbit/s-FCoE im Rechenzentrum eingerichtet. Dieses Plattensystem soll unterschiedliche Leistungsklassen abbilden und die Daten automatisch diesen Klassen zuweisen.
4. Das neue System soll nicht mehr auf Bändern, sondern auf Platten sichern.
5. Ein SAN ist nicht geplant. Die Anbindung der neuen Systeme erfolgt entweder über 10-Gbit/s-Ethernet oder 10-Gbit/s-FCoE.
6. Der bisher zentral genutzte LTO-4-Bandroboter rückt ins Archiv, um die nicht mehr benötigten Backup-Sätze preiswerter unterzubringen.
7. Alle Vorgänge sollen automatisiert ablaufen, um das Personal in diesem Bereich für andere, wichtigere Projekte freizumachen.

Gesucht ist eine Sicherungslösung, die alle vorhandenen Server-Plattformen unterstützt, sowohl auf Band- als auch auf Plattensystemen sichert und per Deduplikation die zu übertragende Datenmenge entfernter Standorte reduziert. Sie unterstützt sowohl die bisherigen Methoden als auch Disk-Backup, bietet Deduplikation an der Quelle und am Ziel, spezielle Unterstützung sowohl für Exchange als auch für SQL und ist in der Lage, nicht mehr benötigte Sicherungen auszulagern.

Festplattenmix im Zentralspeicher

Als zentrales Plattensystem entscheidet man sich für ein Array, das sich mit Platten verschiedener Leistungsklassen – also Fibre-Channel, SATA und Flash – ausrüsten lässt und bereits 10-Gbit/s-FCoE unterstützt. Maximal lässt es sich mit 120 Festplatten ausrüsten und bietet bis zu vier FCoE-Schnittstellen. Das System ist sowohl für alle physikalischen Server als auch für die bereits unter Vmware virtualisierten Maschinen zertifiziert. Es wird mit 32 1-TByte-SATA-Platten in RAID 6 (14+2), weiteren 16 FC-Platten mit je 400 GByte in RAID 5 (7+1) und einer RAID-5-Gruppe mit 146-GByte-Flash-Laufwerken installiert. Insgesamt bietet das Array 28 TByte auf SATA-Medien, 5,6 TByte auf FC-Platten und ein TByte auf Flash-Drives. Die Daten können automatisch zwischen diesen Speicherklassen verschoben werden, je nach momentaner Belastung der logischen Laufwerke.

Für das Backup-to-Disk-System kommt eine weitere Maschine desselben Herstellers zum Einsatz. Zwar könnte der IT-Manager natürlich preiswertere und kompaktere Angebote wählen, jedoch entscheidet er sich hier für die Vorzüge desselben Kundendienstes und derselben Herstellerkontakte. Außerdem gewährt der Anbieter beim Ankauf zweier Geräte deutlich höhere Preisnachlässe. Das Array ist mit 16 TByte in 1-TByte-Laufwerken unter RAID-6-Schutz ausgerüstet und sichert laut Hersteller 720 GByte/h. Es lässt sich im laufenden Betrieb auf bis zu 36 TByte erweitern, was die Zielvorgaben von 30 TByte nach drei Jahren erfüllt.

Erst unter Realumständen testen, dann installieren

Nachdem die Netzwerkabteilung alle zentralen Switches auf 10-Gbit/s-FCoE bzw. 10-Gbit/s-Ethernet umgerüstet und die Serverfraktion entsprechende Testsysteme aufgebaut hat, beginnt die Installation der Prototypenumgebung. Hierzu werden jeweils ein SQL- und ein Exchange-Server physikalisch konfiguriert und mit Testdaten befüllt, während zwei Dateiserver unter Windows 2008 auf einem Vmware »vSphere 4« installiert werden. Auf diesem Server finden ebenfalls Linux- und Netware-Images Platz, die im Test die Außenstellen bzw. Produktionsabteilungen repräsentieren.

Ist die Installation und Konfiguration der Backup-Software und ihrer Agenten erfolgt, beginnen die ausführlichen Tests. Hierbei prüft das IT-Team die folgenden Schritte:

1. Migration der Testdaten von den lokal installierten Platten auf das zentrale Speichersystem. Demontage der lokalen Laufwerke. Mindestens eine Produktionswoche lang wird der Betrieb mit dem neuen System beobachtet.
2. Volle und inkrementelle Sicherung aller vorhandenen Server.
3. Integration in die SQL- und Exchange-Umgebung. Vollsicherung und inkrementell, Rücksicherung einzelner Datensätze bzw. Mailboxen.
4. Sicherungsgeschwindigkeit aller Server.
5. Deduplizierungsrate und Bandbreitenbedarf für die Sicherung der entfernt installierten Abteilungsserver.

Eigentlicher Umstieg erfolgt Schritt für Schritt

Wurden alle Schritte erfolgreich absolviert, überführt man die Produktionssysteme eines nach dem anderen in die neue Umgebung mit dem zentralen Speichersystem und der Plattensicherung. Die Daten werden von den lokalen auf die Platten des zentralen Speichersystems migriert und wiederum eine Woche in Produktion beobachtet. Erst dann lässt sich das nächste System anpassen. An keinem Punkt darf es eine Situation geben, in der die IT-Verwalter nicht sofort auf die alte Konfiguration zurückgreifen und die Produktion wieder aufnehmen können (»negative return«). Auch empfiehlt es sich natürlich, immer nur einen Server gleichzeitig zu migrieren. Ebenso sollten Unternehmen im Zuge einer solchen Erneuerung erwägen, die im Hause vorhandenen »Exoten« nach Möglichkeit durch eine homogenisierte Server-Plattform zu ersetzen. Dies spart Lizenzgebühren für die Backup-Anbindung und die Ausbildung der EDV-Mannschaft auf mehr als einem Betriebssystem.

Nach Ausrollen der neuen Server-Umgebung wird dort die neue Sicherungs-Software installiert. Zwar bieten manche Pakete die Möglichkeit, bereits vorhandene Sicherungen von Band auf Platte zu migrieren, jedoch hat sich dies als zu umständlich erwiesen. Viel leichter ist der Schritt zum neuen Medium, wenn die nächste Vollsicherung ansteht. Diese und alle kommenden Inkremente werden dann auf dem Plattensystem durchgeführt. Sollte in dieser Umgebung etwas nicht funktionieren, stehen immer noch die vorhandenen Bänder bereit, um das Backup durchzuführen.

Die Server der externen Standorte sichern jetzt nicht mehr auf ihre eigenen Bänder, sondern nutzen Deduplikation, um die zur Zentrale zu übertragenden Sicherungssätze zu verkleinern. Je nach Art und Häufigkeit der zu speichernden Daten lässt sich eine Kompression von bis zu 90 Prozent erreichen. Dadurch verringert sich die für die Sicherung benötigte Bandbreite auf zehn Prozent des Ausgangswerts ohne Deduplikation. Dies spart Zeit und Kosten für die Anbindung der einzelnen Standorte.

Erst nach Ablauf eines vollständigen Sicherungszyklus auf allen Servern lässt sich die letzte Stufe der Migration angehen. Nun wird die Backup-Software angepasst, um alle für einen bestimmten Zeitraum nicht mehr angefassten Sicherungssätze auf die nun als Archiv fungierende Bandbibliothek zu verschieben. Auch diese Funktion hat sich bereits im Lastenheft bei der Anschaffung der Software befunden. Als Zeitraum kann zum Beispiel die Dauer einer Vollsicherung eines Systems gelten. Alle Daten, die im Vergleich zur letzten Vollsicherung nicht mehr geschrieben wurden, lagert man aus, da sie zur Rekonstruktion der Produktionsumgebung nicht mehr benötigt werden. Und sollte ein Nutzer doch einmal Dateien aus ausgelagerten Sicherungen benötigen, kann er in der Regel die Zeit erübrigen, die dieser Vorgang benötigt.

Backup-Umstieg nicht auf die leichte Schulter nehmen

Die Umstellung von Band auf Festplatte als primäres Sicherungsmedium wird von den Herstellern einschlägiger Systeme als einfach und unproblematisch beschrieben. Aber selbst falls die Migration tatsächlich ohne Störungen verlaufen sollte, zieht sie sich je nach Art und Anzahl der involvierten Server über mehrere Monate hin. In der Regel wollen die Betreiber auf der sicheren Seite bleiben. Sind externe Standorte beteiligt, ist Deduplikation ein Muss. Sowohl die benötigten Bandbreiten als auch die Sicherungs- und Wiederherstellungszeiten minimieren sich damit spürbar. Darüber hinaus empfiehlt sich die Nutzung der schon vorhandenen Bandsysteme als Archiv zur kapazitiven Entlastung der Backup-Arrays.