Next: Bacula installieren Up: Bacula User's Guide Previous: Unterstützte Bandlaufwerke Contents Index
Wenn Sie wie ich sind, wollen Sie dass Bacula sofort läuft, damit Sie ein Gefühl für das Programm bekommen und sich erst später mit den Details befassen. Dieses Kapitel möchte genau dieses erreichen: Das Programm ohne die ganzen Einzelheiten rasch zum Laufen zu bringen. Wenn Sie den Abschnitt über Pools, Volumes und Labels überspringen wollen, können Sie ihn später immer noch nachholen, aber lesen Sie bitte bis zum Ende des Kapitels und beachten Sie die Anweisungen zum Test Ihres Bandlaufwerkes genau.
Wir gehen davon aus, dass Sie es geschafft haben, Bacula zu kompilieren und zu installieren. Wenn nicht, werfen sie vielleicht zuerst einen Blick auf die System-Anforderungen und dann auf das Kapitel Bacula kompilieren und installieren in diesem Handbuch.
Um Bacula so anpassungsfähig wie möglich zu machen, bestehen die Anweisungen, die sein Verhalten bestimmen, aus verschiedenen Teilen. Die wichtigste Direktive ist die Job-Resource, welche jeweils eine Sicherungsaufgabe beschreibt. Ein Sicherungs-Job besteht im allgemeinen aus einem FileSet, einem (Sicherungs-)Client und einem Zeitplan mit einer oder mehreren Arten und Zeiten der Sicherung, einem Pool und zusätzlichen Instruktionen. Mit anderen Worten: Mit dem FileSet wird bestimmt was gesichert werden soll, mit dem Client, wer sichern soll, der Zeitplan bestimmt wann dies geschehen soll und der Pool wohin gesichert werden soll (z.B. auf welches Volume). Typischerweise bestimmt jeweils eine Kombination FileSet/Client einen Job. Die meisten der Direktiven wie FileSets, Pools und Zeitpläne können für mehrere Jobs verwendet werden und so beliebig kombiniert werden. Sie könnten z.B. zwei verschiedene Job-Definitionen (resources) haben, welche die Daten verschiedener Server sichern, dabei aber den gleichen Zeitplan, das gleiche FileSet (auf beiden Rechnern werden die gleichen Verzeichnisse gesichert) und vielleicht sogar die gleichen Pools nutzen. Der Zeitplan wird festlegen, welche Art der Sicherung wann läuft (z.B. Montags eine Vollsicherung, an den übrigen Wochentage inkrementielle Sicherung) und wenn mehr als ein Job den gleichen Zeitplan hat, wird die Job-Priorität bestimmen, welcher Job tatsächlich als erster läuft. Wenn Sie viele Jobs haben, werden Sie möglicherweise JobDefs benutzen wollen, in denen Sie Vorgaben für alle Jobs festlegen, die dann in den einzelnen Job-Resourcen individuell angepasst werden können, es Ihnen aber ersparen, für jeden Job die gleichen Parameter zu definieren. Zusätzlich zu den durch die FileSets festgelegten zu sichernden Dateien sollte es auch einen Job geben, der Ihre Catalog-Dateien sichert.
Schließlich gibt es neben den Sicherungs-Jobs Wiederherstellungs-Jobs, Verifikationen und administrative Jobs, die andere Direktiven erfordern.
Wenn Sie bisher Programme wie tar zur Datensicherung verwendet haben, werden Ihnen Begriffe Pools, Volumes und Label auf den ersten Blick vielleicht etwas verwirrend vorkommen. Ein Volume ist ein einzelnes physikalisches Band (oder möglicherweise eine einzelne Datei), auf die Bacula die Daten Ihrer Sicherung schreibt. Pools sind Gruppen von Volumes, so dass eine Sicherung nicht auf die Größe eines einzelnen Volumes (die Länge eines Bandes) beschränkt ist. Daher werden Sie bei der Definition eines Job eher einen Pool anstatt einzelner Volumes spezifizieren. Bacula wird das nächste verfügbare Volume dem Pool entnehmen und Sie auffordern, es zu mounten.
Während die grundlegenden Eigenschaften eines Pools in der Pool-Resource des Directors festgelegt sind, werden die Daten der realen Pools im Bacula-Catalog gehalten. Er enthält alle Informationen der Pool-Resourcen und auch die Informationen über alle Volumes, die einem Pool zugefügt wurden. Ein Volume wird normalerweise mit dem label-Befehl des Konsolen-Proramms dem Pool hinzugefügt.
Für jedes Volume hält Bacula eine ziehmliche Menge von Catalog-Informationen vor, wie z.B. den Zeitpunkt des ersten Lesens/Beschreibens, den Zeitpunkt des letzten Lesens/Beschreibens, die Anzahl der Dateien, die es enthält, die Anzahl der Mounts, usw.
Bevor Bacula ein Volume beschreibt, muss das physikalische Volume eine digitale Kennzeichnung erhalten, damit Bacula sicher sein kann, dass das richtige Volumen gemountet ist. Dies erledigt normalerweise der label-Befehl des Konsolen-Programms.
Das Vorgehen, zuerst eine Pool zu schaffen, dann Volumes hinzuzufügen und die Volumes digital zu kennzeichnen, mag zu Anfang mühselig erscheinen, ist aber ganz einfach und erlaubt es, mehrere Volumes zu verwenden (anstatt auf die Speicherkapaziät eines Bandes beschränkt zu sein). Durch Pools wird man bei der Sicherung auch ausgesprochen flexibel. Man kann sich z.B einen ``täglichen'' Pool für inkrementielle und einen ``wöchentlichen'' Pool für Vollsicherungen anlegen. Sind bei der Definition der Sicherungsjobs die richtigen Pools angegeben, wird Bacula niemals einen Tagesjob in ein Volume des wöchentlichen Pools schreiben oder umgekehrt und Ihnen stets sagen, wann welches Band benötigt wird.
Weiteres zu Pools im Abschnitt Pool-Resource des Kapitels ``Director-Konfiguration''. Auch in diesem Kapitel werden wir später auf dieses Thema zurückkommen.
Wenn Sie Bacula zum ersten Mal verwenden, müssen Sie, nachdem Sie den entsprechenden ./configure-Befehl, ein make und ein make install ausgeführt haben, gültige Konfigurationsdateien für den Director, den File-Dämon, den Storage-Dämon und die Console erstellen. Wenn Sie sich nach unseren Empfehlungen gerichtet haben, finden Sie in Ihrem Installationsverzeichnis sowohl Vorgabe-Konfigurationsdateien als auch die ausführbaren Dateien der Dämonen. In jedem Fall sind die Programmdateien in jenem Verzeichnis, welches bei der Ausführung des ./configure-Befehls mit der Option --sbindir und die Konfigurationsdateien in jenem Verzeichnis, welches mit der --sysconfdir-Option angegeben wurde.
Wenn Sie Bacula zum ersten Mal installieren, werden Sie etwas Zeit brauchen, um die Konfigurationsdateien so zu verändern, dass Sie zu Ihrer Umgebung passen. Das wird mit sich bringen, dass Sie Bacula einige Male starten und wieder beenden müssen bis alles stimmt. Verzweifeln Sie nicht! Sind die Konfigurationsdateien einmal erstellt, werden Sie diese nur noch selten ändern und auch Bacula nicht sehr oft starten oder stoppen müssen. Die meiste Arbeit wird darin bestehen, Bänder zu wechseln, wenn sie voll sind.
Das Condsole-Programm wird vom Administrator benutzt, um mit dem Director-Prozess zu interagiern und Jobs manuell zu starten und zu beenden oder Informationen zu einzelnen Jobs zu erhalten.
Die Konfigurationsdatei der Console ist in jenem Verzeichnis, das mit der --sysconfdir-Option bei der Ausführung des ./configure-Befehl spezifiziert wurde und heißt vorgabemäßig console.conf.
Wenn Sie auch die GNOME-Console mit der --enable-gnome-Option kompiliert haben, finden Sie auch hierfür eine Vorgabe-Konfigurationsdatei die gnome-console.conf heißt.
Gleiches gilt für die wxWidgets-Console, die mit der --enable-wx-console-Option kompiliert wird und deren Vorgabe-Konfigurationdsdatei wx-console.conf ist.
Benutzen Sie Bacula zum ersten Mal, wüssen Sie diese Dateien nicht ändern, da brauchbare Vorgabewerte schon gesetzt sind
Das Monitor-Programm erscheint typischerweise als Icon in der Kontrollleiste. Wird dieses zu einem Fenster vergrößert, liefert es dem Administrator Informationen über den Director, den Sicherungsstatus des lokalen Rechners oder jeden anderen konfigurierten Dämon-Prozess.
Die Abbildung zeigt ein Fenster des Tray-Monitors, der für drei Dämon-Prozesse konfiguriert wurde. Wenn man auf die Schaltflächen in der oberen rechten Ecke des Fensters klickt, sieht man den Zustand jedes einzelnen Prozesses. Die Abbildung zeigt den Zustand des momentan ausgewählten Storage-Dämons (MainSD).
Die Konfigurationsdatei des Monitor-Programms befindet sich in jenem Verzeichnis, das bei Ausführung des ./configure-Befehls mit der Option --sysconfdir angegeben wurde. In der Regel müssen Sie als Erstbenutzer die Berechtigung für diese Datei ändern, um Benutzern, die keine root-Rechte haben, zu erlauben, den Monitor zu starten, da diese Anwendung unter dem gleichen Benutzer laufen muss wie die grafische Umgebung (vergessen Sie nicht, nicht-root-Benutzern die Ausführung von bacula-tray-monitor zu erlauben). Solange Sie die Vorgabewerte verwenden, ist dies kein Sicherheitsproblem.
Der File-Dämon ist ein Programm, das auf jedem (Client-)Rechner läuft. Auf Anforderung des Directors sucht er die zu sichernden Dateien und schickt sie (bzw. ihre Daten) an den Storage-Dämon.
Die Konfigurationsdatei des File-Dämon ist in jenem Verzeichnis, das bei Ausführung des ./configure-Befehls mit der Option --sysconfdir angegeben wurde. Vorgabemäßig heißt diese Datei bacula-fd.conf. Normalerweise muss für erste Versuche hier nichts geändert werden, da vernünftige Vorgabewerte gesetzt sind. Will man allerdings die Daten von mehreren Rechnern sichern, muss auf jedem dieser Rechner ein File-Dämon mit einer eigenen Konfigurationsdatei installiert sein. Die Daten aller dieser File-Dämons müssen in der Konfigurationsdatei des Directors erscheinen.
Der Director ist das zentrale Steuerungsprogramm aller anderen Dämon-Prozesse. Er terminiert und überwacht alle Sicherungsjobs.
Die Konfigurationsdatei des Directors liegt in jenem Verzeichnis, das durch die Option --sysconfdir bei der Ausführung des ./configure-Befehls angegeben wurde. Der Name dieser Konfigurationsdatei ist normalerweise bacula-dir.conf.
Im Allgemeinen muss darin nur die Ressource ``FileSet'' geändert werden, so dass ihre Include-Direktive mindestens eine Zeile mit einem gültigen Verzeichnis (oder einer Datei) enthält, die/das zu sichern ist.
Wenn Sie kein DLT-Bandlaufwerk haben, werden Sie möglicherweise die Storage-Resource ändern wollen, so dass diese Ihrem tatsächlichen Sicherungsgerät mehr entspricht. Sie können hier immer die tatsächlichen Namen verwenden und können diese auch beliebig zuweisen, doch müssen sie mit jenen übereinstimmen, die in der Konfigurationsdatei des Storage-Dämon angegeben sind.
Möglicherweise wollen Sie auch die E-Mailadresse zur Benachrichtigung von der Vorgabe root auf Ihre eigene ändern.
Schließlich brauchen Sie, wenn Sie mehrere Rechner sichern wollen, für jedes System einen eigenen File-Dämon bzw. Client und müssen seinen Namen, seine Adresse und ein Passwort spezifizieren. Wir meinen, dass es die Fehlersuche sehr erleichtert, wenn wir den Dämonen den Namen des Rechners geben und ein -fd anhängen. Wenn Ihr Rechner also z.B. foobaz heißt, würden Sie den File-Dämon foobaz-fd nennen. Der Director könnte foobaz-dir heißen und der Storage-Dämon foobaz-sd. Jede Ihrer Bacula-Komponenten muss einen eindeutigen Namen haben. Wenn Sie alle gleich benennen, werden Sie - abgesehen davon, dass sie nicht wissen werden, welcher Dämon Ihnen welche Botschaft schickt - eigenartige Fehlermeldungen erhalten, da die Namen ihrer Temporärdateien nicht eindeutig sind, sofern sie das gleiche Arbeitsverzeichnis benutzen.
Auf Veranlassung des Director-Prozesses ist der Storage-Dämon für die Übernahme der Daten vom File-Dämon und ihrer Speicherung auf dem Sicherungsmedium verantwortlich, bzw. im Falle einer Wiederherstellung für das Finden und die Übergabe der Daten an den File-Dämon.
Die Konfigurationsdatei der Storage-Dämons ist in dem Verzeichnis, das bei Ausführung des ./configure-Befehls mit der --sysconfdir-Option angegeben wurde und heißt vorgabemäßig bacula-sd.conf. Bearbeiten Sie diese Datei, damit sie die korrekten Archivierungsgerätenamen für jedes Ihrer Bandgeräte enthält. Wenn bei der Konfiguration Ihr System richtig erkannt wurde, werden sie schon richtig gesetzt sein. Die Namen dieser Storage-Resourcen und der Media Type müssen mit jenen übereinstimmen, die in der Konfigurationsdatei des Directors stehen. Wenn Sie in eine Datei anstatt auf ein Band sichern wollen, muss als Archive-Gerät ein Verzeichnis angegeben sein, in dem dann die Volumes erzeugt werden und schließlich die Dateien, sobald ein Volume gelabelt wird.
Sie können die Konfigurationsdateien auf korrekte Syntax testen, indem sie den entsprechenden Dämon mit der -t-Option starten. Der Dämon wird die Konfigurationsdatei abarbeiten, gegebenenfalls eine Fehlermeldung ausgeben und sich dann beenden. Das folgende Beispiel geht davon aus, dass die Programm- und die Konfigurationsdateien im gleichen Verzeichnis installiert sind.
cd <installation-directory> ./bacula-dir -t -c bacula-dir.conf ./bacula-fd -t -c bacula-fd.conf ./bacula-sd -t -c bacula-sd.conf ./bconsole -t -c bconsole.conf ./gnome-console -t -c gnome-console.conf ./wx-console -t -c wx-console.conf su <normal user> -c "./bacula-tray-monitor -t -c tray-monitor.conf"
Hiermit werden alle Konfigurationsdateien der wichtigsten Programme getestet. Sind diese in Ordnung, beendet sich das Programm, ohne irgendetwas auszugeben. Beachten sie bitte, dass je nach gewählten Konfigurationsoptionen einige oder sogar alle der letzten drei Befehle auf Ihrem System nicht verfügbar sein werden. Wenn Sie die ausführbaren Dateien in die üblichen Unix-Verzeichnisse statt in ein einziges Verzeichnis installiert haben, müssen Sie die obigen Befehle entsprechend anpassen (das ``./'' vor dem Befehlsname weglassen und den Pfad vor den Namen der Konfigurationsdatei angeben).
Bevor Sie viel Zeit mit Bacula verschwenden, um schließlich herauszufinden, dass das Programm doch nicht mit Ihrem Bandlaufwerk zusammenarbeitet, lesen Sie bitte das Kapitel btape -- Test Ihres Bandlaufwerkes in diesem Handbuch.
Wenn Sie ein neueres SCSI-Bandlaufwerk unter Linux oder Solaris benutzen, wird Bacula vermutlich funktionieren, aber probieren Sie das lieber vorher aus. Benutzer von FreeBSD (und möglicherweise andere xBSD-Varianten) müssen das oben erwähnte Kapitel lesen. Für FreeBSD gibt es unter The FreeBSD Diary eine eingehende Beschreibung, wie man Bacula auf Ihrem System zum Laufen bringt. Benutzer von FreeBSD in einer Version vor 4.9-STABLE vom Montag, dem 29.12.2003, 15:18:01, die vorhaben ein Bandlaufwerk zu verwenden, sollten ausserdem die Datei platforms/freebsd/pthreads-fix.txt in Baculas Hauptverzeichnis lesen. Darin sind wichtige Informationen zur Kompatibilität von Bacula und Ihrem System.
Die neue Pthreads-Bibliothek /lib/tls, welche standardmäßig von neueren ``RedHat''-Systemen (Kernelversion 2.4.x) installiert wird, ist fehlerhaft. Dieses Verzeichnis muss entfernt oder umbenannt werden, bevor Bacula dann nach einem Neustart lauffähig ist. Geschieht dies nicht, wird sich Bacula nach etwa einer Woche Laufzeit entweder für längere Zeitspannen oder dauerhaft blockieren. Man wird hier wohl eher die entsprechende Umgebungsvariable überschreiben, anstatt das Verzeichnis /lib/tls zu entfernen. Mehr zu diesem Problem im Kapitel Unterstützte Betriebssysteme.
Auf Systemen mit Kernel-Version 2.6.x scheint dieses Problem nicht aufzutreten.
Der vielleicht wichtigste Teil beim Betrieb on Bacula ist die Fähigkeit, Dateien wiederherzustellen. Wenn Sie dies nicht wenigstens einmal ausprobiert haben, bevor Sie tatsächlich gezwungen sind, es zu tun, werden Sie viel mehr unter Druck stehen und dazu neigen, Fehler zu machen, als wenn sie diesen Vorgang schon einmal getestet haben.
Um eine Vorstellung davon zu bekommen, wie man Bacula in kurzer Zeit zum Laufen bringt empfehlen wir dringend, das Beispiel im Kapitel Running Bacula Chapter in diesem Handbuch nachzuvollziehen, wo im einzelnen erklärt wird, wie man Bacula laufen lässt.
Wenn Sie die vorgegebene bacula-dir.conf oder eine Abwandlung davon benutzen, werden Sie bemerken, dass alle Ausgaben von Bacula in eine Datei gespeichert werden. Um zu verhindern, dass diese Datei ohne Grenze wächst, empfehlen wir, die Datei logrotate aus dem Verzeichnis scripts/logrotate nach /etc/logrotate.d/bacula zu kopieren. Dadurch wird die Logdatei einmal im Monat rotiert und höchstens fünf Monate lang erhalten. Um die Logrotation Ihren Wünschen anzupassen, können Sie diese Datei bearbeiten.
Wenn sie vorhaben, Bacula eher als Werkzeug zur Wiederherstellung Ihres Systems im Notfall, als nur dazu zu verwenden, beschädigte oder verlorengegangene Dateien wiederherzustellen, werden sie vielleicht das Kapitel Disaster Recovery Using Bacula Chapter in diesem Handbuch lesen wollen.
Auf jeden Fall raten wir Ihnen dringend, die Wiederherstellung einiger gesicherte Dateien zu testen anstatt zu warten, bis ein Notfall eintritt.
