Beim Backup ist das Ob keine Frage, das Wie aber schon. Wo Skripte nicht mehr weiterhelfen, wird die freie Backupsoftware Bacula auch professionellen Ansprüchen gerecht.

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.

Datenwahl

So definiert etwa der Ressourcentyp »Schedule« Zeitpläne, die Jobs in bestimmten Intervallen starten, wobei praktisch jedes Muster realisierbar ist. Ein »FileSet« listet alle zu sichernden Verzeichnisse und Files. Verzeichnisse werden dabei rekursiv behandelt, sodass man im einfachsten Fall für ein Vollbackup nur »/« anzugeben braucht, vielleicht ergänzt um ein paar Ausschlussbedingungen, zum Beispiel für »/tmp« oder versteckte Dateien wie ».journal« oder ».fsck«.

Allerdings kreuzt das Backup nur auf ausdrücklichen Wunsch Filesystemgrenzen, nicht per Default. Es geht so der Gefahr von Endlosschleifen oder versehentlich mitgesicherten Fileservern aus dem Wege. Wer diese Vorsichtsmaßnahme beibehalten möchte, zählt für die Sicherung eines Klienten alle gemounteten lokalen Filesysteme explizit auf.

Es geht aber auch komplizierter. So kann man auf externe Filelisten referenzieren oder Shell-Ausdrücke beziehungsweise -Skripte angeben, die solche Listen zur Laufzeit des Backups produzieren. Weil in Inline-Shellkommandos der Konfiguration alle Sonder- und Leerzeichen aufwändig zu maskieren sind, machen Skripte oft weniger Umstände.

Soll ein Job zum Beispiel alle Konfigurationsfiles in »/etc« und alle versteckten Files und Verzeichnisse im Homedirectory des Users »jcb« sichern, wäre dafür das folgende Mini-Skript geeignet:

#!/bin/sh
find /home/jcb -maxdepth 1 -name ".*"
find /etc -name "*.conf"

Ein File-Set, das sich auf die damit gelieferten Daten bezieht, sähe so aus:

FileSet {
  name = "ConfigSet"
    include {
      Options {
        signature = MD5
      }
      File = "|/etc/bacula/confbackup.sh"
    }
}

Neben Files, Listen oder Skripten kann der Admin auch Raw Devices als Datenquelle angeben (sie dürfen allerdings während der Sicherung höchstens read-only gemountet sein). Außerdem kann das Backup seine Daten sogar aus Fifos beziehen, die eine laufende Applikation mit dem Backup koppeln. Die außergewöhnliche Flexibilität bei der Datenauswahl hat allerdings ihren Preis: Sie ist wesentlich weniger intuitiv als ein File-Browser, in dem die gewünschten Files grafisch markierbar sind. Ideal wäre es, wenn der Anwender zwischen beiden Verfahren wählen könnte.

Abbildung 1: Getrennt marschieren, vereint schlagen – das Preußen-Motto ist auch Baculas Devise: Die Backup-Funktionen verteilen sich im Netz, die Speicherung geschieht zentral.

Abbildung 2: Eine bescheidene Hilfestellung für die Konfiguration des Directory-Daemon bietet JBacula, das in einem eigenen Projekt entwickelt wird. Die wichtigsten Optionen sind aus Menüs wählbar, Tooltips leisten Hilfe.

Ausstattung: Mit Pool

Eine andere Konfigurations-Direktive definiert Volume-Pools und markiert damit einen zweiten wesentlichen Unterschied zu einfacher gestrickten Lösungen. Ein Pool fasst eine Anzahl Bänder zu einer logischen Gruppe zusammen und ermöglicht es damit dem Backup, die Kapazitätsgrenzen eines einzelnen physischen Tape zu überwinden. Erreicht die Sicherung das Bandende, setzt Bacula sie automatisch auf dem nächsten verfügbaren Band desselben Pools fort. Dabei kann es automatisch ältere Bänder der Gruppe nach Ablauf einer einstellbaren Verfallszeit recyceln.

An die Pool-Ressource sind diverse Voreinstellungen gebunden, etwa die erwähnte Wartezeit bis zur möglichen Wiederverwendung der Medien oder die maximale Zahl der Einsätze. Sie gelten damit für alle Bänder des Pools. Der Admin muss sie also nicht für jedes Medium der Gruppe eingeben, kann sie aber im Bedarfsfall überschreiben.

Weiter dienen die Pools dazu, Bänder nach Verwendungszweck zu separieren. So lässt sich zum Beispiel verhindern, dass sich inkrementelle Sicherungen und Vollbackups in die Quere kommen oder gar gegenseitig überschreiben, indem man die jeweiligen Bänder verschiedenen Pools zuweist. Entsprechend sind auch Pools für einzelne Klienten, Wochentage und so weiter möglich.

Soll der Bandwechsel automatisch ablaufen, setzt das natürlich eine Tape-Library voraus. Bacula kooperiert mit einer Anzahl solcher auch Autochanger oder Autoloader genannten Bandroboter mit DAT-, VXA2-, DLT-, LTO- und AIT-Laufwerken[3].

Das Hilfsprogramm Mtx[4], das Bacula für die Ansteuerung dieser Libraries verwendet, unterstützt übrigens sogar Barcode-Labels, mit denen der Bandroboter ein Tape identifiziert, ohne es zuvor in ein Laufwerk zu laden. In manchen Fällen – wenn zum Beispiel Bänder innerhalb der Library manuell umgeräumt wurden – müssen die tatsächlichen mit den früher gespeicherten Ablageorten neu abgeglichen werden. Spätestens bei dieser Gelegenheit wird der Admin dies Feature schätzen lernen, denn es beschleunigt die Inventarisierung um ein Vielfaches.

Katalogisiert

Zu jedem File, das Bacula auf Band sichert, merkt es sich eine Fülle von Einzelheiten wie Größe, Attribute, Signatur, Änderungsdatum oder Zeitpunkt und Ort der Sicherung in einer Datenbank, dem Catalog. Dieses Verzeichnis ist der dritte große Unterschied zu einer simplen Sicherung mit Skripten der Marke Eigenbau, ermöglicht es doch das gezielte Recovery einzelner Files, ohne dass die Software dafür das komplette Archiv lesen muss. Die Auswahl wiederherzustellender Files geschieht allein anhand der Metadaten.

Zu diesen Metadaten gehört auch die Position der gewünschten Files auf dem Band. Das muss Bacula deshalb nicht sequenziell von Anfang an durchforsten, sondern kann zumindest den Beginn des Jobs gezielt anfahren. Darüber hinaus archiviert der Catalog eine Historie alle Sicherungen.

Bacula verwaltet den Catalog mit jeder gängigen SQL-Datenbank, es enthält Einrichtungsskripte für PostgreSQL, MySQL und SQLite. Das ist sogar im Vergleich mit mancher kommerziellen Lösung ein Vorteil, weil eigene Sicherungen der Datenbank und im Ernstfall sogar manuelle Eingriffe leicht möglich sind. Schließlich zählt ein verlorener oder inkonsistenter Katalog bei darauf basierender Backupsoftware zu den ernsten (zumindest zeitintensiven) Problemen für den Admin. Daher liegen auch gleich Skripte bei, die den Katalog automatisch in einem Ascii-File sichern, während ein Job läuft. Sollte dabei etwas schiefgehen, ist zumindest die letzte Version schnell wieder verfügbar.

Baculas Verzeichnis der gesicherten Files lässt sich übrigens auch für eine einfache Form der Intrusion Detection à la Tripwire oder Aide verwenden. Zwei eingebaute Funktionen, die von Backup oder Recovery unabhängig startbar sind, dienen speziell dem Sammeln der Metadaten und dem Abgleich mit dem Filesystem. Dabei entdecken sie möglicherweise nicht autorisierte Änderungen.

Teamwork

Ein Direktor wäre nichts ohne sein Personal. In Bacula stehen dem Chef zwei Gruppen von Bediensteten zur Verfügung: Ein oder mehrere Storage-Daemons und eine Anzahl File-Daemons. Letztere laufen auf den Clients und liefern via Netzwerk die zu sichernden Daten an den Storage-Server, auf dem der gleichnamige Daemon tätig ist und das Bandlaufwerk oder die Library bedient. Im Bedarfsfall kann er übrigens genauso gut auf Festplatten sichern, was angesichts der fallenden Plattenpreise zumindest für eine kurz- oder mittelfristige Pufferung der letzten Backups ein überlegenswertes Thema ist (Disk-to-Disk-to-Tape).

File-Daemons gibt es für Linux, die meisten Unix-artigen Betriebssysteme (zum Beispiel Solaris, AIX, HPUX, FreeBSD und sogar Mac OS X) sowie alle Windows-Versionen. Damit ist der Umweg über Samba oder NFS wohl selten erforderlich. Wenn doch, bleibt er selbstverständlich möglich.

Abbildung 3: Noch kein GUI, aber zumindest eine grafische Konsole, die kein Terminalfenster braucht und ein paar Menüs bietet: GConsole.

Kommando zurück

Bei einem Recovery läuft der Prozess in umgekehrter Reihenfolge ab: Angestoßen vom Director schickt der Storage-Daemon die wiederherzustellenden Daten an einen File-Daemon, der sie auf dem Client speichert. Normalerweise landen sie dabei nicht wieder an ihrem Ursprungsort, stattdessen wird der komplette gesicherte Verzeichnisbaum unter einem besonderen Directory rekonstruiert. Dieses Verzeichnis lässt sich in der Beschreibung des Restore-Jobs konfigurieren und sollte in einem Filesystem mit ausreichenden Kapazitätsreserven liegen, als Default ist »/tmp/bacula-restores« eingestellt.

Dieses Verhalten lässt sich ändern, wenn man das Root-Directory als Ziel des Recovery angibt. Dann gelangen die geretteten Files wieder an jenen Ort, von dem sie ursprünglich gesichert wurden. Dabei ist allerdings Vorsicht geboten: Bacula kennt keine der üblichen Strategien zur Konfliktvermeidung. Existiert ein recovertes File bereits, wird es weder geschützt noch umbenannt, sondern kommentarlos überschrieben, was nicht immer gewünscht ist.

Für die Auswahl der rückzusichernden Files gibt es mehrere Verfahren. Alle münden in einer virtuellen Verzeichnishierarchie, die alle Dateien widerspiegelt, die als Ergebnis bestimmter, vorangegangener Backupjobs auf die Bänder gelangt sind. Der Verzeichnisbaum lässt sich in der Konsole mit den Unix-typischen Kommandos durchsuchen und betrachten (»cd«, »ls«, »pwd« und so weiter). Der Admin markiert die gewünschten Files und Verzeichnisse per Kommando für die Wiederherstellung. (Auch hierbei wäre eine grafische File-Auswahl wünschenswert – zumindest als Alternative zur Kommandozeile.)

Als besonders nützlichen Service kann Bacula in dem erwähnten virtuellen Filesystem auch das letzte Vollbackup eines Klienten und alle darauf folgenden inkrementellen Sicherungen zu dem aktuell verfügbaren Stand kombinieren. Außerdem ist es möglich, die Auswahl auf alle vor oder nach einem bestimmten Zeitpunkt gesicherte Files einzuschränken.

Aktuelle Knoppix-Versionen[6] enthalten bereits einen Bacula-File-Daemon plus Konsole und eignen sich damit als einfache Lösung für das Desaster Recovery, wenn man zusätzlich die Partitionierung aller gesicherten Platten irgendwo notiert und vielleicht auch noch Baculas Bootstrap-Files separat gesichert hat. Früher gab es eine Bacula-Recovery-CD, die die Wiederbelebung nach einem Totalausfall weiter automatisieren sollte. Sie funktioniert aber nicht mit neueren Linux-Kernels (2.6.x). Ein Remake ist in der Diskussion.

Gewaltenteilung

Der Zugang zur Bacula-Konsole ist nur durch die Ausführungsrechte der Benutzer reglementiert, die Anwendung selbst erfordert keine gesonderte Authentifizierung und kann folglich keine verschieden privilegierten Benutzer unterscheiden. Es lassen sich jedoch Varianten der Console-Applikation konfigurieren, die nur bestimmte Jobs ausführen oder bestimmte Kommandos, File-Sets, Medien-Pools oder Devices verwenden. Das erzielt durch die Hintertür einen ähnlichen Effekt, wie ihn eine eigene Benutzerverwaltung bietet.

Die Granularität reicht zwar nicht aus, um es mit vernünftigem Aufwand jedem Anwender zu erlauben, ausschließlich seine Files ohne Hilfe des Administrators wiederherzustellen, sie genügt aber sehr wohl für abgegrenzte Aufgabenbereiche innerhalb einer Administratorengruppe. Die Benutzer wären in vielen Fällen ohnehin überfordert, denn vollständig mit der Maus bedienbare grafische Oberflächen gibt es bei Bacula nicht.

Aus gutem Grund enthalten auch die beiden grafischen Tools Wxconsole und GConsole, die dank einiger Menüs die Merk- und Tippfähigkeit nicht ganz so beanspruchen, immer auch eine Kommandozeile für anders nicht erreichbare Funktionen. Das separat entwickelte, Java-basierte JBacula[5] hilft durch eine Bildschirmmaske und Tooltips ansatzweise bei der Konfiguration des Directory-Daemon (Abbildung 2).

Fazit

Ein Administrator, der die Kommandozeile nicht scheut, dem als Backupmedien Festplatten, einzelne Bandlaufwerke oder eine mittelgroße Library ausreichend Platz für seine Datensicherungen bieten und der zudem auf keine Applikationen Rücksicht nehmen muss, die nur online und nur mit spezieller Software zu sichern sind, dieser Admin findet in Bacula eine sehr gute und dabei kostenlose Backupsoftware mit zahlreichen professionellen Features.

Bacula ist dank seiner verteilten Architektur gut skalierbar und lässt sich an viele Bedürfnisse außergewöhnlich gut anpassen. Das gilt beispielsweise auch für solche Umgebungen, die sich über mehrere Subnetze erstrecken und eventuell Außenstellen oder besonders gesicherte Bereiche einbeziehen. Die Software ist zudem gut dokumentiert und ermöglicht es, ohne allzu großen Aufwand in einer heterogenen Systemlandschaft alle Daten zuverlässig und zentralisiert zu sichern. Das ist, wie gesagt, auch für den Admin eine Art Lebensversicherung – und zwar zu sehr günstigen Konditionen.