Flexible Datensicherung für den Produktiveinsatz

Auch Daten haben kein ewiges Leben, aber viele zumindest einen sanften Tod: Sie verdämmern ihre letzten Tage friedlich auf dem Altenteil im hintersten Winkel des Filesystems, leiden still unter Bedeutungsverlust und schwindender Aktualität, bis sie ein gnädiger Löschlauf endlich erlöst.

Gut versichert

Immer wieder werden aber auch aktuelle Daten plötzlich und unverhofft aus dem Dasein gerissen. Oft durch einen Unfall, etwa die Bruchlandung eines Schreibkopfs, manchmal auch durch einen Benutzer, der sie mit einem unbedachten Tastendruck ins Jenseits befördert. Auch erscheint der Sensenmann ihnen zuweilen in Gestalt einer Amok laufenden Applikation.

Glücklicherweise gibt es jedoch für sie (und den Admin, dem sie anvertraut sind) eine Lebensversicherung, die ihnen sogar die Auferstehung garantiert: das Backup. Die Konditionen dieser Versicherung fallen allerdings sehr unterschiedlich aus. Preiswerte Policen bieten einfache Skripte, die mit einschlägigen Kommandos des Betriebssystems (»tar«, »dd«, »cpio«) vorsorgen. Für den lokalen Einsatz oder Kleingruppen reicht eine solche Lösung mitunter aus.

Die Mittelklasse übernimmt das Prinzip, bedient sich aber ausgefeilterer Techniken (Rsync-Skripte, Amanda). Bei beiden Varianten findet sich manchmal nur im Kleingedruckten ein Hinweis auf eine Obergrenze für die Datenmenge, enormen Zeitbedarf, nötige Scripting-Kenntnisse, bescheidene Hardware-Unterstützung oder die fehlende Eignung für eine zentralisierte Datensicherung.

Die Oberklasse kennt solche Beschränkungen nicht, verlangt dafür aber gepfefferte Prämien. Doch es gibt Ausnahmen. Eine davon ist Bacula[1], eine freie Backupsoftware, die etliche Fea- tures bietet, die sonst der kommerziellen Konkurrenz vorbehalten sind.

Ein Unterschied zum schlichten Backupskript fällt sofort auf: Bacula ist kein Monolith, sondern ein Set aus Daemons und einer Schnittstelle zum Benutzer. Die Daemons haben jeweils abgegrenzte Verantwortungsbereiche und kommunizieren untereinander übers Netzwerk. Das ermöglicht gewissermaßen eine Trennung von Exekutive und Legislative: Die Kontrollinstanz läuft auf dem Rechner des Administrators, die Buchführung übernimmt ein Datenbankserver, der die Infrastruktur bereits mitbringt.

Die eigentliche Ausführung, also das Lesen der Daten und das Sichern auf ein Backupmedium, obliegt einem Team aus File-Daemons auf den Klienten und Storage-Daemons auf zentralen Backupservern. Bei Bedarf lassen sich beliebige Funktionen auch wieder auf einer Maschine zusammenfassen. Das ist die Grundlage für eine flexible, anpassungsfähige und gut skalierbare Architektur (Abbildung 1).

Zentrale Leitung

Der Boss der Daemons nennt sich standesgemäß Director. Er weiß, was wann wohin zu sichern ist und wo sich die Files für ein Recovery befinden, kennt die Zeitpläne (Schedules), Klienten, Ablageorte und die Details der geplanten Arbeiten. Der Director ruft die ihm untergebenen Daemons nach einem Zeitplan zur Arbeit. Ihm allein ist es außerdem vorbehalten, über die Konsole mit dem menschlichen Benutzer zu kommunizieren.

Die Eckdaten der Konfiguration merkt sich der Director in einem Ascii-File (»bacula-dir.conf«) in Form hierarchisch gegliederter Ressourcen-Beschreibungen. An oberster Stelle der Rangordnung steht die Job-Ressource, die alle Einstellungen für einen bestimmten Arbeitsgang zusammenfasst. Dazu zählen zum Beispiel dessen Typ (Backup, Restore, Verify oder Admin), der Ausführungszeitpunkt und der zugehörige Level (für ein Backup: Full, Incremental oder Differential, siehe[2]).

Die meisten Einzelheiten sind der Übersicht halber in Unter-Ressourcen gruppiert, den so genannten Direktiven. Die Gemeinsamkeiten ähnlicher Jobs können darüber hinaus »JobDefs«-Ressourcen zu einem Prototyp für eine Klasse verwandter Jobs zusammenfassen, auf den sich dann andere Jobbeschreibungen beziehen. Das strafft das Konfigurationsfile und spart Tipparbeit.