Subsections


Bacula installieren

Normalerweise benötigen Sie ein Release mit Baculas Quellcode und, wenn ein Windows-Client benutzt werde soll, ein ausführbares Release von Bacula für Windows. Entprechend Ihrer Konfigurationsoptionen benötigt Bacula bestimmte Pakete von Drittanbietern (wie z.B. SQLite, MySQL oder PostgreSQL) zur Kompilierung. Um Ihnen die Arbeit zu erleichtern, haben wir einige dieser Softwarepakete als zwei depkgs-Releases veröffentlicht (Dependency Packages). Dies kann Ihr Leben ungemein erleichtern, da Sie so mit allen notwendigen Pakaten versorgt anstatt gezwungen sind, sie selbst einzeln im Internet zu finden und zu installieren.

Source Release Files

Seit Baculas Version 1.38.0 ist der Quellcode in vier einzelne Tar-Dateien aufgeteilt, die jeweils einem Modul in Baculas CVS entsprechen. Im einzelnen sind dies:

bacula-1.38.0.tar.gz
Dies ist Baculas Quellcode. Mit jedem Release erhöht sich die Versionsnummer.

bacula-docs-1.38.0.tar.gz
Diese Datei enthält eine Kopie des Verzeichnisses der Dokumente im CVS. Einige Dokumente sind vorkompiliert. Für Englisch existiert ein HTML-Verzeichnis, ein einzelnes HTML-File und eine PDF-Datei. Die französische und die deutsche Übersetzung sind in Arbeit, aber nicht kompiliert.

bacula-gui-1.38.0.tar.gz
Diese Datei enthält grafische Benutzeroberflächen, die nicht Bestandteil des Hauptprogrammes sind. Momentan sind dies ``bacula-web'' zur Generierung von Verwaltungsansichten Ihrer Bacula-Jobs innerhalb eines Web-Browsers und ``bimagemgr'', ein Dateibrowser, der verwendet wird, um aus Bacula-Volumes CD-Images zu brennen.

bacula-rescue-1.8.1.tar.gz
Dies ist der Code für die Bacula Rettungs-CD. Die Versionsnummer diese Paketes ist nicht an die Versionsummer von Bacula gebunden und wird sich daher unterscheiden. Mit diesem Code können Sie eine CD brennen, die unter anderem eine Beschreibung Ihrer Systemkonfiguration und die statisch gelinkte Version des File-Dämons enthält. Damit können Sie im Falle eines Festplattenausfalles mit Hilfe von Bacula Ihre Festplatten neu partitionieren, formatieren und Ihr System auf einfache Art wiederherstellen.

Bacula upgraden

Wenn Sie Bacula von einer Version auf die nächste upgraden, sollten Sie erst die ReleaseNotes aller Versionen zwischen Ihrer laufenden und jener, auf die sie upgraden wollen, sorgfältig lesen. Wenn die Bacula Catalog-Datenbank upgegraded wurde, müssen Sie entweder ganz von vorne anfangen und Ihre Datenbank neu initialisieren oder diese als ASCII-Datei sichern und dann mit dem Upgrade fortfahren. Dies geschieht normalerweise nachdem Bacula kompiliert und installiert ist durch Eingabe von:

cd <installed-scripts-dir> (default /etc/bacula)
./update_bacula_tables

Dieses Update-Skript finden Sie auch in Baculas Quellcode im Verzeichnis ``src/cats'':

Gab es zwischen Ihrer Version und der aktuellen mehrere Datenbank-Upgrades, werden Sie jedes einzelne Datenbank Upgradeskript ausführen müssen. Um Ihnen dies zu erleichtern, sind alle alten Upgrade-Skripte im Verzeichnis upgradedb des Quellcodes. Sie werden diese Skripte den Gegebenheiten Ihrer Systemkonfiguration anpassen müssen.

Das letzte Upgrade-Skript (wenn vorhanden) wird dann so ausgeführt, wie es oben beschrieben ist.

Wenn Sie von einer Hauptversion auf die nächste upgraden, müssen alle Komponenten gleichzeitig ersetzt werden, da sich in der Regel das Übertragungs-Protokoll zwischen den Dämonen ändert. Innerhalb eines bestimmten Release (z.B. Version 1.32.x) wird sich das Dämon-Protokoll jedoch nicht ändern solange nicht ein Bug oder ein Versehen zu beheben ist. Wenn das alles für Sie verwirrend ist, lesen Sie einfach die ReleaseNotes sehr sorgfältig. Es wird hier stehen, wenn alle Dämonen gleichzeitig upgegraded werden müssen.

Beachten Sie schließlich, dass es in der Regel nicht notwendig ist, vor dem Upgrade ein make uninstall auszuführen. Tatsächlich werden Sie so sehr wahrscheinlich alle ihre Konfigurationsdateien zerstören, was verheerend sein könnte. Die normale Upgrade-Prozedur besteht einfach in der Eingabe von make install. Im allgemeinen werden dabei keine Ihrer ``.conf''- oder ``.sql''-Dateien überschrieben.

Weiteres zum Upgraden lesen sie im Abschnitt Upgrading Bacula Versions im Kapitel ``Tips'' in diesem Handbuch.


Dependency-Packages

Wie oben erwähnt, haben wir einige Pakete von Drittanbietern, die Bacula möglicherweise benötigt, in den Releases depkgs und depkgs1 zusammengefasst. Natürlich können Sie sich auch die neuesten Versionen von den Original-Autoren besorgen. Die Quellen der einzelnen Pakete stehen in der README-Datei jedes einzelnen Paketes. Beachten Sie jedoch, dass die Pakete der depkgs-Dateien von uns auf ihre Kompatibilität zu Bacula getestet wurden.

Typischerweise heißen die Dependency-Packages depkgs-ddMMMyy.tar.gz und depkgs1-ddMMyy.tar.gz wobei dd der Tag, MMM der Monat in abgekürzter Form (z.B. ``Jan'') und yy das Jahr ist, an dem es herausgegeben wurde. Ein aktuelles Beispiel ist: depkgs-07Apr02.tar.gz. Um es zu installiern und zu kompilieren (wenn es benötigt wird) gehen Sie wie folgt vor:

  1. Erstellen sie ein bacula-Verzeichnis, in das Sie sowohl die Bacula-Quelldateien als auch das Dependency-Packages legen.
  2. Entpacken Sie das depkg mit ``detar'' in das bacula-Verzeichnis.
  3. cd bacula/depkgs
  4. make

Die genaue Zusanmmensetzung der Dependency-Packages wird sich von Zeit zu Zeit ändern. Momentan sehen sie so aus:

Drittanbieterpaket depkgs depkgs1 depkgs-win32
SQLite X - -
mtx X - -
readline - X -
pthreads - - X
zlib - - X
wxWidgets - - X

Beachten Sie, dass einige dieser Pakete recht umfangreich sind, so dass ihre Compilierung einige Zeit beanspruchen kann. Mit den obigen Anweisungen werden alle Pakete im entsprechenden Verzeichnis kompiliert. Bacula wird allerdings bei seine Kompilierung nur jene Teile verwenden, die es tatsächlich benötigt.

Alternativ können Sie nur jene Pakete kompilieren, die Sie tatsächlich benötigen. Beispielsweise wird

cd bacula/depkgs
make sqlite

nur das ``SQLite''-Paket konfigurieren und kompilieren.

Sie sollten die benötigten Pakete aus depkgs und/oder depkgs1 kompilieren bevor Sie Bacula konfigurieren und kompilieren, da Bacula diese während seiner eigenen Kompilierung benötigt.

Auch wenn Sie SQLite nicht verwenden, könnte es sich für Sie lohnen mtx zu kompilieren, da das enthaltenen tapeinfo-Programm oft wertvolle Informationen über Ihr SCSI-Bandlaufwerk (z.B. Kompression, min./max. Blockgröße...) liefern kann.

Das depkgs-win32-Paket enthält den Qullcode der ``Pthreads''-, ``wxWidgets''- und ``zlib''-Bibliotheken, die das Win32-Clientprogramm verwendet. Man benötigt diese nur, wenn Sie das Win32-Programm selbst kompilieren wollen.


Unterstützte Betriebssysteme

Lesen sie bitte den Abschnitt Unterstützte Betriebssysteme im Kapitel ``QuickStart'' dieses Handbuches.


Bacula aus dem Quellcode kompilieren

Die Grundinstallation ist ziemlich einfach.

  1. Installieren und kompilieren sie alle benötgten depkgs wie oben beschrieben.
  2. Konfigurieren und installieren Sie ``MySQL'' oder ``PostgreSQL'' (wenn gewünscht) Installation und Konfiguration von MySQL Phase I oder Installation und Konfiguration von PostgreSQL Phase I. Wenn Sie für die Installation von ``MySQL'' ein RPM verwenden, müssen Sie auch mysql-devel installieren, so dass die Header-Dateien verfügbar sind, wenn Sie Bacula kompilieren. Zusätzlich erfordert die MySQL Client-Bibliothek die gzip-Kompressionsbibliotheken libz.a oder libz.so. Wenn Sie RPM-Pakete verwenden, sind diese Bibliotheken im Paket zlib1g-dev. Auf Debian-Systemen müssen Sie das zlib1g-dev-Paket laden. Wenn Sie weder RPMs noch debs verwenden, müssen Sie die passenden Pakete für Ihr System selbst finden. Wenn auf Ihrem System schon MySQL oder PostgreSQL läuft, können Sie diese Phase überspringen, wenn Sie ``thread safe''-Bibliotheken kompiliert und die oben erwähnten zusätzlichen RPMs installiert haben.

  3. Anstatt ``MySQL'' und ``PostgreSQL'' können Sie auch SQLite konfigurieren und installieren Installation und Konfiguration von SQLite. Dessen Quellcode ist Teil des depkgs-Paketes.
  4. Entpacken sie Baculas Quellcode vorzugsweise in das bacula-Verzeichnis, welches oben erwähnt wurde.
  5. Wechseln (cd) Sie in das Verzeichnis mit dem Quellcode.
  6. Führen Sie ./configure aus (mit den entsprechenden Konfigurationsoptionen, die weiter unten näher beschrieben sind.
  7. Prüfen Sie die Ausgabe des ./configure-Befehls sehr sorgfältig, besonders die Ausgaben zum Installationsverzeichnis der Programm- und der Konfigurationsdateien. Sind diese nicht korrekt, wiederholen Sie ./configure bis sie stimmen. Die Ausgabe des ./configure-Befehls ist in der Datei config.out abgespeichert und kann jederzeit wieder angesehen werden, ohne ./configure neu zu starten, indem man cat config.out eingibt.
  8. Wenn Sie Optionen ändern, nachdem ./configure gelaufen war und Sie es neu starten müssen, geben Sie vorher das folgende ein.

          make distclean
    

    Damit gehen Sie sicher, dass Sie wirklich von vorne anfangen und keine Mischung der verschiedenen Optionen haben. Dies liegt daran, dass ./configure einen Großteil der Informationen zwischenspeichert. make distclean ist auch sehr wichtig, wenn Sie die Quellverzeichnisse auf einen anderen Rechner verlagern. Schlägt der Befehl fehl, ignorieren Sie das einfach und machen mit

  9. make

    weiter.

    Wenn es hierbei Fehlermeldungen beim Linken in das Verzeichnis (src/stored) des Storage-Dämon gibt, liegt es vielleicht daran, dass sie die statischen Bibliotheken in Ihrem System nicht geladen sind. Diese Problem bemerkte ich auf einem Solaris-System. Verwenden sie den ./configure-Befehl ohne die Option --enable-static-tools um den Fehler zu beheben.

  10. make install

  11. Wenn Sie ein Bacula-Neuling sind, empfehlen wir dringend, den nächsten Schritt zu überspringen und die Vorgabe-Konfigurationsdateien zu verwenden. Probieren Sie damit das Beispiel im nächsten Kapitel aus und ändern sie danach Ihre Konfigurationsdateien, so dass sie Ihren eigenen Anforderungen entsprechen.

  12. Passen Sie die Konfigurationsdateien aller drei Dämonprozesse und die des Console-Programms an. Einzelheiten hierzu im Abschnitt Setting Up Bacula Configuration Files des Kapitels ``Konfiguration'' in diesem Handbuch. Wir empfehlen Ihnen, an den beigefügten Vorgabe-Konfigurationsdateien zunächst nur soviel zu ändern wie unbedingt notwendig ist. Eine endgültige Anpassung ist immer noch möglich, wenn Bacula zuverlässig läuft. Passen Sie bitte auf, wenn sie die (zufällig generierten) Passwörter und die Namen verändern. Aus Sicherheitsgründen müssen diese in den Konfigurationsdateien übereinstimmen.

  13. Erzeugen Sie die Datenbank und die Tabellen für Bacula in MySQL (wenn sie MySQL verwenden)(MySQL installieren und Konfigurieren Phase II, in PostgreSQL (PostgreSQL installieren und Konfigurieren Phase II) oder gegebenenfalls in SQLite (SQLite installieren und Konfigurieren Phase II).

  14. Starten Sie Bacula (./bacula start). Im nächsten Kapitel wird dies im einzelnen erklärt.
  15. Kommunizieren Sie mit Bacula über das Console-Programm.

  16. Folgen Sie für die letzten beiden Punkte den Anweisungen im Kapitel Running Bacula diese Handbuches, wo Sie eine einfache Sicherung und eine Wiederherstellung durchführen. Tun Sie dies bevor Sie die Konfiguratinsdateien in größerem Umfang verändern, so dass Sie sicher sein können, dass Bacula funktioniert und Sie damit vertraut sind. Danach wird es einfacher sein, die Konfigurationsdateien anzupassen.

  17. Wenn Sie nach der Installation beschließen, mit Bacula ``umzuziehen'', d.h. es in anderen Verzeichnissen installieren zu wollen, gehen Sie wie folgt vor:

          make uninstall
          make distclean
          ./configure (mit-den-neuen-Optionen)
          make
          make install
    

Wenn alles gut geht, wird der ./configure-Prozess Ihr laufendes Betriebssystem korrekt erkennen und den Quellcode entsprechend konfigurieren. Momentan werden FreeBSD, Linux (Red Hat) und Solaris unterstützt. Von MacOS X 10.3 wird berichtet, dass der Client nur dann darauf läuft, wenn die readline-Unterstützung deaktiviert ist.

Wenn Sie Bacula auf mehr als einem System installieren, können Sie einfach den Verzeichnisbaum des Quellcodes auf den anderen Rechner übertragen und ein ``make install'' ausführen. Gibt es jedoch Unterschiede in den Bibliotheken, den Betriebssystemversionen oder soll es auf einem anderen Betriebssystem installiert werden, sollten Sie mit der originalen tar-Datei beginnen. Wenn Sie die Verzeichnisstruktur des Quellcodes übertragen und den ./configure-Befehl schon ausgeführt haben, müssen Sie unbedingt

make distclean

ausführen, bevor Sie ``./configure'' erneut aufrufen. Dies liegt daran, dass ``GNU autoconf'' die Konfiguration zwischenspeichert und wenn Sie beispielsweise die Konfiguration eines Linux-Rechners auf einem Solaris-System wiederverwenden, können Sie sicher sein, dass die Kompilierung fehlschlägt. Um dies zu vermeiden starten Sie entweder mit der tar-Datei oder führen ``make distclean'' aus, wie oben erwähnt.

Gewöhnlich werden Sie einen etwas komplizierteren configure-Befehl absetzen wollen, um sicher zu gehen, dass die von Ihnen gewünschten Module kompiliert werden und alles in den richtigen Verzeichnissen abgelegt wird.

Auf RedHat zum Beispiel könnte ``./configure'' so aussehen:

CFLAGS="-g -Wall" \
  ./configure \
    --sbindir=$HOME/bacula/bin \
    --sysconfdir=$HOME/bacula/bin \
    --with-pid-dir=$HOME/bacula/bin/working \
    --with-subsys-dir=$HOME/bacula/bin/working \
    --with-mysql=$HOME/mysql \
    --with-working-dir=$HOME/bacula/bin/working \
    --with-dump-email=$USER

Beachten Sie bitte, dass der Vorteil der Verwendung der obigen Konfiguration für den Anfang darin liegt, dass hierbei alles in ein einziges Verzeichnis geschrieben wird, welches später gelöscht werden kann, wenn Sie die Beispiele des nächsten Kapitels ausgeführt und gelernt haben wie Bacula funktioniert. Ausserdem kann das Obige auch ohne root-Rechte installiert und ausgeführt werden.

Um den Entwicklern die Arbeit zu erleichtern, haben wir dem Verzeichnis examples ein defaultconfig-Skript beigefügt. Diese Skript enthält alle Statements, die man normalerweise benutzt und jeder Entwickler oder Benutzer kann sie nach seinen Bedürfnissen verändern. In diesem Verzeichnis sind auch andere nützliche Beispiele.

Die ./configure-Schalter --enable-conio oder --enable-readline sind nützlich, da man dadurch eine Kommandozeilen-History und ein Editorfunktionen für die Kommandozeile des Console-Programms erhält. Wenn Sie eine dieser Optionen verwenden, benötigen Sie beim Linken entweder das termcap- oder das ncurses-Paket. Auf manchen Systemen wie z.B. ``SuSE'' ist die termcap-Bibliothek nicht im Verzeichnis der Standard-Bibliotheken. Daher kann diese Option wirkungslos sein oder Sie erhalten folgende Fehlermeldung

/usr/lib/gcc-lib/i586-suse-linux/3.3.1/.../ld:
cannot find -ltermcap
collect2: ld returned 1 exit status

während Sie die Bacula-Console kompilieren. In diesem Fall müsssen Sie die LDFLAGS-Umgebungsvariable vor der Kompilierung wie folgt setzen:

export LDFLAGS="-L/usr/lib/termcap"

Die gleichen Erfordernisse an die Systembibliothek gelten, wenn sie die ``Readline''-Subroutinen für das Editieren und die History der Kommandozeile benutzen wollen oder eine MySQL-Bibliothek, die Verschlüsselung erfordert. Wenn Sie Verschlüsselung benötigen, können Sie entweder die entsprechenden zusätzlichen Bibliotheks-Pfade wie oben gezeigt setzen oder wie unten gezeigt direkt in der Befehlzeile des Befehls mit angeben.

LDFLAGS="-lssl -lcyrpto" \
   ./configure \
      <Ihre-Optionen>

Auf manchen Systemen wie Mandriva neigt ``readline'' dazu, die Eingaben zu verstümmeln, was es völlig unbrauchbar macht. Wenn das bei Ihnen geschieht, wählen Sie die Option ab oder, wenn Sie Version 1.33 oder höher verwenden, versuchen Sie mit der Option --enable-conio den eingebauten ``readline''-Ersatz zu verwenden. Auch hierzu werden Sie entweder die ``termcap''- oder ``ncurses''-Bibliothek benötigen, doch es ist unwahrscheinlich, dass das conio-Paket Ihre Eingaben dann verstümmelt.

``readline'' wird ab Version 1.34. nicht weiter unterstützt. Der Code ist noch verfügbar und wenn Benutzer dafür Patches schicken, wird es mir ein Vergnügen sein, diese einzubauen. Da jedoch jede Version von ``readline'' mit den Vorgängerversionen inkompatibel zu sein scheint und zwischen den Systemen wesentliche Unterschiede bestehen, kann ich es mir nicht mehr länger leisten, es zu unterstützen.


Welches Datenbanksystem soll verwendet werden?

Vor der Kompilierung von Bacula müssen Sie sich entscheiden, ob Sie SQLite, MySQL oder PostgreSQL verwenden werden. Wenn bei Ihnen nicht sowieso schon MySQl oder PostgrSQL läuft, empfehlen wir versuchsweise mit SQLite zu beginnen. Dies wird Ihnen die Einrichtung wesentlich erleichtern, da SQLite in Bacula hineinkompiliert wird und keine Administration erfordert. Es hat hat eine ganz ordentliche Performanz und ist für kleine bis mittlere Installationen gut geeignet (maximal 10 bis 20 Rechner). Allerdings sollten wir erwähnen, dass einige unserer Benutzer mit SQLite unerklärliche Datenbankkorruptionen hatten. Für ein Produktiv-System empfehlen wir daher die Installation von MySQL oder PostgreSQL:

Wenn Sie für den Bacula-Catalog MySQL verwenden wollen, lesen Sie bitte das Kapitel MySQL installieren und konigurieren in diesem Handbuch. Sie werden hierzu MySQL installieren müssen, bevor Sie Bacula konfigurieren. MySQL ist ein Datenbanksystem von hoher Qualität, das sehr effizient arbeitet und für Installationen jeder Größe geeignet ist. Seine Einrichtung und Administration sind ein wenig komplizierter als die von SQLite, da es einige Besonderheiten wie userids und Passwörter bietet. Es läuft als eigenständiger Prozess, ist wirklich professionell und kommt mit Datenbanken jeder Größe zurecht.

Wenn Sie PostgreSQL als Bacula-Catalog verwenden wollen, lesen Sie bitte das Kapitel PostgreSQL installieren und konfigurieren in diesem Handbuch. Bevor Bacula konfiguriert wird, muss PostgreSQl installiert sein. Es ist MySQL sehr ähnlich, dabei aber eher etwas mehr SQL92-kompatibel und hat viele Features wie ``Transaktionen'', ``Stored Procedures'' und ähnliches. Man braucht eine gewisses Erfahrung, um es zu installieren und zu warten.

Wenn Sie als Bacula Catalog SQLite verwenden wollen, lesen Sie bitte das Kapitel SQLite installieren und konfigurieren in diesem Handbuch.

Quick Start

Unten werden nun einige Optionen und wichtige Vorüberlegungen ausgeführt, die Sie jedoch für den Moment überspringen können, wenn Sie mit der vereinfachten Konfiguration, wie sie oben gezeigt wurde, keine Probleme hatten.

Falls der ``./configure''-Prozess bestimmte Bibliotheken (z.B. ``libintl'') nicht findet, vergewissern Sie sich, dass das entsprechende Paket auf Ihrem Rechner installiert ist. Wenn das Paket an einem Ort installiert ist, denn Bacula nicht erwartet, kann in der Regel mit einem der im Folgenden aufgeführten Optionsschalter ein Suchpfad übergeben werden. "./configure --help" liefert eine Liste aller Optionen. Das letzte Mittel ist, ein Feature durch einen entsprechenden Optionschalter zu deaktivieren (z.B. ``--disable-nls'').

Wenn Sie richtig loslegen wollen, empfehlen wir, zum nächsten Kapitel weitergehen und das Beispielprogramm zum Laufen zu bringen. Es wird Sie viel über Bacula lehren und kann zum Ausprobieren in ein einzelnes Verzeichnis installiert (um es auf einfache Art wieder löschen zu können) und ohne root-Rechte betrieben werden. Wenn irgendwelche Probleme auftreten oder Sie richtig installieren wollen, kehren Sie zu diesem Kapitel zurück und lesen Sie die Einzelheiten, die nun folgen.


Konfigurationsoptionen

Um Ihre Installation anzupassen, hat der configure-Befehl die folgenden Kommandozeilen-Schalter.

--sysbindir=<Pfad/zu/den/Programmdateien>
Legt fest, in welches Verzeichnis die Bacula Programmdateien bei Ausführung des make install-Befehls installiert werden.

--sysconfdir=<Pfad/zu/den/Konfigurationsdateien>
Legt fest, in welches Verzeichnis die Bacula Konfigurationsdateien bei Ausführung des make install-Befehls installiert werden.

--mandir=<path>
Vorgabemäßig installiert Bacula eine einfache Unix-manpage in ``/usr/share/man''. Soll die manpage an einen anderen Ort, können Sie mit dieser Option einen Pfad setzen. Beachten Sie bitte, dass die Bacula-Handbücher (HTML- und PDF-Dateien) Bestandteil eines eigenen tar-Files sind, das nicht Bestandteil des Quellcode-Releases ist.

--datadir=<path>
Wenn Sie Bacula oder Teile davon übersetzen wollen, können Sie die `` --datadir''-Option verwenden um den Speicherort der ``po''-Dateien festzulegen. Die ``po''-Dateien müssen ``von Hand'' installiert werden, da Bacula dies (noch) nicht automatisch tut.

--enable-smartalloc
Damit wird der ``Smartalloc orphaned buffer detection code'' mit eingebunden. Diese Option ist dringend empfohlen. Da wir nie ohne diese Option kompilieren, werden Sie vielleicht Probleme haben, wenn sie nicht gesetzt ist. Wir empfehlen dringend, diesen Schalter gesetzt zu lassen, da er hilft, Memory-Leaks zu entdecken. Dieser Konfigurationsparameter wird bei der Kompilierung von Bacula benutzt.

--enable-gnome
Ist auf Ihrem Computer GNOME installiert und wollen Sie das grafische GNOME-Interface benutzen, setzen Sie diesen Schalter. Dadurch wird alles im Verzeichnis src/gnome-console kompiliert.

--enable-wx-console
Wenn auf Ihrem Rechner wxWidgets installiert ist und sie das grafische wxWidgets Console-Interface benutzen wollen, müssen Sie diesen Schalter setzen. Hierdurch wird alles im Verzeichnis src/wx-console kompiliert. Dies kann auch für Benutzer hilfreich sein, die eine grafische Konsole benutzen, aber GNOME nicht installieren wollen, da wxWidgets mit GTK+-, Motif- und sogar X11-Bibliotheken läuft

--enable-tray-monitor
Wenn Sie auf Ihrem Rechner GTK installiert haben und eine grafische Umgebung oder einen Window-Manager benutzen, der dem Standard für die System-Tray von FreeDesktop entspricht (wie KDE oder GNOME) und wenn sie Ihre GUI benutzen wollen, um die Bacula-Dämonen zu überwachen, sollten sie diesen Schalter setzen. Ist er gesetzt, wird alles im Verzeichnis src/tray-monitor kompiliert.

--enable-static-tools
Durch Setzen dieses Schalters werden die Hilfsprogramme des Storage-Dämons (bls, bextract, and bscan) statisch gelinkt. Dadurch kann man sie auch verwenden, ohne dass die gemeinsamen Bibliotheken geladen sind. Wenn beim Linken Probleme im Verzeichnis src/stored auftreten, sollten sie sich vergewissern, dass diese Option nicht gesetzt ist. Sie können durch Setzen des Schalters --disable-static-tools das statische Linken auch explizit unterdrücken.

--enable-static-fd
Durch diese Option kompiliert der make-Prozess zusätzlich zum Standard File-Dämon einen statischen Bacula File-Dämon. Diese statische Version hat alle benötigten Bibliotheken statisch gelinkt und wird für eine Notfallwiederherstellung auf einer leeren Festplatte verwendet. Diese Option kann meistens durch den Befehl make static-bacula-fd ersetzt werden, den man im Verzeichnis src/filed ausführen kann. Daneben ist auch die unten beschriebene Option --enable-client-only nützlich, wenn man nur einen einzelnen Client kompilieren will und die übrigen Programmteile nicht.

Wird ein statisches Programm gelinkt, benötigt der Linker alle verwendeten Bibliotheken in statischen Versionen. Benutzer, die diese Option häufiger verwenden, werden auch häufiger Linker-Fehler haben. Als Erstes sollte man dann überprüfen, ob auf dem System eine statische ``glibc''-Bibliothek installiert ist. Als nächstes sollte man `./configure'' ohne die Optionen --openssl und --with-python aufrufen, da hierbei zusätzliche Bibliotheken benötigt werden. Man kann diese Optionen verwenden, doch muss man dann zusätzliche statische Bibliotheken laden.

--enable-static-sd
Damit wird zusätzlich zum Standard-Storage-Dämon ein statischer Storage-Dämon kompiliert. Die statische Version hat die Bibliotheksfunktionen fest eingebaut und ist bei der Datenwiederherstellung im Notfall hilfreich.

Wird ein statisches Programm gelinkt, benötigt der Linker alle verwendeten Bibliotheken in statischen Versionen. Benutzer, die diese Option häufiger verwenden, werden auch häufiger Linker-Fehler haben. Als Erstes sollte man dann überprüfen, ob auf dem System eine statische ``glibc''-Bibliothek installiert ist. Als nächstes sollte man `./configure'' ohne die Optionen --openssl und --with-python aufrufen, da hierbei zusätzliche Bibliotheken benötigt werden. Man kann diese Optionen verwenden, doch muss man dann zusätzliche statische Bibliotheken laden.

--enable-static-dir
Damit wird zusätzlich zum Standard-Director ein statischer Director kompiliert. Die statische Version hat die Bibliotheksfunktionen fest eingebaut und ist bei der Datenwiederherstellung im Notfall hilfreich.

Wird ein statisches Programm gelinkt, benötigt der Linker alle verwendeten Bibliotheken in statischen Versionen. Benutzer, die diese Option häufiger verwenden, werden auch häufiger Linker-Fehler haben. Als Erstes sollte man dann überprüfen, ob auf dem System eine statische ``glibc''-Bibliothek installiert ist. Als nächstes sollte man `./configure'' ohne die Optionen --openssl und --with-python aufrufen, da hierbei zusätzliche Bibliotheken benötigt werden. Man kann diese Optionen verwenden, doch muss man dann zusätzliche statische Bibliotheken laden.

--enable-static-cons
Damit werden zusätzlich zur Standard-Console eine statische Console und statische GNOME-Console kompiliert. Die statischen Versionen haben die Bibliotheksfunktionen fest eingebaut und sind bei der Datenwiederherstellung im Notfall hilfreich.

Wird ein statisches Programm gelinkt, benötigt der Linker alle verwendeten Bibliotheken in statischen Versionen. Benutzer, die diese Option häufiger verwenden, werden auch häufiger Linker-Fehler haben. Als Erstes sollte man dann überprüfen, ob auf dem System eine statische ``glibc''-Bibliothek installiert ist. Als nächstes sollte man `./configure'' ohne die Optionen --openssl und --with-python aufrufen, da hierbei zusätzliche Bibliotheken benötigt werden. Man kann diese Optionen verwenden, doch muss man dann zusätzliche statische Bibliotheken laden.

--enable-client-only
Durch Setzen dieses Schalters werden nur der File-Dämon und die von ihm benötigten Bibliotheken kompiliert. Keiner der anderen Dämonen, nicht die Sicherungswerkzeuge oder die Console werden kompiliert. Daher wird mit dem Befehl make install auch nur der File-Dämon installiert. Um alle Dämonen zu kompilieren, müssen Sie eine Konfiguration ohne diese Option verwenden. Mit dieser Option wird die Kompilierung nur eines Client-Prozesses auf einem Client-Rechner sehr erleichtert.

Wird ein statisches Programm gelinkt, benötigt der Linker alle verwendeten Bibliotheken in statischen Versionen. Benutzer, die diese Option häufiger verwenden, werden auch häufiger Linker-Fehler haben. Als Erstes sollte man dann überprüfen, ob auf dem System eine statische ``glibc''-Bibliothek installiert ist. Als nächstes sollte man `./configure'' ohne die Optionen --openssl und --with-python aufrufen, da hierbei zusätzliche Bibliotheken benötigt werden. Man kann diese Optionen verwenden, doch muss man dann zusätzliche statische Bibliotheken laden.

--enable-largefile
Mit diesem Schalter (voreingestellt) wird Bacula mit der Unterstützung für 64 Bit breite Adressen kompiliert, sofern dies Ihr Rechner unterstützt. Damit kann Bacula Dateien lesen und schreiben, die größer sind als 2 GBytes. Dieses Feature kann durch setzen des Schalters --disable-largefile abgewählt werden. Damit sind nur 32 Bit breite Adressen möglich.

--disable-nls
Vorgabemäßig verwendet Bacula ``GNU Native Language Support''-Bibliotheken (NLS). Auf manchen Rechnern sind diese Bibliotheken nicht verfügbar oder funktionieren nicht richtig (beonders auf nicht-Linux Implementierungen). In diesen Fällen kann man durch Setzen von --disable-nls die Verwendung dieser Bibliotheken unterbinden. In diesem Fall benutzt Bacula Englisch.

--with-sqlite=<Pfad/zu/SQLite>
Mit dieser Option wird die Benutzung eines SQlite-Datenbanksystems ermöglicht. Da Bacula an einem Standard-Speicherort (depkgs/sqlite) sucht, wird der Pfad sqlite-path normalerweise nicht angegeben. Näheres hierzu im Kapitel SQLite installieren and konfigurieren in diesem Handbuch. Beachten Sie auch den Hiinweis zur Option ``--with-postgresql''.

--with-sqlite3=<Pfad/zu/sqlite3>
Dies erlaubt die Verwendung von SQLite in der Version 3.x. Der Pfad (sqlite3-path) muss normalerweise nicht gesetzt werden, da Bacula die benötigten Komponenten an den Standardspeicherorten (depkgs/sqlite3) sucht. Im Kapitel SQLite installieren und konfigurieren dieses Handbuches finden sie weitere Einzelheiten.

--with-mysql=<Pfad/zu/MySQL>
Mit dieser Option werden die Catalog-Dienste für Bacula kompiliert. Sie setzt voraus, dass MySQL bereits auf Ihrem Rechner läuft, und erwartet, dass es im Verzeichnis, das Sie mit der Pfadangabe (mysql-path) angeben, installiert ist. Wenn dieser Schalter nicht gesetzt ist, wird Bacula automatisch den Code der internen Bacula-Datenbank einbeziehen. Nach Möglichkeit empfehlen wir, diesen Schalter zu setzen. Wenn Sie ihn verwenden, installieren Sie bitte zuerst MySQL und lesen das Kapitel MySQL installieren and konfigurieren in diesem Handbuch bevor Sie mit der Konfiguration fortfahren.

--with-postgresql=<Pfad/zu/PostgreSQL>
Dieser Schalter erfordert die Angabe des Pfades zum PostgreSQL-Programmverzeichnis, da Bacula ihn nicht von selbst finden kann. Zur Kompilierung mit PostgreSQL verwendet man einfach --with-postgresql.

Um Bacula richtig zu konfigurieren, muss eine der vier unterstützten Datenbank-Optionen spezifiziert sein. Entweder also ``--with-sqlite'', ``--with-sqlite3'', ``--with-mysql'' oder `--with-postgresql''. Andernfalls wird der ``./configure''-Prozess fehlschlagen.

--with-openssl=<path>
Diese Schalter wird benötigt, wenn Bacula TLS (ssl) verwenden soll. In der Regel muss der Pfad nicht spezifiziert werden, da der Konfigurationsprozess die OpenSSL-Bibliotheken an deren Standardorten sucht. Wenn OpenSSL aktiviert ist, gestattet Bacula eine sichere Kommunikation zwischen seinen Dämonprozessen. Weitere Informationen zur Verwendung von TLS im Kapitel Bacula TLS in diesem Handbuch.

--with-python=<Pfad/zu/Python>
Mit diese Option wird die Bacula-Unterstützung für Python aktiviert. Wird kein Pfad mit angegeben, sucht der Konfigurationsprozess Bibliotheken an den Standard-Installationsorten von Python 2.2., 2.3 und 2.4. Wird die Bibliothek nicht gefunden, muss die Option mit dem Pfad zum Verzeichnis Ihrer Python-Bibliotheken aufgerufen werden. Im Kapitel Python sind Einzelheiten dazu, wie man Python-Scripting verwenden kann.

--with-libintl-prefix=<DIR>
Mit dieser Option durchsucht Bacula die Verzeichnisse ``DIR/include'' und ``DIR/lib'' nach den ``libintl''-Headern und -Bibliotheken, die es für den ``Native Language Support'' (NLS) benötigt.

--enable-conio
Teilt Bacula mit, die kleine, leichtgewichtige, ``readline'' ersetzende Routine zu kompilieren. Diese ist im allgemeinen sehr viel einfacher zu konfigurieren als ``readline'', benötigt aber entweder die ``termcap''- oder ``ncurses''-Bibliothek.

--with-readline=<Pfad/zu/readline>
Teilt Bacula mit, wo readline installiert ist. Sofern es Teil der Standard-Bibliothek ist, findet Bacula normalerweise ``readline''. Wird es nicht gefunden, und ist der Schalter --with-readline gesetzt, wird readline deaktiviert. Diese Option betrifft Baculas Kompilierung. Mit Readline ist im der Console-Programm eine History und ein Editieren der Kommandozeile möglich. Readline wird nicht mehr unterstützt. Sie sind daher bei Problemen auf sich allein gestellt.

--enable-readline
Damit wird Bacula mitgeteilt, die Readline-Unterstütung zu ermöglichen. Das Paket scheint sich in inkompatibler Weise von Version zu Version zu ändern. Daher ist wegen der Vielzahl der Konfigurationsprobleme dieser Schalter normalerweise nicht gesetzt.

--with-tcp-wrappers=<Pfad/zur/TCP-Wrapper/Bibliothek>
Damit wird spezifiziert, dass Bacula mit TCP-Wrappern (man hosts_access(5)) kompiliert werden soll. Die Angabe des Pfades ist optional, da Bacula die Bibliotheken an den Standard-Speicherorten findet. Diese Option betrifft Baculas Kompilierung. Wenn Sie bei der Spezifikation der Einschränkungen in ihren /etc/hosts.allow- und /etc/hosts.deny-Dateien die twist-Option (hosts_options(5)) verwenden, wird sich der Bacula-Prozess beenden. Beachten Sie bitte, dass Sie beim Einrichten Ihrer /etc/hosts.allow- und /etc/hosts.deny-Dateien die infrage kommenden Bacula-Dämonen mit deren Namen aus der Konfigurationsdatei und nicht mit deren jeweiligen Programmnamen bezeichnen.

Weitere Informationen zur Konfiguration und zum Test der TCP-Wrapper im Abschnitt TCP Wrapper konfigurieren und testen des Kapitels zur Sicherheit.

--with-working-dir=<Pfad/zum/Arbeitsverzeichnis>
Die Angabe dieser Option ist zwingend und spezifizert das Verzeichnis, in welches Bacula zwischen seinen Ausführungen seine Dateien sichert. Wenn z.B. die interne Datenbank verwendet wird, werden deren Dateien hier abgelegt. Diese Option wird nur benutzt, um die Konfigurationsdateien der Dämonen zu verändern. Das Gleiche erreichen Sie, wenn Sie die Konfigurationsdateien nachträglich ändern. Das Arbeitsverzeichnis wird bei der Installation nicht automatisch erstellt, so dass Sie sicherstellen müssen, dass es vor der ersten Benutzung von Bacula vorhanden ist.

--with-base-port=<Port=Nummer>
Um funktioniern zu können, benötigt Bacula drei TCP/IC-Ports (einen für die Bacula-Console, einen für den Storage-Dämon und einen für den File-Dämon). Die Direktive --with-baseport weist automatisch drei Port Nummern zu, die mit der Basisadresse beginnen, die Sie spezifizieren. Auch in den sich ergebenden Konfigurationsdateien können Sie die Portnummern ändern. Sie müssen jedoch aufpassen, dass die Nummern in allen drei Konfigurationsdateien genau übereinstimmen. Der Vorgabe-Basisport hat die Nummer 9101. Damit sind die Ports 9101 bis 9103 zugewiesen. Diese Portnummern (9101, 9102, 9103) wurden von der IANA Bacula offiziell zugeteilt. Durch Setzen dieser Option verändern Sie nur die Konfigurationsdateien. Diese können Sie auch nach der Installation noch verändern.

--with-dump-email=<E-mail-Adresse>
Dieser Schalter spezifiziert die E-Mail-Adresse an die alle ``core dumps'' gesendet werden und wird normalerweise nur von Entwicklern verwendet.

--with-pid-dir=<Pfad>
Damit wird jenes Verzeichnis spezifiziert, in welchem Bacula die Datei mit den Prozess-IDs während seiner Ausführung ablegt. Vorgabemäßig ist dies /var/run. Diese Verzeichnis wird bei der Installation nicht angelegt. Daher sollten Sie sicher sein, dass es vorhanden ist, bevor Sie Bacula zum ersten Mal verwenden.

--with-subsys-dir=<Pfad>
Dieser Schalter spezifiziert den Ort, an dem Bacula die Subsystem-Lock Datei während seiner Ausführung ablegt. Vorgabe ist /var/run/subsys. Stellen Sie sicher, dass sie hierfür und das sbindir-Verzeichnis nicht das gleiche Verzeichnis spezifizieren. Dieses Verzeichnis wird nur innerhalb der Autostart-Skripten verwendet. Das ``subsys''-Verzeichnis wird bei Baculas Installation nicht erstellt, so dass Sie selbst sicherstellen müssen, dass es erstellt ist, bevor Sie Bacula verwenden.

--with-dir-password=<Passwort>
Mit diesem Schalter kann ein Passwort für den Zugang (in der Regel über das Console-Programm) zum Director spezifiziert werden. Ist der Schalter nicht gesetzt, generiert der Konfigurationsprozess ein zufälliges Passwort.

--with-fd-password=<Passwort>
Mit diesem Schalter kann ein Passwort für den Zugang zum File-Dämon spezifiziert werden (normalerweise vom Director aufgerufen). Wenn es nicht spezifiziert wurde, generiert der Konfigurationsprozess ein zufälliges Passwort.

--with-sd-password=<Passwort>
Mit diesem Schalter kann ein Passwort für den Zugang zum Storage-Dämon spezifiziert werden (normalerweise vom Director aufgerufen). Wenn es nicht spezifiziert wurde, generiert der Konfigurationsprozess ein zufälliges Passwort.

--with-dir-user=<User>

Durch Setzen dieses Schalters kann die User-ID festgelegt werden unter welcher der Director läuft. Der Director-Prozess muss als root gestartet werden, doch muss er nicht unter root laufen. Nach den ersten Initialisierungen kann er dem User übergeben werden, dessen ID Sie hier spezifizieren.

--with-dir-group=<Group>

Durch Setzen dieses Schalters kann die Group-ID festgelegt werden unter welcher der Director läuft. Der Director-Prozess muss als root gestartet werden, doch muss er nicht unter root laufen. Nach den ersten Initialisierungen kann er der Gruppe übergeben werden, deren ID Sie hier spezifizieren.

--with-sd-user=<User>
Mit diesem Schalter kann die User-ID festgelegt werden unter welcher der Storage-Dämon läuft. Der Storage-Dämon muss als root gestartet werden, doch muss er nicht unter root laufen. Nach den ersten Initialisierungen kann er dem User übergeben werden, dessen ID Sie hier spezifizieren. Wenn Sie diese Option verwenden, müssen Sie auch sicherstellen, dass der Storageprozess alle Geräte(Bandlaufwerke, usw.) verwenden darf, die er benötigt.

--with-sd-group=<Group>
Durch Setzen dieses Schalters kann die Group-ID festgelegt werden unter welcher der Storage-Dämon läuft. Der Storage-Dämon muss als root gestartet werden, doch muss er nicht unter root laufen. Nach den ersten Initialisierungen kann er der Gruppe übergeben werden, deren ID Sie hier spezifizieren.

--with-fd-user=<User>
Durch Setzen dieses Schalters kann die User-ID festgelegt werden unter welcher der File-Dämon läuft. Der File-Dämon muss als root gestartet werden und muss in den meisten Fällen auch unter root laufen. In ganz besonderen Fällen kann mit dieser Option der File-Dämon-Prozess nach den ersten Initialisierungen einem User übergeben werden, dessen ID Sie hier spezifizieren.

--with-fd-group=<Group>
Durch Setzen dieses Schalters kann die Group-ID festgelegt werden unter welcher der File-Dämon läuft. Der File-Dämon muss als root gestartet werden und muss in den meisten Fällen auch unter root laufen. Trotzdem kann der File-Dämon-Prozess nach den ersten Initialisierungen der Gruppe übergeben werden, deren ID Sie hier spezifizieren.

Beachten Sie bitte, dass durch Eingabe von ./configure --help noch viele andere Optionen angezeigt werden, diese aber bislang nicht implementiert sind.

Optionen, die wir für die meisten Systeme empfehlen

Wir empfehlen für die meisten Systeme mit folgenden Optionen zu beginnen:

./configure \
  --enable-smartalloc \
  --sbindir=$HOME/bacula/bin \
  --sysconfdir=$HOME/bacula/bin \
  --with-pid-dir=$HOME/bacula/bin/working \
  --with-subsys-dir=$HOME/bacula/bin/working \
  --with-mysql=$HOME/mysql \
  --with-working-dir=$HOME/bacula/working

Wenn Sie Bacula lieber in ein Installationsverzeichnis installieren wollen, als es aus seinem Kompilationsverzeichnis heraus zu betreiben (wie es Entwickler tun) müssen Sie den Schalter --sbindir and --sysconfdir mit den entsprechenden Pfaden verwenden. Dies ist nicht notwendig, wenn Sie ``make install'' nicht verwenden, wie es meistens bei der Programm-Entwicklung der Fall ist. Der Installationsprozess erzeugt die mit ``sbindir'' und ``sysconfdir'' angegebenen Verzeichnisse, aber nicht jene, die als ``pid-dir'', ``subsys-dir'' oder ``working-dir'' spezifiziert wurden. Sie müssen selbst sicherstellen, dass diese existieren, bevor Bacula das erste Mal läuft. Es folgt ein Beispiel dafür wie Kern das tut.

RedHat

Bei der Verwendung von SQLite:

 
CFLAGS="-g -Wall" ./configure \
  --sbindir=$HOME/bacula/bin \
  --sysconfdir=$HOME/bacula/bin \
  --enable-smartalloc \
  --with-sqlite=$HOME/bacula/depkgs/sqlite \
  --with-working-dir=$HOME/bacula/working \
  --with-pid-dir=$HOME/bacula/bin/working \
  --with-subsys-dir=$HOME/bacula/bin/working \
  --enable-gnome \
  --enable-conio

oder

 
CFLAGS="-g -Wall" ./configure \
  --sbindir=$HOME/bacula/bin \
  --sysconfdir=$HOME/bacula/bin \
  --enable-smartalloc \
  --with-mysql=$HOME/mysql \
  --with-working-dir=$HOME/bacula/working
  --with-pid-dir=$HOME/bacula/bin/working \
  --with-subsys-dir=$HOME/bacula/bin/working
  --enable-gnome \
  --enable-conio

oder, zum Schluss, eine vollständig traditionelle RedHat-Linux Installation:

CFLAGS="-g -Wall" ./configure \
  --prefix=/usr \
  --sbindir=/usr/sbin \
  --sysconfdir=/etc/bacula \
  --with-scriptdir=/etc/bacula \
  --enable-smartalloc \
  --enable-gnome \
  --with-mysql \
  --with-working-dir=/var/bacula \
  --with-pid-dir=/var/run \
  --enable-conio
Beachten Sie bitte, dass Bacula davon ausgeht, dass die Verzeichnisse /var/bacula, /var/run, und /var/lock/subsys bereits existieren und es diese während der Installation nicht automatisch erzeugt.

Beachten Sie bitte, dass bei Benutzung einer AMD64 CPU, die unter 64 bit CentOS4 läuft, mit gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) ein Compiler Bug auftritt, so dass Code erzeugt wird, der eine Segmentverletzung verusacht. Typischerweise macht sich dies zuerst beim Storage-Dämon bemerkbar. Eine Lösung ist es, Bacula ohne Optimierung zu kompilieren (normalerweise ist dies -O2).

Solaris

Um Bacula aus den Quellcodedateien zu erzeugen, muss auf dem Solaris-System bereits das folgende installiert sein (das ist es standardmäßig nicht): libiconv, gcc 3.3.2, stdc++, libgcc (wegen der stdc++- und gcc_s-Bibliotheken), make 3.8 oder neuer.

Möglicherweise muss die PATH-Umgebungsvariable um ``/usr/local/bin'' und ``/usr/ccs/bin'' (wegen ar) ergänzt werden

#!/bin/sh
CFLAGS="-g" ./configure \
  --sbindir=$HOME/bacula/bin \
  --sysconfdir=$HOME/bacula/bin \
  --with-mysql=$HOME/mysql \
  --enable-smartalloc \
  --with-pid-dir=$HOME/bacula/bin/working \
  --with-subsys-dir=$HOME/bacula/bin/working \
  --with-working-dir=$HOME/bacula/working

Wie oben schon erwähnt, erzeugt der Installationsprozess die mit ``sbindir'' und ``sysconfdir'' bezeichneten Verzeichnisse, falls sie nicht schon vorhanden sind. Die Verzeichnisse ``pid-dir'', ``subsys-dir'' und ``working-dir'' werden nicht automatisch erzeugt. Vergewissern Sie sich daher, dass sie existieren, bevor Bacula zum ersten Mal laufen soll.

Beachten Sie bitte, dass Sie möglicherweise die folgenden Pakete installieren müssen, um Bacula kompilieren zu können:

SUNWbinutils,
SUNWarc,
SUNWhea,
SUNWGcc,
SUNWGnutls
SUNWGnutls-devel
SUNWGmake
SUNWgccruntime
SUNWlibgcrypt
SUNWzlib
SUNWzlibs
SUNWbinutilsS
SUNWGmakeS
SUNWlibm

export 
PATH=/usr/bin::/usr/ccs/bin:/etc:/usr/openwin/bin:/usr/local/bin:/usr/sfw/bin:/opt/sfw/bin:/usr/ucb:/usr/sbin

FreeBSD

Unter The FreeBSD Diary gibt es eine detailierte Beschreibung wie Bacula unter diesem Betriebssystem intalliert wird. Benutzer von FreeBSD, die eine Version von vor 4.9-STABLE (Montag, 29. Dezember 2003, 15:18:01 UTC) verwenden, sollten das Kapitel Test der Bandlaufwerke in diesem Handbuch lesen. Darin sind wichtige Informationen, wie man das Bandlaufwerk so konfiguriert, dass es mit Bacula zusammenarbeitet.

Wenn Sie Bacula zusammen mit MySQL verwenden, sollten Sie darauf achten, MySQL eher mit den Thread-Bibliotheken von FreeBSD als mit denen von Linux zu kompilieren, weil Bacula selbst normalerweise so kompiliert wird. Eine Mischung von Beiden wird möglicherweise nicht funktionieren.

Win32

Um die Win32-Version des File-Client zu installieren, lesen Sie bitte das Kapitel Win32 Installation in diesem Handbuch.


Windows-Systeme mit installiertem CYGWIN

Seit der Version 1.34 verwendet Bacula für den Win32-File-Dämon CYGWIN nicht mehr. Er wird allerdings immer noch in einer CYGWIN-Umgebung kompiliert - möglicherweise funktioniert das aber auch mit dem Visual C -Studio allein. Wenn Sie den Win32-File-Dämon selbst kompilieren wollen, benötigen sie Microsoft C++ in der Version 6.0 oder höher. Für Bacula in den Versionen vor 1.3 wurde CYGWIN verwendet. Einzelheiten zur Kompilierung stehen in der README-Datei im Verzeichnis ``src/win32''.

Beachten Sie, dass, obwohl sich fast alle Elemente von Bacula unter Windows kompilieren lassen, nur der File-Dämon getestet und verwendet wurde.

Beachten Sie auf jeden Fall die Installationsanweisungen des Kapitels Win32-Installation in diesem Dokument.

Kerns Konfigurations-Skript

Dieses Skript verwende ich für meinen ``produktiven'' Linux-Rechner:

#!/bin/sh
# This is Kern's configure script for Bacula
CFLAGS="-g -Wall" \
  ./configure \
    --sbindir=$HOME/bacula/bin \
    --sysconfdir=$HOME/bacula/bin \
    --enable-smartalloc \
    --enable-gnome \
    --with-pid-dir=$HOME/bacula/bin/working \
    --with-subsys-dir=$HOME/bacula/bin/working \
    --with-mysql=$HOME/mysql \
    --with-working-dir=$HOME/bacula/bin/working \
    --with-dump-email=$USER \
    --with-smtp-host=mail.your-site.com \
    --with-baseport=9101
exit 0

Beachten Sie bitte, dass ich 9101 als Basis-Port definiere. Dadurch verwendet Bacula Port 9101 für die Director-Console, Port 9102 für die File-Dämonen und Port 9103 für die Storage-Dämonen. Diese Ports müssten auf allen Systemen verfügbar sein, da sie von der IANA (Internet Assigned Numbers Authority) offiziell für Bacula reserviert wurden. Wir raten dringend, nur diese Ports zu verwenden, um Konflikte mit anderen Programmen zu vermeiden. Wenn Sie die Option --with-baseport nicht verwenden, ist dies die Voreinstellung.

Eventuell können Sie auch noch das Folgende in Ihre /etc/services-Datei eintragen, was das Erkennen der Verbindungen, die Bacula verwendet, erleichtert (z.B. mit netstat -a):

bacula-dir      9101/tcp
bacula-fd       9102/tcp
bacula-sd       9103/tcp

Bacula installieren

Bevor man die Konfigurations-Dateien bearbeitet, wird man Bacula in dessen Zielverzeichnisse installieren wollen. Dies geschieht mit:

make install

Wenn Bacula zuvor schon installiert worden war, werden die Programmdateien überschrieben werden, die Konfigurationsdateien jedoch erhalten bleiben. An die Namen der ``neuen'' Konfigurationsdateien wird ein .new angehängt. Wenn Sie Bacula bereits installiert und betrieben hatten, werden Sie diese normalerweise verwerfen wollen oder ignorieren.

Einen File-Dämon oder Client-Prozess kompilieren

Wenn der Director und Storage-Dämon bei Ihnen auf einem Rechner läuft und Sie die Daten eines anderen Rechners sichern wollen, brauchen Sie auf diesem Rechner eine Kopie des File-Dämons. Sind der Rechner und das Betriebsystem gleich, genügt es, die Programmdatei bacula-fd und die Konfigurationsdatei bacula-fd.conf zu kopieren und dann den Name und das Passwort in der Konfigurationsdatei anzupassen, sodass diese eindeutig sind. Die entsprechenden Erweiterungen muss man auch in der Konfigurationsdatei des Directors (bacula-dir.conf) machen.

Ist die Rechnerachitektur und/oder das Betriebsystem verschieden, so muss der File-Dämon auf dem Client-Rechner kompiliert werden. Man verwendet hierzu den gleichen ./configure-Befehl wie für das Hauptprogramm und beginnt in einer neuen Kopie des Quellcode-Verzeichnisses oder indem man vor dem ./configure ein make distclean ausführt.

Da der File-Dämon nicht mit der Datenbank arbeitet, können die Optionen --with-mysql oder --with-sqlite entfernt werden. Durch die Verwendung des Schalters --enable-client-only werden nur die benötigten Bibliotheken und die Client-Programme erzeugt. Dadurch ist es nicht notwendig, die Datenbank-Programme zu installieren, nur um den File-Dämon zu erzeugen. Geben Sie zum Schluss einfach make ein. Damit wird nur das Client-Programm erzeugt.

Auto-Start der Dämon-Prozesse

Sollen die Dämon-Prozesse beim Booten Ihres Systems automatisch gestartet bzw. beendet werden (was sinnvoll ist), ist ein weiterer Schritt erforderlich. Als erstes muss der ``./configure''-Prozess Ihr System erkennen - es muss also unterstützt werden und darf nicht als unknown erkannt sein. Dann müssen die plattformspezifischen Dateien wie folgt installiert werden:

(become root)
make install-autostart

Die Möglichkeit des Auto-Starts ist nur für Systeme implementiert, die wir offiziell unterstützen (momentan FreeBSD, RedHat/Fedora-Linux und Solaris) und wurde bislang nur auf Fedora-Linux vollständig getestet.

Mit dem Befehl make install-autostart werden die entsprechenden Start-Skripte zusammen mit den notwendigen symbolischen Links installiert. Unter RedHat-Linux sind diese Skripte in den Verzeichnisssen /etc/rc.d/init.d/bacula-dir, /etc/rc.d/init.d/bacula-fd und /etc/rc.d/init.d/bacula-sd. Der genaue Speicherort hängt vom verwendeten Beriebssystem ab.

Wenn nur der File-Dämon installiert werden soll, können Sie dies mit folgendem Befehl tun:

make install-autostart-fd

Weitere Hinweise zur Kompilierung

Um eine Programmdatei in einem beliebigen Verzeichnis zu erzeugen, geben Sie einfach das folgende ein:

make

Um alle Objekt- und Programmdateien (auch die mit ``1'', ``2'' oder ``3'' bezeichneten Dateien, die Kern als temporäre Dateien verwendet) geben Sie folgendes ein:

make clean

Um wirklich alles für eine Distribution zu bereinigen:

make distclean

Beachten Sie bitte, dass dies alle Makefiles löscht und normalerweise auf der obersten Verzeichnisebene ausgeführt wird, um den Quellcode für eine Distribution vorzubereiten. Um dies rückgängig zu machen, muss ./configure auch von der obersten Verzeichnisebene ausgeführt werden, da alle Makefiles gelöscht sind.

Um einem Unterverzeichnis eine neue Datei hinzuzufügen, muss die Datei ``Makefile.in'' in jenem Verzeichnis bearbeitet werden. Danach genügt es, make einzugeben. In den meisten Fällen erzeugt der make-Befehl ein neues Makefile aus ``Makefile.in''. In manchen Fällen muss der make-Befehl wiederholt werden. In extremen Fällen wechselt man in die oberste Verzeichnisebene und gibt ein: make Makefiles.

Um Abhängigkeiten hinzuzufügen:

make depend

Mit make depend werden die Abhängigkeiten der Header-Dateien aller Objekt-Dateien dem Makefile und der Datei ``Makefile.in" hinzugefügt. Dieser Befehl sollte in allen Verzeichnissen ausgeführt werden, in welchen Sie die Abhängigkeiten ändern. Normalerweise muss der Befehl nur ausgeführt werden, wenn sie Quell- oder Header-Dateien hinzufügen oder löschen. make depend wird normalerweise während des Konfigurations-Prozesses automatisch aufgerufen.

Um zu installieren:

make install

Dieser Befehl wird verwendet, wenn Sie Bacula als Backup-System installieren wollen, nicht aber wenn Sie an Bacula selbst programmieren. Nach Ausführen des Befehls make install werden die folgenden Dateien auf Ihrem System installiert (mehr oder weniger). Welche Dateien und Verzeichnisse es im einzelnen sind, hängt von Ihrem ./configure-Befehl ab (wird z.B. GNOME nicht konfiguriert, wird auch ``gnome-console'' und ``gnome-console.conf'' nicht installiert. Wenn Sie SQLite anstatt MySQL verwenden, werden einige der Dateien andere sein).

bacula
bacula-dir
bacula-dir.conf
bacula-fd
bacula-fd.conf
bacula-sd
bacula-sd.conf
bacula-tray-monitor
tray-monitor.conf
bextract
bls
bscanBacula
btape
btraceback
btraceback.gdb
bconsole
bconsole.conf
create_mysql_database
dbcheck
delete_catalog_backup
drop_bacula_tables
drop_mysql_tables
fd
gnome-console
gnome-console.conf
make_bacula_tables
make_catalog_backup
make_mysql_tables
mtx-changer
query.sql
bsmtp
startmysql
stopmysqlBacula
wx-console
wx-console.conf

Die Installation des Tray-Monitors

Wenn Sie den Konfigurationsschalter --enable-tray-monitor verwendet und make install ausgeführt haben, ist der Tray-Monitor schon installiert.

Da Sie Ihre grafische Umgebung nicht als root betreiben (wenn doch, sollten sie das abstellen), müssen Sie den Usern Leserechte auf tray-monitor.conf und Ausführungsrechte für bacula-tray-monitor geben. Dies ist kein Sicherheitsrisiko.

Melden Sie sich bei Ihrer grafischen Umgebung an (KDE, Gnome oder eine andere), starten sie den bacula-tray-monitor als gewöhnlicher Benutzer und achten Sie darauf, ob das Cassetten-Icon irgendwo auf Ihrem Bildschirm erscheint (gewöhnlich in der Task-Leiste). Tut es das nicht, werfen Sie einen Blick auf die unten aufgeführten Anweisungen entsprechend Ihrer Umgebung oder Ihres Window-Managers.

GNOME

Ein System-Tray oder einen ``Benachrichtigungs-Bereich'' (um die GNOME-Terminologie zu verwenden), wird von GNOME seit der Version 2.2 unterstützt. Um sie zu aktivieren, klicken Sie rechts auf Ihre Kontrollleiste, öffnen das Menü Add to this Panel, dann auf Utility und klicken schließlich auf Notification Area.

KDE

Seit der Version 3.1 unterstützt KDE das System-Tray. Um es zu aktivieren, klicken Sie Ihre Kontrollleiste rechts, öffnen das Menü Zur Kontrollleiste hinzufügen, dann auf Miniprogramm und klicken schließlich auf Systemabschnitt der Kontrollleiste.

Andere Fenster-Manager

Lesen Sie die Dokumentation um zu erfahren, ob der Freedesktop System-Tray-Standard von Ihrem Fenster-Manager unterstützt wird und - wenn vorhanden - wie er aktiviert wird.

Die Bacula Konfigurations-Dateien bearbeiten

Schlagen Sie im Kapitel Bacula konfigurieren dieses Handbuches nach, wie sie die Konfigurationsdateien von Bacula einrichten.


Critical Items to Implement Before Going Production

General

We recommend you take your time before implementing a Bacula backup system since Bacula is a rather complex program, and if you make a mistake, you may suddenly find that you cannot restore your files in case of a disaster. This is especially true if you have not previously used a major backup product.

If you follow the instructions in this chapter, you will have covered most of the major problems that can occur. It goes without saying that if you ever find that we have left out an important point, please inform us, so that we can document it to the benefit of everyone.

Critical Items

The following assumes that you have installed Bacula, you more or less understand it, you have at least worked through the tutorial or have equivalent experience, and that you have set up a basic production configuration. If you haven't done the above, please do so and then come back here. The following is a sort of checklist that points with perhaps a brief explanation of why you should do it. You will find the details elsewhere in the manual. The order is more or less the order you would use in setting up a production system (if you already are in production, use the checklist anyway).

Recommended Items

Although these items may not be critical, they are recommended and will help you avoid problems.

If you absolutely must implement a system where you write a different tape each night and take it offsite in the morning. We recommend that you do several things:


A Brief Tutorial

This chapter will guide you through running Bacula. To do so, we assume you have installed Bacula, possibly in a single file as shown in the previous chapter, in which case, you can run Bacula as non-root for these tests. However, we assume that you have not changed the .conf files. If you have modified the .conf files, please go back and uninstall Bacula, then reinstall it, but do not make any changes. The examples in this chapter use the default configuration files, and will write the volumes to disk in your /tmp directory, in addition, the data backed up will be the source directory where you built Bacula. As a consequence, you can run all the Bacula daemons for these tests as non-root. Please note, in production, your File daemon(s) must run as root. See the Security chapter for more information on this subject.

The general flow of running Bacula is:

  1. cd <install-directory>
  2. Start the Database (if using MySQL or PostgreSQL)
  3. Start the Daemons with ./bacula start
  4. Start the Console program to interact with the Director
  5. Run a job
  6. When the Volume fills, unmount the Volume, if it is a tape, label a new one, and continue running. In this chapter, we will write only to disk files so you won't need to worry about tapes for the moment.
  7. Test recovering some files from the Volume just written to ensure the backup is good and that you know how to recover. Better test before disaster strikes
  8. Add a second client.

Each of these steps is described in more detail below.

Before Running Bacula

Before running Bacula for the first time in production, we recommend that you run the test command in the btape program as described in the Utility Program Chapter of this manual. This will help ensure that Bacula functions correctly with your tape drive. If you have a modern HP, Sony, or Quantum DDS or DLT tape drive running on Linux or Solaris, you can probably skip this test as Bacula is well tested with these drives and systems. For all other cases, you are strongly encouraged to run the test before continuing. btape also has a fill command that attempts to duplicate what Bacula does when filling a tape and writing on the next tape. You should consider trying this command as well, but be forewarned, it can take hours (about 4 hours on my drive) to fill a large capacity tape.


Starting the Database

If you are using MySQL or PostgreSQL as the Bacula database, you should start it before you attempt to run a job to avoid getting error messages from Bacula when it starts. The scripts startmysql and stopmysql are what I (Kern) use to start and stop my local MySQL. Note, if you are using SQLite, you will not want to use startmysql or stopmysql. If you are running this in production, you will probably want to find some way to automatically start MySQL or PostgreSQL after each system reboot.

If you are using SQLite (i.e. you specified the --with-sqlite=xxx option on the ./configure command, you need do nothing. SQLite is automatically started by Bacula.


Starting the Daemons

Assuming you have built from source or have installed the rpms, to start the three daemons, from your installation directory, simply enter:

./bacula start

The bacula script starts the Storage daemon, the File daemon, and the Director daemon, which all normally run as daemons in the background. If you are using the autostart feature of Bacula, your daemons will either be automatically started on reboot, or you can control them individually with the files bacula-dir, bacula-fd, and bacula-sd, which are usually located in /etc/init.d, though the actual location is system dependent. Some distributions may do this differently.

Note, on Windows, currently only the File daemon is ported, and it must be started differently. Please see the Windows Version of Bacula Chapter of this manual.

The rpm packages configure the daemons to run as user=root and group=bacula. The rpm installation also creates the group bacula if it does not exist on the system. Any users that you add to the group bacula will have access to files created by the daemons. To disable or alter this behavior edit the daemon startup scripts:

and then restart as noted above.

The installation chapter of this manual explains how you can install scripts that will automatically restart the daemons when the system starts.

Interacting with the Director to Query or Start Jobs

To communicate with the director and to query the state of Bacula or run jobs, from the top level directory, simply enter:

./bconsole

Alternatively to running the command line console, if you have GNOME installed and used the --enable-gnome on the configure command, you may use the GNOME Console program:

./gnome-console

Another possibilty is to run the wxWidgets program wx-console.

For simplicity, here we will describe only the ./bconsole program. Most of what is described here applies equally well to ./gnome-console and to wx-console

The ./bconsole runs the Bacula Console program, which connects to the Director daemon. Since Bacula is a network program, you can run the Console program anywhere on your network. Most frequently, however, one runs it on the same machine as the Director. Normally, the Console program will print something similar to the following:

[kern@polymatou bin]$ ./bconsole
Connecting to Director lpmatou:9101
1000 OK: HeadMan Version: 1.30 (28 April 2003)
*

the asterisk is the console command prompt.

Type help to see a list of available commands:

*help
  Command    Description
  =======    ===========
  add        add media to a pool
  autodisplay autodisplay [on/off] -- console messages
  automount  automount [on/off] -- after label
  cancel     cancel job=nnn -- cancel a job
  create     create DB Pool from resource
  delete     delete [pool=<pool-name> | media volume=<volume-name>]
  estimate   performs FileSet estimate debug=1 give full listing
  exit       exit = quit
  help       print this command
  label      label a tape
  list       list [pools | jobs | jobtotals | media <pool> |
             files jobid=<nn>]; from catalog
  llist      full or long list like list command
  messages   messages
  mount      mount <storage-name>
  prune      prune expired records from catalog
  purge      purge records from catalog
  query      query catalog
  quit       quit
  relabel    relabel a tape
  release    release <storage-name>
  restore    restore files
  run        run <job-name>
  setdebug   sets debug level
  show       show (resource records) [jobs | pools | ... | all]
  sqlquery   use SQL to query catalog
  status     status [storage | client]=<name>
  time       print current time
  unmount    unmount <storage-name>
  update     update Volume or Pool
  use        use catalog xxx
  var        does variable expansion
  version    print Director version
  wait       wait until no jobs are running
*

Details of the console program's commands are explained in the Console Chapter of this manual.


Running a Job

At this point, we assume you have done the following:

Furthermore, we assume for the moment you are using the default configuration files.

At this point, enter the following command:

show filesets

and you should get something similar to:

FileSet: name=Full Set
      Inc: /home/kern/bacula/bacula-1.30
      Exc: /proc
      Exc: /tmp
      Exc: /.journal
      Exc: /.fsck
FileSet: name=Catalog
      Inc: /home/kern/bacula/testbin/working/bacula.sql

This is a pre-defined FileSet that will backup the Bacula source directory. The actual directory names printed should correspond to your system configuration. For testing purposes, we have chosen a directory of moderate size (about 40 Megabytes) and complexity without being too big. The FileSet Catalog is used for backing up Bacula's catalog and is not of interest to us for the moment. The Inc: entries are the files or directories that will be included in the backup and the Exc: are those that will be excluded. You can change what is backed up by editing bacula-dir.conf and changing the File = line in the FileSet resource.

Now is the time to run your first backup job. We are going to backup your Bacula source directory to a File Volume in your /tmp directory just to show you how easy it is. Now enter:

status dir

and you should get the following output:

rufus-dir Version: 1.30 (28 April 2003)
Daemon started 28-Apr-2003 14:03, 0 Jobs run.
Console connected at 28-Apr-2003 14:03
No jobs are running.
Level          Type     Scheduled          Name
=================================================================
Incremental    Backup   29-Apr-2003 01:05  Client1
Full           Backup   29-Apr-2003 01:10  BackupCatalog
====

where the times and the Director's name will be different according to your setup. This shows that an Incremental job is scheduled to run for the Job Client1 at 1:05am and that at 1:10, a BackupCatalog is scheduled to run. Note, you should probably change the name Client1 to be the name of your machine, if not, when you add additional clients, it will be very confusing. For my real machine, I use Rufus rather than Client1 as in this example.

Now enter:

status client

and you should get something like:

The defined Client resources are:
     1: rufus-fd
Item 1 selected automatically.
Connecting to Client rufus-fd at rufus:8102
rufus-fd Version: 1.30 (28 April 2003)
Daemon started 28-Apr-2003 14:03, 0 Jobs run.
Director connected at: 28-Apr-2003 14:14
No jobs running.
====

In this case, the client is named rufus-fd your name will be different, but the line beginning with rufus-fd Version ... is printed by your File daemon, so we are now sure it is up and running.

Finally do the same for your Storage daemon with:

status storage

and you should get:

The defined Storage resources are:
     1: File
Item 1 selected automatically.
Connecting to Storage daemon File at rufus:8103
rufus-sd Version: 1.30 (28 April 2003)
Daemon started 28-Apr-2003 14:03, 0 Jobs run.
Device /tmp is not open.
No jobs running.
====

You will notice that the default Storage daemon device is named File and that it will use device /tmp, which is not currently open.

Now, let's actually run a job with:

run

you should get the following output:

Using default Catalog name=MyCatalog DB=bacula
A job name must be specified.
The defined Job resources are:
     1: Client1
     2: BackupCatalog
     3: RestoreFiles
Select Job resource (1-3):

Here, Bacula has listed the three different Jobs that you can run, and you should choose number 1 and type enter, at which point you will get:

Run Backup job
JobName:  Client1
FileSet:  Full Set
Level:    Incremental
Client:   rufus-fd
Storage:  File
Pool:     Default
When:     2003-04-28 14:18:57
OK to run? (yes/mod/no):

At this point, take some time to look carefully at what is printed and understand it. It is asking you if it is OK to run a job named Client1 with FileSet Full Set (we listed above) as an Incremental job on your Client (your client name will be different), and to use Storage File and Pool Default, and finally, it wants to run it now (the current time should be displayed by your console).

Here we have the choice to run (yes), to modify one or more of the above parameters (mod), or to not run the job (no). Please enter yes, at which point you should immediately get the command prompt (an asterisk). If you wait a few seconds, then enter the command messages you will get back something like:

28-Apr-2003 14:22 rufus-dir: Last FULL backup time not found. Doing
                  FULL backup.
28-Apr-2003 14:22 rufus-dir: Start Backup JobId 1,
                  Job=Client1.2003-04-28_14.22.33
28-Apr-2003 14:22 rufus-sd: Job Client1.2003-04-28_14.22.33 waiting.
                  Cannot find any appendable volumes.
Please use the "label"  command to create a new Volume for:
    Storage:      FileStorage
    Media type:   File
    Pool:         Default

The first message, indicates that no previous Full backup was done, so Bacula is upgrading our Incremental job to a Full backup (this is normal). The second message indicates that the job started with JobId 1., and the third message tells us that Bacula cannot find any Volumes in the Pool for writing the output. This is normal because we have not yet created (labeled) any Volumes. Bacula indicates to you all the details of the volume it needs.

At this point, the job is BLOCKED waiting for a Volume. You can check this if you want by doing a status dir. In order to continue, we must create a Volume that Bacula can write on. We do so with:

label

and Bacula will print:

The defined Storage resources are:
     1: File
Item 1 selected automatically.
Enter new Volume name:

at which point, you should enter some name beginning with a letter and containing only letters and numbers (period, hyphen, and underscore) are also permitted. For example, enter TestVolume001, and you should get back:

Defined Pools:
     1: Default
Item 1 selected automatically.
Connecting to Storage daemon File at rufus:8103 ...
Sending label command for Volume "TestVolume001" Slot 0 ...
3000 OK label. Volume=TestVolume001 Device=/tmp
Catalog record for Volume "TestVolume002", Slot 0  successfully created.
Requesting mount FileStorage ...
3001 OK mount. Device=/tmp

Finally, enter messages and you should get something like:

28-Apr-2003 14:30 rufus-sd: Wrote label to prelabeled Volume
   "TestVolume001" on device /tmp
28-Apr-2003 14:30 rufus-dir: Bacula 1.30 (28Apr03): 28-Apr-2003 14:30
JobId:                  1
Job:                    Client1.2003-04-28_14.22.33
FileSet:                Full Set
Backup Level:           Full
Client:                 rufus-fd
Start time:             28-Apr-2003 14:22
End time:               28-Apr-2003 14:30
Files Written:          1,444
Bytes Written:          38,988,877
Rate:                   81.2 KB/s
Software Compression:   None
Volume names(s):        TestVolume001
Volume Session Id:      1
Volume Session Time:    1051531381
Last Volume Bytes:      39,072,359
FD termination status:  OK
SD termination status:  OK
Termination:            Backup OK
28-Apr-2003 14:30 rufus-dir: Begin pruning Jobs.
28-Apr-2003 14:30 rufus-dir: No Jobs found to prune.
28-Apr-2003 14:30 rufus-dir: Begin pruning Files.
28-Apr-2003 14:30 rufus-dir: No Files found to prune.
28-Apr-2003 14:30 rufus-dir: End auto prune.

If you don't see the output immediately, you can keep entering messages until the job terminates, or you can enter, autodisplay on and your messages will automatically be displayed as soon as they are ready.

If you do an ls -l of your /tmp directory, you will see that you have the following item:

-rw-r-----    1 kern     kern     39072153 Apr 28 14:30 TestVolume001

This is the file Volume that you just wrote and it contains all the data of the job just run. If you run additional jobs, they will be appended to this Volume unless you specify otherwise.

You might ask yourself if you have to label all the Volumes that Bacula is going to use. The answer for disk Volumes, like the one we used, is no. It is possible to have Bacula automatically label volumes. For tape Volumes, you will most likely have to label each of the Volumes you want to use.

If you would like to stop here, you can simply enter quit in the Console program, and you can stop Bacula with ./bacula stop. To clean up, simply delete the file /tmp/TestVolume001, and you should also re-initialize your database using:

./drop_bacula_tables
./make_bacula_tables

Please note that this will erase all information about the previous jobs that have run, and that you might want to do it now while testing but that normally you will not want to re-initialize your database.

If you would like to try restoring the files that you just backed up, read the following section.

Restoring Your Files

If you have run the default configuration and the save of the Bacula source code as demonstrated above, you can restore the backed up files in the Console program by entering:

restore all

where you will get:

First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.

To select the JobIds, you have the following choices:
     1: List last 20 Jobs run
     2: List Jobs where a given File is saved
     3: Enter list of comma separated JobIds to select
     4: Enter SQL list command
     5: Select the most recent backup for a client
     6: Select backup for a client before a specified time
     7: Enter a list of files to restore
     8: Enter a list of files to restore before a specified time
     9: Find the JobIds of the most recent backup for a client
    10: Find the JobIds for a backup for a client before a specified time
    11: Enter a list of directories to restore for found JobIds
    12: Cancel
Select item:  (1-12):

As you can see, there are a number of options, but for the current demonstration, please enter 5 to do a restore of the last backup you did, and you will get the following output:

Defined Clients:
     1: rufus-fd
Item 1 selected automatically.
The defined FileSet resources are:
     1: 1  Full Set  2003-04-28 14:22:33
Item 1 selected automatically.
+-------+-------+----------+---------------------+---------------+
| JobId | Level | JobFiles | StartTime           | VolumeName    |
+-------+-------+----------+---------------------+---------------+
| 1     | F     | 1444     | 2003-04-28 14:22:33 | TestVolume002 |
+-------+-------+----------+---------------------+---------------+
You have selected the following JobId: 1
Building directory tree for JobId 1 ...
1 Job inserted into the tree and marked for extraction.
The defined Storage resources are:
     1: File
Item 1 selected automatically.
You are now entering file selection mode where you add and
remove files to be restored. All files are initially added.
Enter "done" to leave this mode.
cwd is: /
$

where I have truncated the listing on the right side to make it more readable. As you can see by starting at the top of the listing, Bacula knows what client you have, and since there was only one, it selected it automatically, likewise for the FileSet. Then Bacula produced a listing containing all the jobs that form the current backup, in this case, there is only one, and the Storage daemon was also automatically chosen. Bacula then took all the files that were in Job number 1 and entered them into a directory tree (a sort of in memory representation of your filesystem). At this point, you can use the cd and ls ro dir commands to walk up and down the directory tree and view what files will be restored. For example, if I enter cd /home/kern/bacula/bacula-1.30 and then enter dir I will get a listing of all the files in the Bacula source directory. On your system, the path will be somewhat different. For more information on this, please refer to the Restore Command Chapter of this manual for more details.

To exit this mode, simply enter:

done

and you will get the following output:

Bootstrap records written to
   /home/kern/bacula/testbin/working/restore.bsr
The restore job will require the following Volumes:
   
   TestVolume001
1444 files selected to restore.
Run Restore job
JobName:    RestoreFiles
Bootstrap:  /home/kern/bacula/testbin/working/restore.bsr
Where:      /tmp/bacula-restores
Replace:    always
FileSet:    Full Set
Client:     rufus-fd
Storage:    File
JobId:      *None*
When:       2005-04-28 14:53:54
OK to run? (yes/mod/no):

If you answer yes your files will be restored to /tmp/bacula-restores. If you want to restore the files to their original locations, you must use the mod option and explicitly set Where: to nothing (or to /). We recommend you go ahead and answer yes and after a brief moment, enter messages, at which point you should get a listing of all the files that were restored as well as a summary of the job that looks similar to this:

28-Apr-2005 14:56 rufus-dir: Bacula 1.30 (28Apr03): 28-Apr-2003 14:56
JobId:                  2
Job:                    RestoreFiles.2005-04-28_14.56.06
Client:                 rufus-fd
Start time:             28-Apr-2005 14:56
End time:               28-Apr-2005 14:56
Files Restored:         1,444
Bytes Restored:         38,816,381
Rate:                   9704.1 KB/s
FD termination status:  OK
Termination:            Restore OK
28-Apr-2005 14:56 rufus-dir: Begin pruning Jobs.
28-Apr-2005 14:56 rufus-dir: No Jobs found to prune.
28-Apr-2005 14:56 rufus-dir: Begin pruning Files.
28-Apr-2005 14:56 rufus-dir: No Files found to prune.
28-Apr-2005 14:56 rufus-dir: End auto prune.

After exiting the Console program, you can examine the files in /tmp/bacula-restores, which will contain a small directory tree with all the files. Be sure to clean up at the end with:

rm -rf /tmp/bacula-restore

Quitting the Console Program

Simply enter the command quit.

Adding a Second Client

If you have gotten the example shown above to work on your system, you may be ready to add a second Client (File daemon). That is you have a second machine that you would like backed up. The only part you need installed on the other machine is the binary bacula-fd (or bacula-fd.exe for Windows) and its configuration file bacula-fd.conf. You can start with the same bacula-fd.conf file that you are currently using and make one minor modification to it to create the conf file for your second client. Change the File daemon name from whatever was configured, rufus-fd in the example above, but your system will have a different name. The best is to change it to the name of your second machine. For example:

...
#
# "Global" File daemon configuration specifications
#
FileDaemon {                          # this is me
  Name = rufus-fd
  FDport = 9102                  # where we listen for the director
  WorkingDirectory = /home/kern/bacula/working
  Pid Directory = /var/run
}
...

would become:

...
#
# "Global" File daemon configuration specifications
#
FileDaemon {                          # this is me
  Name = matou-fd
  FDport = 9102                  # where we listen for the director
  WorkingDirectory = /home/kern/bacula/working
  Pid Directory = /var/run
}
...

where I show just a portion of the file and have changed rufus-fd to matou-fd. The names you use are your choice. For the moment, I recommend you change nothing else. Later, you will want to change the password.

Now you should install that change on your second machine. Then you need to make some additions to your Director's configuration file to define the new File daemon or Client. Starting from our original example which should be installed on your system, you should add the following lines (essentially copies of the existing data but with the names changed) to your Director's configuration file bacula-dir.conf.

#
# Define the main nightly save backup job
#   By default, this job will back up to disk in /tmp
Job {
  Name = "Matou"
  Type = Backup
  Client = matou-fd
  FileSet = "Full Set"
  Schedule = "WeeklyCycle"
  Storage = File
  Messages = Standard
  Pool = Default
  Write Bootstrap = "/home/kern/bacula/working/matou.bsr"
}
# Client (File Services) to backup
Client {
  Name = matou-fd
  Address = matou
  FDPort = 9102
  Catalog = MyCatalog
  Password = "xxxxx"                  # password for
  File Retention = 30d                # 30 days
  Job Retention = 180d                # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
}

Then make sure that the Address parameter in the Storage resource is set to the fully qualified domain name and not to something like "localhost". The address specified is sent to the File daemon (client) and it must be a fully qualified domain name. If you pass something like "localhost" it will not resolve correctly and will result in a time out when the File daemon fails to connect to the Storage daemon.

That is all that is necessary. I copied the existing resource to create a second Job (Matou) to backup the second client (matou-fd). It has the name Matou, the Client is named matou-fd, and the bootstrap file name is changed, but everything else is the same. This means that Matou will be backed up on the same schedule using the same set of tapes. You may want to change that later, but for now, let's keep it simple.

The second change was to add a new Client resource that defines matou-fd and has the correct address matou, but in real life, you may need a fully qualified machine address or an IP address. I also kept the password the same (shown as xxxxx for the example).

At this point, if you stop Bacula and restart it, and start the Client on the other machine, everything will be ready, and the prompts that you saw above will now include the second machine.

To make this a real production installation, you will possibly want to use different Pool, or a different schedule. It is up to you to customize. In any case, you should change the password in both the Director's file and the Client's file for additional security.

For some important tips on changing names and passwords, and a diagram of what names and passwords must match, please see Authorization Errors in the FAQ chapter of this manual.


When The Tape Fills

If you have scheduled your job, typically nightly, there will come a time when the tape fills up and Bacula cannot continue. In this case, Bacula will send you a message similar to the following:

rufus-sd: block.c:337 === Write error errno=28: ERR=No space left
          on device

This indicates that Bacula got a write error because the tape is full. Bacula will then search the Pool specified for your Job looking for an appendable volume. In the best of all cases, you will have properly set your Retention Periods and you will have all your tapes marked to be Recycled, and Bacula will automatically recycle the tapes in your pool requesting and overwriting old Volumes. For more information on recycling, please see the Recycling chapter of this manual. If you find that your Volumes were not properly recycled (usually because of a configuration error), please see the Manually Recycling Volumes section of the Recycling chapter.

If like me, you have a very large set of Volumes and you label them with the date the Volume was first writing, or you have not set up your Retention periods, Bacula will not find a tape in the pool, and it will send you a message similar to the following:

rufus-sd: Job kernsave.2002-09-19.10:50:48 waiting. Cannot find any
          appendable volumes.
Please use the "label"  command to create a new Volume for:
    Storage:      SDT-10000
    Media type:   DDS-4
    Pool:         Default

Until you create a new Volume, this message will be repeated an hour later, then two hours later, and so on doubling the interval each time up to a maximum interval of 1 day.

The obvious question at this point is: What do I do now?

The answer is simple: first, using the Console program, close the tape drive using the unmount command. If you only have a single drive, it will be automatically selected, otherwise, make sure you release the one specified on the message (in this case STD-10000).

Next, you remove the tape from the drive and insert a new blank tape. Note, on some older tape drives, you may need to write an end of file mark (mt -f /dev/nst0 weof) to prevent the drive from running away when Bacula attempts to read the label.

Finally, you use the label command in the Console to write a label to the new Volume. The label command will contact the Storage daemon to write the software label, if it is successful, it will add the new Volume to the Pool, then issue a mount command to the Storage daemon. See the previous sections of this chapter for more details on labeling tapes.

The result is that Bacula will continue the previous Job writing the backup to the new Volume.

If you have a Pool of volumes and Bacula is cycling through them, instead of the above message "Cannot find any appendable volumes.", Bacula may ask you to mount a specific volume. In that case, you should attempt to do just that. If you do not have the volume any more (for any of a number of reasons), you can simply mount another volume from the same Pool, providing it is appendable, and Bacula will use it. You can use the list volumes command in the console program to determine which volumes are appendable and which are not.

If like me, you have your Volume retention periods set correctly, but you have no more free Volumes, you can relabel and reuse a Volume as follows:

To manually relabel the Volume use the following additional steps:

Other Useful Console Commands

status dir
Print a status of all running jobs and jobs scheduled in the next 24 hours.

status
The console program will prompt you to select a daemon type, then will request the daemon's status.

status jobid=nn
Print a status of JobId nn if it is running. The Storage daemon is contacted and requested to print a current status of the job as well.

list pools
List the pools defined in the Catalog (normally only Default is used).

list media
Lists all the media defined in the Catalog.

list jobs
Lists all jobs in the Catalog that have run.

list jobid=nn
Lists JobId nn from the Catalog.

list jobtotals
Lists totals for all jobs in the Catalog.

list files jobid=nn
List the files that were saved for JobId nn.

list jobmedia
List the media information for each Job run.

messages
Prints any messages that have been directed to the console.

unmount storage=storage-name
Unmounts the drive associated with the storage device with the name storage-name if the drive is not currently being used. This command is used if you wish Bacula to free the drive so that you can use it to label a tape.

mount storage=storage-name
Causes the drive associated with the storage device to be mounted again. When Bacula reaches the end of a volume and requests you to mount a new volume, you must issue this command after you have placed the new volume in the drive. In effect, it is the signal needed by Bacula to know to start reading or writing the new volume.

quit
Exit or quit the console program.

Most of the commands given above, with the exception of list, will prompt you for the necessary arguments if you simply enter the command name.

Debug Daemon Output

If you want debug output from the daemons as they are running, start the daemons from the install directory as follows:

./bacula start -d100

This can be particularly helpful if your daemons do not start correctly, because direct daemon output to the console is normally directed to the NULL device, but with the debug level greater than zero, the output will be sent to the starting terminal.

To stop the three daemons, enter the following from the install directory:

./bacula stop

The execution of bacula stop may complain about pids not found. This is OK, especially if one of the daemons has died, which is very rare.

To do a full system save, each File daemon must be running as root so that it will have permission to access all the files. None of the other daemons require root privileges. However, the Storage daemon must be able to open the tape drives. On many systems, only root can access the tape drives. Either run the Storage daemon as root, or change the permissions on the tape devices to permit non-root access. MySQL and PostgreSQL can be installed and run with any userid; root privilege is not necessary.

Have Patience When Starting the Daemons or Mounting Blank Tapes

When you start the Bacula daemons, the Storage daemon attempts to open all defined storage devices and verify the currently mounted Volume (if configured). Until all the storage devices are verified, the Storage daemon will not accept connections from the Console program. If a tape was previously used, it will be rewound, and on some devices this can take several minutes. As a consequence, you may need to have a bit of patience when first contacting the Storage daemon after starting the daemons. If you can see your tape drive, once the lights stop flashing, the drive will be ready to be used.

The same considerations apply if you have just mounted a blank tape in a drive such as an HP DLT. It can take a minute or two before the drive properly recognizes that the tape is blank. If you attempt to mount the tape with the Console program during this recognition period, it is quite possible that you will hang your SCSI driver (at least on my RedHat Linux system). As a consequence, you are again urged to have patience when inserting blank tapes. Let the device settle down before attempting to access it.

Difficulties Connecting from the FD to the SD

If you are having difficulties getting one or more of your File daemons to connect to the Storage daemon, it is most likely because you have not used a fully qualified Internet address on the Address directive in the Director's Storage resource. That is the resolver on the File daemon's machine (not on the Director's) must be able to resolve the name you supply into an IP address. An example of an address that is guaranteed not to work: localhost. An example that may work: megalon. An example that is more likely to work: magalon.mydomain.com. On Win32 if you don't have a good resolver (often true on older Win98 systems), you might try using an IP address in place of a name.

If your address is correct, then make sure that no other program is using the port 9103 on the Storage daemon's machine. The Bacula port number are authorized by IANA, and should not be used by other programs, but apparently some HP printers do use these port numbers. A netstat -a on the Storage daemon's machine can determine who is using the 9103 port (used for FD to SD communications in Bacula).

Daemon Command Line Options

Each of the three daemons (Director, File, Storage) accepts a small set of options on the command line. In general, each of the daemons as well as the Console program accepts the following options:

-c <file>
Define the file to use as a configuration file. The default is the daemon name followed by .conf i.e. bacula-dir.conf for the Director, bacula-fd.conf for the File daemon, and bacula-sd for the Storage daemon.

-d nn
Set the debug level to nn. Higher levels of debug cause more information to be displayed on STDOUT concerning what the daemon is doing.

-f
Run the daemon in the foreground. This option is needed to run the daemon under the debugger.

-s
Do not trap signals. This option is needed to run the daemon under the debugger.

-t
Read the configuration file and print any error messages, then immediately exit. Useful for syntax testing of new configuration files.

-v
Be more verbose or more complete in printing error and informational messages. Recommended.

-?
Print the version and list of options.

The Director has the following additional Director specific option:

-r <job>
Run the named job immediately. This is for debugging and should not be used.

The File daemon has the following File daemon specific option:

-i
Assume that the daemon is called from inetd or xinetd. In this case, the daemon assumes that a connection has already been made and that it is passed as STDIN. After the connection terminates the daemon will exit.

The Storage daemon has no Storage daemon specific options.

The Console program has no console specific options.


Creating a Pool

Creating the Pool is automatically done when Bacula starts, so if you understand Pools, you can skip to the next section.

When you run a job, one of the things that Bacula must know is what Volumes to use to backup the FileSet. Instead of specifying a Volume (tape) directly, you specify which Pool of Volumes you want Bacula to consult when it wants a tape for writing backups. Bacula will select the first available Volume from the Pool that is appropriate for the Storage device you have specified for the Job being run. When a volume has filled up with data, Bacula will change its VolStatus from Append to Full, and then Bacula will use the next volume and so on. If no appendable Volume exists in the Pool, the Director will attempt to recycle an old Volume, if there are still no appendable Volumes available, Bacula will send a message requesting the operator to create an appropriate Volume.

Bacula keeps track of the Pool name, the volumes contained in the Pool, and a number of attributes of each of those Volumes.

When Bacula starts, it ensures that all Pool resource definitions have been recorded in the catalog. You can verify this by entering:

list pools

to the console program, which should print something like the following:

*list pools
Using default Catalog name=MySQL DB=bacula
+--------+---------+---------+---------+----------+-------------+
| PoolId | Name    | NumVols | MaxVols | PoolType | LabelFormat |
+--------+---------+---------+---------+----------+-------------+
| 1      | Default | 3       | 0       | Backup   | *           |
| 2      | File    | 12      | 12      | Backup   | File        |
+--------+---------+---------+---------+----------+-------------+
*

If you attempt to create the same Pool name a second time, Bacula will print:

Error: Pool Default already exists.
Once created, you may use the {\bf update} command to
modify many of the values in the Pool record.

Labeling Your Volumes

Bacula requires that each Volume contains a software label. There are several strategies for labeling volumes. The one I use is to label them as they are needed by Bacula using the console program. That is when Bacula needs a new Volume, and it does not find one in the catalog, it will send me an email message requesting that I add Volumes to the Pool. I then use the label command in the Console program to label a new Volume and to define it in the Pool database, after which Bacula will begin writing on the new Volume. Alternatively, I can use the Console relabel command to relabel a Volume that is no longer used providing it has VolStatus Purged.

Another strategy is to label a set of volumes at the start, then use them as Bacula requests them. This is most often done if you are cycling through a set of tapes, for example using an autochanger. For more details on recycling, please see the Automatic Volume Recycling chapter of this manual.

If you run a Bacula job, and you have no labeled tapes in the Pool, Bacula will inform you, and you can create them "on-the-fly" so to speak. In my case, I label my tapes with the date, for example: DLT-18April02. See below for the details of using the label command.

Labeling Volumes with the Console Program

Labeling volumes is normally done by using the console program.

  1. ./bconsole
  2. label

If Bacula complains that you cannot label the tape because it is already labeled, simply unmount the tape using the unmount command in the console, then physically mount a blank tape and re-issue the label command.

Since the physical storage media is different for each device, the label command will provide you with a list of the defined Storage resources such as the following:

The defined Storage resources are:
     1: File
     2: 8mmDrive
     3: DLTDrive
     4: SDT-10000
Select Storage resource (1-4):

At this point, you should have a blank tape in the drive corresponding to the Storage resource that you select.

It will then ask you for the Volume name.

Enter new Volume name:

If Bacula complains:

Media record for Volume xxxx already exists.

It means that the volume name xxxx that you entered already exists in the Media database. You can list all the defined Media (Volumes) with the list media command. Note, the LastWritten column has been truncated for proper printing.

+---------------+---------+--------+----------------+-----/~/-+------------+-----+
| VolumeName    | MediaTyp| VolStat| VolBytes       | LastWri | VolReten   | Recy|
+---------------+---------+--------+----------------+---------+------------+-----+
| DLTVol0002    | DLT8000 | Purged | 56,128,042,217 | 2001-10 | 31,536,000 |   0 |
| DLT-07Oct2001 | DLT8000 | Full   | 56,172,030,586 | 2001-11 | 31,536,000 |   0 |
| DLT-08Nov2001 | DLT8000 | Full   | 55,691,684,216 | 2001-12 | 31,536,000 |   0 |
| DLT-01Dec2001 | DLT8000 | Full   | 55,162,215,866 | 2001-12 | 31,536,000 |   0 |
| DLT-28Dec2001 | DLT8000 | Full   | 57,888,007,042 | 2002-01 | 31,536,000 |   0 |
| DLT-20Jan2002 | DLT8000 | Full   | 57,003,507,308 | 2002-02 | 31,536,000 |   0 |
| DLT-16Feb2002 | DLT8000 | Full   | 55,772,630,824 | 2002-03 | 31,536,000 |   0 |
| DLT-12Mar2002 | DLT8000 | Full   | 50,666,320,453 | 1970-01 | 31,536,000 |   0 |
| DLT-27Mar2002 | DLT8000 | Full   | 57,592,952,309 | 2002-04 | 31,536,000 |   0 |
| DLT-15Apr2002 | DLT8000 | Full   | 57,190,864,185 | 2002-05 | 31,536,000 |   0 |
| DLT-04May2002 | DLT8000 | Full   | 60,486,677,724 | 2002-05 | 31,536,000 |   0 |
| DLT-26May02   | DLT8000 | Append |  1,336,699,620 | 2002-05 | 31,536,000 |   1 |
+---------------+---------+--------+----------------+-----/~/-+------------+-----+

Once Bacula has verified that the volume does not already exist, it will prompt you for the name of the Pool in which the Volume (tape) is to be created. If there is only one Pool (Default), it will be automatically selected.

If the tape is successfully labeled, a Volume record will also be created in the Pool. That is the Volume name and all its other attributes will appear when you list the Pool. In addition, that Volume will be available for backup if the MediaType matches what is requested by the Storage daemon.

When you labeled the tape, you answered very few questions about it -- principally the Volume name, and perhaps the Slot. However, a Volume record in the catalog database (internally known as a Media record) contains quite a few attributes. Most of these attributes will be filled in from the default values that were defined in the Pool (i.e. the Pool holds most of the default attributes used when creating a Volume).

It is also possible to add media to the pool without physically labeling the Volumes. This can be done with the add command. For more information, please see the Console Chapter of this manual.

Kern Sibbald 2008-01-31