Wie sichert man 60 GB in 36 Stunden über 16-Mbit-Token-Ring? Gibt es verläßliche Alternativen zu Vier-Millimeter-DAT-Devices? Was braucht man alles, um im Katastrophenfall Server oder Teile von ihnen wiederaufzusetzen? Wie sichert man SAP-R/3-Datenbanken? Dies ist nur ein Teil der Fragen, denen sich das Backup-Team der Deutschen Shell AG, Hamburg, vor einem Jahr stellen mußte. Zu diesem Zeitpunkt waren zirka 20 NT-Server mit unterschiedlichen Aufgaben im Einsatz, die über "Back-up Exec" von Arcada auf zwei Vier-Millimeter-DAT-Autoloader gesichert wurden. Eine Ausnahme bildeten zwei SAP-R/3-Server, deren Datenbank über die SAP-eigenen Programme - "Br-Archive" und "Br-Back-up" - auf je einen dedizierten Vier-Millimeter-DAT-Autoloader gesichert wurde. Über einen Zeitraum von zirka 18 Monaten lief dieser Prozeß mehr oder minder zufriedenstellend. Kleinere Schwierigkeiten wie zu lange Restore-Zeiten wurden benutzerseitig noch in Kauf genommen. Die verschiedensten Applikationen und Netzwerkkomponenten befanden sich im Aufbau, und der Host-seitig gewohnte Anspruch auf Antwort- und Verfügbarkeitszeiten war noch nicht so ausgeprägt wie heute. Die konsequente Umstellung von zirka 600 Benutzern auf das Netzwerk und die damit verbundene Einführung von netzwerkbasierten Mail-Systemen führten zwangsläufig zu einem größeren Datenvolumen und der Notwendigkeit eines zuverlässigen Backup-Services.
Mit der Professionalisierung des Netzwerkbetriebs wurden die Schwächen des Sicherungsumfelds offensichtlich: Bandfehler, extrem lange Sicherungszeiten (zirka 800 MB pro Stunde entsprachen zirka 56 Stunden Sicherungszeit für das Gesamtsystem) sowie die fehlenden Integrationsmöglichkeiten des R/3-Systems in die Netzwerksicherung.
Insbesondere die Häufung der Laufwerk- und Bandfehler war dramatisch: Bis zu vier Fehler pro Woche waren "normal". Glücklicherweise wurden von Beginn an alle Daten zweimal gesichert (eine Sicherung für den Bunker), eine davon war immer verwendbar. Der kritische Moment, in dem eine zerstörte Datei aufgrund eines defekten Bands verloren ist, blieb erspart. Dennoch: Hard- und Software waren ausgereizt.
Hinzu kam, daß nach Aufbau der SAP-R/3-Datenbank deren Produktionsübergabe bevorstand und damit die Verantwortung für die Datensicherung dem Backup-Team zufiel.
Nach Diskussionen mit den beteiligten Stellen und Mitarbeitern war klar, daß akuter Handlungsbedarf im Bereich der Hard- und Software bestand. Das Projekt bestand aus sechs Schritten: Schwachstellenanalyse des laufenden Systems, Anforderungen an neues System (Hardware und Software), Auswahl und Test der Komponenten (Hardware und Software), Implementierung, Praxisübergabe sowie Ablösung der Altsysteme.
Die Anforderungen an Soft- und Hardware ergaben sich aus der Schwachstellenanalyse: zertifizierte SAP-R/3-Schnittstelle, Unterstützung unterschiedlicher Betriebssysteme, maximaler Automatisierungsgrad, Versionskontrolle der Sicherungen, Unterstützung bei Desaster Recovery, Überwachung von Sicherungen der Außenstellen sowie bei der Hardware Ausfallsicherheit, Verfügbarkeit und Kapazitätserweiterung bei Bedarf.
Die Auswahl der Komponenten gestaltete sich relativ einfach. Mit Unterstützung der Firma TIM GmbH wurden Vorschläge für Hard- und Software erarbeitet. Das künftige Datenvolumen wurde auf 180 GB geschätzt, was inklusive Versionskontrolle einen Datenbestand von zirka 840 GB bedeutete. Damit war schon aus Kostensicht klar, daß als Speichermedium nur der Einsatz von Bändern in Frage kam.
Die Zitterpartien mit den Vier-Millimeter-DAT-Bändern und -Laufwerken steckten noch so in den Knochen, daß die Ablösung durch DLT-Tapes quasi beschlossen war. Aufgrund der geschätzten Datenmenge wurde der Einsatz eines Roboters/DLT Library notwendig. Die Wahl fiel auf den "Adic Scalar" mit drei 400er DLT-Laufwerken.
Die Auswahl der Softwareprodukte war aufgrund des K.-o.-Kriteriums R/3-Zertifizierung gering: Nur "Hiback" der Firma Hinrichs & Hinrichs erfüllte das Merkmal. Nichtsdestoweniger wurden auch andere Produkte untersucht: "Cheyenne ARC Serve", "Legato Networker", "IBM ADSM", "Ultrabac" sowie nochmals Backup Exec. Die Produkte zeigten zumeist eine sehr erfreuliche Bedieneroberfläche, unterschieden sich aber stark in ihren Funktionalitäten. Je nachdem fehlten einige der folgenden Features: pre-/postprocessing Jobs zur Datenbanksicherung (zum Beispiel für Oracle), Unterstützung von DLT-Roboter-Devices (Adic Scalar), SAP-R/3-Zertifizierung, Integration von Nicht-NT-Plattformen, Versionskontrolle und Unterstützung von Desaster Recovery. Einzig Hiback und IBM ADSM waren erfreulich weit entwickelt. Gegen ADSM sprach damals, daß die Freigabe für NT noch ausstand. Das Produkt wurde nach dieser Vorauswahl genauer untersucht. Die Benutzeroberfläche war sehr gewöhnungsbedürftig, alle anderen Produkte waren übersichtlicher, komfortabler und mit genießbaren Hilfemenüs versehen. Es war unübersehbar, daß Hiback nicht von einem Anwender, sondern von einem Entwickler designed wurde: Die angebotenen Help-Menüs waren quasi nicht brauchbar. Hier half im Fehlerfall nur der direkte Draht zum Hersteller und Entwickler.
Der tiefere Einstieg in das Produkt offenbarte die Stärken: Jeder zu sichernde Server wird mit einem Client-Modul ausgestattet, das zu sichernde Daten bereits lokal komprimiert und die um bis zu 50 Prozent niedrigere Datenmenge übers Netz schickt. Dadurch und mit dem im Test befindlichen DLT-Roboter erhöhte sich der Datendurchsatz auf zirka 3 bis 4 GB pro Stunde; eine respektable Größenordnung für einen 16-Mbit-Token-Ring.
Einfach zeigte sich auch die Implementierung in R/3. Die Anbindung erfolgte über die Backint-Schnittstelle von SAP und war innerhalb von 20 Minuten aufgebaut. Dabei stellt Hiback über diese Schnittstelle dem R/3 die gesamten Sicherungs-Devices zur Verfügung, das heißt, die R/3-Sicherung läuft unter der Kontrolle des R/3-Systems mit Bereitstellung der Ressourcen durch Hiback ab.
Ein weiterer Vorteil ist die Unabhängigkeit der beschriebenen Bänder von Sicherungs-Devices und Datenbanken: Alle Informationen befinden sich auf dem Band. Im Gegensatz zu ADSM, wo nur das Zusammenspiel von Bändern und einer auf dem Server vorgehaltenen Datenbank einen Zugriff auf Sicherungskopien erlaubt, können mit Hiback gesicherte Daten auf allen (mediengerechten) Devices wiederaufgesetzt werden. Die Funktionalität war insgesamt überzeugend. Der fade Eindruck der mangelhaften Benutzeroberfläche fiel deshalb weniger ins Gewicht, weil das künftige Backup-Operating aus wenigen Mitarbeitern bestehen sollte und diesen bei gezielter Schulung die Mängel als vermittelbar erschienen.
Mit dem Roboter Adic Scalar gab es anfängliche Schwierigkeiten bei der Justierung des Greifers sowie zwei Laufwerken. Nach Austausch der Komponenten lief die Hardware fehlerfrei (anstelle des angestrebten Vier-Stunden-vor-Ort-Services kann TIM GmbH leider nur den Acht-Stunden-vor-Ort-Service bieten).
Auch aufgrund mangelnder Alternativen fiel die Entscheidung zugunsten von Hiback eindeutig aus. Die nachfolgende Implementierung war durch den Paralleltest mit dem bestehenden System quasi geschafft (eine De-facto-Abhängigkeit vom Testsystem bestand seit Wochen); die wichtigsten Server wurden bereits über beide Systeme gesichert, die weniger kritischen Server wurden jetzt mit in die Sicherung aufgenommen. Gleichzeitig wurde die entsprechende Dokumentation angefertigt, die das Konzept, Vorgehensweisen in Sonderfällen sowie das tägliche Operating beschreibt. Praxisübergabe und Ablösung der Altsysteme folgten wenig später. Vor kurzem wurde mit dem Zusatzprodukt "Hibars" die Möglichkeit geschaffen, alle im Netzwerk betriebenen Sicherungen zentral zu steuern und zu überwachen. Am Horizont ist erkennbar, daß eine weitere Software für HSM vonnöten sein wird, da Hiback diese Funktionalität nicht bietet.
Damit waren alle wichtigen Zielsetzungen erfüllt. Im täglichen Betrieb lassen sich die inzwischen 1,6 TB mit einem Aufwand von zirka 30 Minuten gut verwalten, vorher wurde für ein Zehntel des Volumens die dreifache Zeit benötigt.
Angeklickt
Obwohl zahlreiche Soft- und Hardwareprodukte für Backup-Lösungen angeboten werden, erfüllten für die Shell AG nur wenige von ihnen die Kriterien, die eine ausgewogene, durchdachte und im Ernstfall funktionierende Umgebung ermöglichen. Den Leistungsversprechen der Hersteller stehen die Entwickler der Betriebssysteme gegenüber: Beispielsweise wurde mit dem "Service Pack 3" für NT 4.0 die Struktur der Registry geändert, so daß ihre Sicherung nicht ohne Anpassung der Software möglich war.
*Jan-Ullrich Kath ist Projektleiter bei der deutschen Shell AG in Hamburg.