Bild 1: Hierarchical Storage Management im Überblick.

Auch die zuverlässigste Festplatte wird eines Tages sterben. Nur regelmäßige Backups können den Daten-GAU verhindern. Der Einleitungsartikel unseres Schwerpunkts beleuchtet die Strategien.

Wirksame Datensicherung macht insbesondere angesichts explodierender Dateigrößen eine vernünftige Verwaltung der Daten nötig. Moderne Datensicherung ist längst viel mehr als nur das Abziehen der Daten auf eine Bandkassette. Das betrifft nicht nur die Wahl der Backup-Soft- und Hardware, sondern auch die Konfiguration der Daten-Server und letztlich auch das Benutzerverhalten.

Die User stellen sich gerne auf den Standpunkt, dass sie sich selbst nicht um Technik kümmern mögen; der Administrator solle mit derartigen Problemen allein klarzukommen. Plattenplatz wird eher früher als später voll. Kooperative User tragen durch Aufräumen, Komprimieren und Packen zur Übersicht bei.

Langzeitarchivierung

Vom Backup zu unterscheiden ist die Offline-Lagerung von Daten. Während beim Backup meist davon ausgegangen wird, dass man nur Daten aus nicht allzu weiter Vergangenheit, zum Beispiel drei Monate, zur Wiederherstellung braucht, gilt dies für Archivierungen nicht. Kandidaten für Ar-chivierungen sind Daten, die aktuell nicht mehr benötigt werden, aber später wieder wichtig werden (könnten). Archivierungen – eventuell auf mehrere Medien als “Clone” – sollten zum Standardrepertoire beim Verwalten der Daten im Rechnerverbund gehören. Diese Funktion muss nicht unbedingt vom verwendeten Backup-System erfüllt werden. Ein tar oder cpio auf mehrere redundante Bänder mit Beschriftung reicht meist.

Hierarchical Storage Management

Eine sehr reizvolle Technik, die gerne in die Diskussion gebracht wird, ist HSM, etwa von Veritas [8] oder SAM-FS von LSC. Hierbei werden Daten in einem bestimmten Zeitraum von der Platte auf langsamere und preiswertere Medien kopiert. Diesen Schritt bezeichnet man als “Archiving”.

Bild 1: Hierarchical Storage Management im Überblick.

Daten, auf die eine gewisse Zeitlang niemand zugreift, werden vom Online-Medium entfernt (“released”). Der Filesystem-Eintrag bleibt erhalten, nur die Datenblöcke verschwinden.

Spätere Zugriffe auf Daten, die sich nicht mehr auf der Platte befinden, führen zum “Staging”. Das bedeutet, dass vollautomatisch die Daten wieder von den langsameren Medien abgeholt und verfügbar gemacht werden, was natürlich etwas dauern kann. HSM kann nicht ohne Unterstützung durch das Filesystem realisiert werden, da die beschriebenen Vorgänge für die User-Prozesse beziehungsweise deren Systemcalls unsichtbar sein sollen.

HSM in der einfachsten Form ersetzt nicht das Backup. Sind die Daten vom Online-Medium verschwunden, sind sie nur noch einmal vorhanden. Geht dann beispielsweise das Band kaputt, auf dem sie sich befinden, müssen sie von woanders wiederhergestellt werden. HSM-Systeme bieten daher die Möglichkeit, gleich mehrere Kopien anzufertigen.

Umfang und Zeitpunkt einer Sicherung

Die Ergebnisse der täglichen Arbeit müssen ins Backup. Aber sicher sollen die Sicherungskapazitäten nicht unbedingt mit Dingen voll gestopft werden, welche ohnehin auf CD oder im Internet verfügbar sind. Hierzu gehören etwa die Betriebssysteme. Eine Rechnerlandschaft wird aber normalerweise nicht mit unveränderten Systeminstallationen ausgestattet sein. Anpassungen an die jeweiligen Erfordernisse sind immer nötig.

Die Software sollte neben der Sicherung aller Daten auch den Modus inkrementell beherrschen. Das bedeutet, dass nur die Dateien ins Backup geschrieben werden, welche sich seit dem letzten Backup geändert haben.

Oft sind zusätzlich Backups vom Typ Level-N möglich mit N = 1, 2, … Bei einem Level-N Backup werden alle Daten gesichert, die sich seit dem letzten Backup mit demselben Level verändert haben. Dabei kann man sich vorstellen, dass ein Gesamt-Backup den Level 0 und ein inkrementelles den Level Unendlich hat.

Bei einem Level-3-Backup wird alles Neue seit dem letzten Level-3-, Level-4-, oder einem inkrementellen Backup gesichert. Die Software Afbackup [1] des Autors wertet das anders herum aus, damit man offen zu höheren Leveln ist.

Typisch ist eine Gesamtsicherung an jedem Wochenende mit inkrementellen Sicherungen jede Nacht. Eine andere Möglichkeit sind Gesamtsicherungen an jedem ersten Wochenende im Monat und ein Level-1-Backup an den anderen Wochenenden mit inkrementellen Sicherungen jede Nacht. Je länger eine Gesamtsicherung zurückliegt, desto länger dauert womöglich die Wiederherstellung. Grundsätzlich sollte keine Sicherung laufen, während viele Leute arbeiten, da das Backup eine erhebliche Last für die betroffenen Rechner und das Netzwerk darstellt.

Es kann wünschenswert sein, mehrere Rechner gleichzeitig zu sichern. Falls das Ziel der Daten aber nur ein einzelner Backupserver oder ein Bandlaufwerk ist, muss die Backup-Software eine solche Betriebsart unterstützen. Wenn mehrere Rechner viele Daten haben, ist ein paralleler Start besonders von inkrementellen Backups sehr hilfreich. Ein anderes Beispiel sind viele Backup-Clients, die über langsame Leitungen auf einen zentralen Server sichern, wobei man aber nur dann etwas von der Parallelisierung hat, wenn sich die Durchsätze am Server aufsummieren können.

Bänder gehen mit unter kaputt. Daher gehen nicht wenige Administratoren so vor, dass sie bei jedem Gesamt-Backup die Verwendung eines neuen Bandes konfigurieren. Auf diese Weise hat man immer eine gesamte Sicherung verfügbar, die maximal ein Intervall zwischen zwei Vollsicherungen zurückliegt, auch wenn ein einzelnes Band ausfällt. Mehrfache Sicherungen derselben Daten auf verschiedene Medien können neben der höheren Redundanz günstig für die User sein.

Konfiguriert man nur eine Gesamtsicherung auf Platten bei längere Zeit aufgehobenen Sicherungen auf Band, hat man ein schnelles Restore der aktuellen Dateien von den Festplatten bei gleichzeitiger Sicherheit.

Das Sicherungsziel

Bei den heutigen Plattenpreisen ist es eine Überlegung wert, auf Festplatten zu sichern. Dabei sind die erzielbaren Durchsätze selbst bei langsamen Platten höher als bei den gängigen Bandtechnologien. Dennoch besteht ein deutlicher Preisunterschied zugunsten von Bändern: Ein DLT mit zirka 65 GByte Kapazität ohne Kompression kostet etwa 100 Mark, dafür bekommt man noch keine Platte dieser Kapazität. Zudem sind Bandwechsel gut automatisierbar .

Bandtechnologien

Vor dem Kauf eines Bandlaufwerks oder eines Wechslers steht die Qual der Wahl. Viele Technologien buhlen um die Gunst der Käufer. Im Folgenden werden die wichtigsten von ihnen vorgestellt. Die Entscheidung für eine der beschriebenen Technologien sollte primär von der zu sichernden Datenmenge abhängen, dann vom Preis der Laufwerke und der Bänder.

Quarter-Inch-Cartridges

QIC spielen in der Systemverwaltung kaum noch eine Rolle, aber im privaten Einsatz sind sie noch vielfältig zu finden, weil die Laufwerke besonders preiswert sind und für Heimanwender akzeptable Kapazitäten bieten.

QIC zeichnet linear in Serpentinen auf, das Band wird in hoher Geschwindigkeit am Kopf vorbei gezogen, und sobald das Bandende erreicht ist, wird der Kopf angehoben und wieder das gesamte Band durchgezogen. So bekommt man mit kostengünstiger Mechanik Kapazität und Geschwindigkeit. Beim Kauf solcher Laufwerke ist jedoch darauf zu achten, dass sie Read-after-Write beherrschen – der Datensicherheit zuliebe.

Exabyte

Aus der Technik von Video-8 abgeleitet, galten die Bänder wegen enger Bandführungsradien, weiter Kopfumschlingung und der resultierenden Beanspruchung als verschleißanfällig. Bei neueren Produkten sollen diese Probleme behoben sein, doch es gibt andere Schwierigkeiten. Schiebt man ein Band zum Lesen in ein nicht baugleiches Laufwerk, funktioniert das Lesen nicht immer. Das passiert auch bei Laufwerken desselben Herstellers.

Mit dem typischen Problem die Blockgrößen richtig einzustellen, das oft in Newsgroups auftaucht, hat dies nichts zu tun. Bei Ausfall eines Laufwerks sollte also ein baugleicher Ersatz in Reichweite sein. Exabyte erreicht derzeit Kapazitäten bis 60 GByte pro Band (unkomprimiert).

DAT

Die Kapazitätsangaben bei DAT sind in der Regel mit unrealistisch hohen Kompressionsraten ermittelt. In der Praxis ist nur der unkomprimierte Wert von Relevanz. Wegen des relativ großen “Verschnitts” infolge fauler Bandstellen (“Drops”) liegt die real erzielte Menge in der Regel darunter. Erschwerend kommt hinzu, dass DAT-Laufwerke nach dem DDS-3-Standard die Verschmutzung des Kopfes meist zu spät erkennen und melden.

Ein Phänomen, welches häufiger auftritt, sind die beim schnellen Suchen auf dem Band übersehenen Markierungen. Das kann dazu führen, dass Daten nicht gefunden oder schlimmstenfalls Bandteile überschrieben werden, ohne, dass es zunächst auffällt. Ab DDS-3 wird der Kopf automatisch im Laufwerk bei Betrieb relativ oft gereinigt.

Daraus soll aber keine übermäßige Abnutzung resultieren. Es ist dringend anzuraten, bei DAT die Reinigungsintervalle einzuhalten, welche die Hersteller in der Begleitdokumentation empfehlen (aber nicht übertreiben). DAT erreicht mit DDS-4 theoretisch unkomprimierte 20 GByte.

Digital Linear Tape

DLT wurde für hohe Dichten, geringen mechanischen Verschleiß und hohe Aufzeichnungsgeschwindigkeiten entwickelt. Probleme kann es mitunter beim Ausfädeln des Bandes geben, die zweite Spule befindet sich im Bandlaufwerk. Schlimmstenfalls wird dabei der Anfang des Bandes in Mitleidenschaft gezogen, wodurch es unbenutzbar wird. Am Bandanfang befinden sich laufwerksverwaltete Informationen. Sind diese nicht auswertbar, akzeptiert das Laufwerk das Band schon beim Einlegen nicht. Bei der AIT-Technologie von Sony wird deshalb extra ein beschreibbarer Chip in den Kassetten verbaut.

Der Weg zur Datensicherung

Eine einfache und leistungsfähige Variante ist der direkte Anschluss des Laufwerks an den jeweiligen Fileserver. Hierbei wird auch das Netzwerk nicht belastet und eventuelle Securityüberlegungen bezüglich abgehörter Daten sind nicht nötig. Brennt allerdings der Server ab, sind die Bänder nicht zu retten. Dieses Problem kann man durch regelmäßige Entnahme und Lagerung an anderem Ort etwas entschärfen. Die entscheidende Frage ist, welche Zeiträume ohne Sicherung akzeptabel sind.

Bild 2: Backupstrategien

Will man Sicherheit auch bei Gebäudeschäden erreichen, muss man Online-Daten und Backup geografisch trennen. Das erreicht der Administrator mittels Backup übers Netzwerk oder der Einsatz eines geeigneten Bus-Technologie zwischen Rechner und Laufwerk.

Am häufigsten anzutreffen ist die Sicherung über Netzwerk zu einem Rechner, der dann als Backup-Server fungiert. Soll dabei das Netzwerk nicht belastet werden, über welches die Rechner der User bedient werden, kann man die Möglichkeit einer zusätzlichen Netzwerkverbindung zwischen den beiden Rechnern erwägen. Ist Security ein wichtiger Aspekt, werden alle typischen Probleme bei Netzwerkdiensten relevant.

Korrekte Zugriffsrechte

Kann nur derjenige die Backupdaten lesen und schreiben, der das auch darf? Gibt es systematische Hintertüren, die aus der Architektur resultieren? Können Bugs (etwa Buffer-Overflows) zu unberechtigten Zugriffen führen? In jedem Fall müssen die Permissions der Devices in /dev geprüft werden.

Normalerweise besitzt jedermann auf Bändern Schreibrechte; selbst namhafte Backup-Produkte arbeiten so oder geben keine Hinweise in der Dokumentation. Kann hier keine Einschränkung der Rechte durchgeführt werden, ohne dass die Backup-Software den Dienst einstellt, muss überlegt werden, den Backupserver gegen Login durch normale, möglicherweise böswillige Benutzer zu sperren. Diese Überlegung gilt natürlich nicht nur beim Backup über das Netzwerk.

Sichern per Storage Area Network

Eine weitere Möglichkeit kommt seit einiger Zeit in Mode: Backup im Storage Area Network. SAN bedeutet, dass nicht nur eine Verbindung zwischen einem Rechner und Massenspeichern besteht wie an einem SCSI-Bus, sondern dass mehrere Rechner mit mehreren Massenspeicher-Systemen – eventuell auch über mehrere redundante Wege – vernetzt sind. Auf diese Weise können schnelle Verbindungen von allen angeschlossenen Geräten wahlweise benutzt werden, ähnlich der Kommunikation zwischen Rechnern in einem LAN.

Im SAN können auch Backupgeräte (meist Jukeboxen) angeschlossen sein. Die Sicherung der Daten läuft dann nicht über den Fileserver, sondern direkt vom Online-Massenspeicher zum Backupsystem. Bei dieser Datenübertragung wird weder der Fileserverrechner noch das Netzwerk außerhalb des SAN belastet.

Da aber meist Daten aus einem Filesystem gesichert werden, kommt auf die steuernde Software eine weitere Aufgabe zu: Weder Massenspeicher noch Backupgerät kennen die Filesystemstruktur. Diese Information besitzt der Filesystem-Treiber im Server-Betriebssystem exklusiv. Wird eine Datei gesichert, wird dem Massenspeicher mitgeteilt, welche Blöcke er an das Backup-Gerät senden soll. Beim Restore wird es aufwändiger: Die beteiligten Hardwarekomponenten haben bei solchen Installationen Schrankformat und die Software ist teuer. Wer in eine solche Lösung investieren mag, kommt an der Ausarbeitung einer individuellen Strategie unter keinen Umständen vorbei.

Eine weitere Variante sei noch kurz skizziert: Es gibt Geräte (zum Beispiel Celerra von EMC <sup>2 [10], Server von Network Appliance [11] oder Geräte von Transtec [2]), die in einem Gehäuse Massenspeicher und Logik vereinen, so dass sie sich im Netz als reine Fileserver darstellen (“Network Attached Storage”). Sie bieten typischerweise keine anderen Services an und man kann sich auch nicht einloggen. Soll deren Sicherung nicht über den Fileservice im Netzwerk laufen, so besteht die Möglichkeit, direkt an diese Geräte Laufwerke und Wechsler anzuschließen. Backupsoftware auf den Geräten selbst und steuernde Software auf einem Rechner im Netzwerk (NetApp NFS-Server und Veritas NetBackup [8]) ermöglichen dann die Sicherung.


Bei Sicherung über NFS-Mounts muss zum Backup-Zeitpunkt mindestens ein read-only-root-Export vorhanden sein, da sonst lesegeschützte Daten nicht gesichert werden. Beim Restore muss root sogar über NFS schreiben dürfen. Da ein gefälschtes UDP-Paket mit dem Absender des NFS-Client bereits ausreicht, um auf dem NFS-Server Daten zu manipulieren, besteht hier ein potentielles Sicherheitsrisiko.</sup>

Handhabung der Medien

<sup>Wird die Menge der Daten, die in einem Schwung zu sichern sind, größer als die Kapazität eines Bandes, sollte man einen Wechsler (Stacker, Jukebox oder eine Tape-Library) anschaffen. Einfachste Stacker haben beispielsweise ein Laufwerk und sechs Fächer (Slots) für Bänder, die der Roboter dann wechseln kann. Große Jukeboxen besitzen Hunderte Slots sowie sechs oder mehr Laufwerke. Häufig kommen mehrere Loadports oder Loadbays hinzu. Sie erleichtern die Arbeit des Administrators beim Bestücken des Geräts mit Bändern merklich.


Bezüglich der Backup-Software sollte man sich sicherheitshalber beim Hersteller erkundigen, ob der Wechsler unterstützt wird. Meist implementieren die Wechsler aber zumindest eine Untermenge eines Standardprotokolls, mit dem die Hardware über den SCSI-Bus angesteuert werden kann. Softwareseitig können hierzu auch die im Sourcecode verfügbaren Programme mtx oder stc (für Solaris) verwendet werden [1b].</sup>

Backup-Software

<sup>Frei verfügbare Pakete [4] wie beispielsweise Amanda, Burt oder Afbackup [1] des Autors sind hier ebenso interessant wie kommerzielle Software. Eine auszugsweise Auflistung von Backup-Software, die in diesem Heft nicht erwähnt werden, können Sie in den Referenzen auf der Seite 43 nachsehen.


Grundsätzlich gilt bei der Auswahl einer Software dasselbe wie bei allen anderen Produkten. Wer Aussagen eines Herstellers glaubt, ohne sie in einer Teststellung verifiziert zu haben, geht ein Risiko ein. Auf eine Testinstallation sollte auf keinen Fall verzichtet werden. Dabei sollte man mit möglichst realistischen Randbedingungen testen. Die Probleme, die wirklich weh tun, treten erst bei höherer Komplexität unter Nutzung von Kombinationen von Features oder im Zusammenhang mit anderen Komponenten auf.


Bisweilen wird still schweigend an-genommen, dass bestimmte Funktionalitäten vorhanden sind, etwa dass ein Verify (also Vergleich des Inhalts der Sicherung mit dem Filesystem) möglich ist oder dass bei einer Archivierung beim anschließenden Lesen des Bandes ein solcher Vergleich stattfindet. Das muss aber nicht unbedingt so sein.


Ein ziemlich teures Backup- und Archivierungsprodukt liest im An-schluss an eine Archivierung das Band und sendet die Daten über das Netz zu dem Rechner, von dem die Daten stammen. Ein Vergleich mit dem Filesystem erfolgt jedoch nicht. Die Bewertung, wie viel ein Vor- oder Nachteil eines Produkts für den jeweiligen Einsatz bedeutet, ist ein entscheidender Aspekt. Sind Security-Gesichtspunkte wichtig, scheue man sich nicht, strace einzusetzen, tcp-dump, lsof, truss, snoop, oder andere Tools auf dem jeweiligen System.


Außerdem müssen die Permissions geprüft werden, mit denen die Software installiert ist. Fehlt beispielsweise bei für User startbare Programme ein Set-UID-Bit (muss nicht unbedingt Set-UID auf root sein) und wird die Shared Version der Libc benutzt (testen mit ldd), so sind intern implementierte Zugriffsbeschränkungen ziemlich sicher Makulatur, da sie sich durch Umdefinieren von Funktionen wie getuid mit Hilfe der Environment-Variablen LD_PRELOAD recht einfach umgehen lassen.</sup>

Der Index kann ein Problem sein

<sup>Eine typische Eigenschaft der meisten Produkte kann sich auch als Achillesferse herausstellen: Damit man gezielt bestimmte Daten zur Wiederherstellung auswählen kann, verwalten die Systeme einen Online-Index. In ihm ist die gesamte Struktur der gesicherten Verzeichnisbäume abgelegt. Mit einem passenden Programm können User oder Administratoren in den gesicherten Daten navigieren wie in einem Filebrowser und eine Auswahl für das Restore treffen.


Wenn hierbei dieselben Rechtebeschränkungen wirksam werden sollen wie beim Arbeiten im Filesystem, sollten die Rechte, Eigentümer und ACLs hinterlegt sein. Zusätzlich müssen Informationen verwaltet werden wie Sicherungszeitpunkt, Aufbewahrungsort der Daten und das Flag, ob der Dateisystemeintrag wiederherstellbar ist.


Im Grunde wird hier ein Filesystem ohne Datenblöcke aufgebaut, aber mit zusätzlichen Informationen. Je mehr Einträge im zu sichernden Filesystem vorhanden sind, desto größer wird der Index. Wenn im Originalverzeichnis nur leere Dateien oder Symlinks liegen, kann dieser Online-Index, der auch in einem Filesystem liegt, nicht weniger Platz beanspruchen als die Originaldaten. Außerdem unterliegt er Konsistenzanforderungen wie ein Filesystem.</sup>

^{Das bedeutet: Wenn ein Prozess, der den Index manipuliert, unkontrolliert stirbt, kann der Index inkonsistent sein. Dann muss er geprüft und repariert werden, also eine Art fsck laufen. In diesem Fall muss er wiederhergestellt werden oder die Möglichkeit des Navigierens in der Sicherung entfällt. Problematisch ist das Hinterlegen der Flags zur Auswahl im Index. Das führt dazu, dass man keine parallelen Restores auf demselben Client fahren kann, obwohl es theoretisch möglich wäre. Eine Auswahl im Restore-Frontend führt dazu, dass eine andere, vorher getroffene Auswahl zurückgesetzt wird. Das äußert sich darin, dass Teile des ersten Restore nicht wiederhergestellt werden, da die Flags zwischenzeitlich gelöscht wurden. ( okl)}