%%
%%

\chapter{Was ist Bacula?}
\label{GeneralChapter}
\index[general]{Bacula!Was ist }
\index[general]{Was ist Bacula? }


Bacula ist ein System von Computerprogrammen, mit denen Sie 
(oder der System-Administrator) in der Lage sind, Computerdaten innerhalb eines 
heterogenen Netzwerkes zu sichern, die Sicherungen wiederherzustellen und zu \"{u}berpr\"{u}fen.
Bacula kann aber auch auf nur einem einzigen Computer benutzt werden und
auf verschiedene Arten von Medien, wie B\"{a}nder oder Festplatten sichern.

Technisch gesehen ist es ein netzwerkf\"{a}higes
Sicherungsprogramm mit Client/Server-Architektur. 
Bacula ist leistungsf\"{a}hig und vergleichsweise einfach zu benutzen. 
Dabei hat es viele anspruchsvolle Funktionen zur Verwaltung der Sicherung,
die das Auffinden und die Wiederherstellung besch\"{a}digter oder verlorener 
Dateien erleichtern. Durch seinen modularen Aufbau l\"{a}sst es sich jedem System
anpassen: Vom Einzelplatzrechner bis zu einem gro{\ss}en System mit hunderten von
Computern, die \"{u}ber ein weitr\"{a}umiges Netzwerk verteilt sind.

\section{Wer ben\"{o}tigt Bacula?}
\index[general]{Wer ben\"{o}tigt Bacula? }
\index[general]{Bacula!Wer ben\"{o}tigt }

Wenn Sie momentan Programme wie tar, dump oder 
bru zur Datensicherung verwenden und eine Netzwerkl\"{o}sung, gr\"{o}{\ss}ere Flexibilit\"{a}t
oder einen Verzeichnis-Dienst suchen, wird Bacula wahrscheinlich die
zus\"{a}tzlichen Funktionen zur Verf\"{u}gung stellen, die Sie suchen. Wenn Sie dagegen
ein UNIX-Neuling sind oder keine weitergehenden Erfahrung mit
anspruchsvollen Sicherungsprogrammen haben, raten wir von Bacula ab, da es in
der Einrichtung und der Benutzung sehr viel komplizierter ist als z.B. 
tar oder dump. 

Wenn Bacula, wie die oben genannten einfachen Programme funktionieren und
einfach nur ein beliebiges Band in Ihrem Laufwerk beschreiben soll, wird Ihnen der Umgang
mit Bacula kompliziert vorkommen. Bacula ist so entworfen, dass es Ihre
Daten nach von Ihnen festgelegten Regeln sichert, was bedeutet, dass die
Wiederverwendung eines Bandes nur die letzte Wahl sein kann.
Nat\"{u}rlich ist es m\"{o}glich, Bacula dazu zu bringen, jedes beliebige Band
im Laufwerk zu beschreiben, jedoch ist es einfacher und wirkungsvoller
hierf\"{u}r ein anderes Programm zu verwenden.
Wenn Sie Amanda verwenden und ein Sicherungsprogramm suchen, das
einzelne Backup-Jobs auf mehrere Volumes schreiben kann
(also die Job-Gr\"{o}{\ss}e nicht durch die Speicherkapazit\"{a}t Ihres Bandlaufwerkes beschr\"{a}nkt ist)
wird Bacula wahrscheinlich Ihren Bed\"{u}rfnissen entsprechen.
Viele unserer Benutzer finden au{\ss}erdem, dass Bacula
einfacher zu konfigurieren und zu benutzen ist als entsprechende andere Programme.

Wenn Sie gegenw\"{a}rtig ein anspruchsvolles kommerzielles Programm wie Legato
Networker, ARCserveIT, Arkeia oder PerfectBackup+ verwenden,
k\"{o}nnte Sie Bacula interessieren, da es viele Eigenschaften und Funktionen dieser Programme hat,
dabei aber als freie Software unter der GNU Software Lizenz Version 2 verf\"{u}gbar ist. 


\section{Bacula Komponenten oder Dienste}
\index[general]{Bacula Komponenten oder Dienste }
\index[general]{Dienste!Bacula Komponenten oder }

Bacula besteht aus den folgenden f\"{u}nf Hauptkomponenten bzw. Diensten: 

\addcontentsline{lof}{figure}{Bacula Applications}
\includegraphics{\idir bacula-applications.eps} 
(Dank an Aristedes Maniatis f\"{u}r diese und die folgende Grafik) 

\subsection*{Bacula Director}
   \label{DirDef}
   Der Bacula Director-Dienst ist das Programm, das alle Sicherungs-, Wiederherstellungs-, Verifizierungs- und
Archivierungsvorg\"{a}nge \"{u}berwacht und steuert.
Der Systemadministrator verwendet den Bacula Director, um die Zeitpunkte
der Sicherungen festzulegen und Dateien wiederherzustellen.
N\"{a}heres hierzu im Dokument ``Director Services Daemon Design'' im ``Bacula Developer's Guide''.
Der Director l\"{a}uft als D\"{a}mon bzw. Dienst (also im Hintergrund). 

\subsection*{Bacula Console}
   \label{UADef}
   Der Bacula Console-Dienst ist jenes Programm, welches es einem
Systemadministrator oder Benutzer erlaubt, mit dem Bacula Director zu
kommunizieren. Zur Zeit ist die Bacula Console in drei Versionen
verf\"{u}gbar. Die erste und einfachste, ist das Consolen Programm in einer
Shell zu starten (also eine TTY-Schnittstelle). Die meisten
Systemadministratoren werden das v\"{o}llig angemessen finden.
Die zweite M\"{o}glichkeit ist ein grafisches GNOME-Interface, das weit davon entfernt
ist, vollst\"{a}ndig zu sein, aber schon ganz gut funktioniert und die meisten
M\"{o}glichkeiten bietet, die auch die Shell-Konsole hat. Die dritte
Version ist eine grafische wxWidgets-Benutzeroberfl\"{a}che, \"{u}ber die Daten
interaktiv wiederhergestellt werden k\"{o}nnen. Auch sie hat die meisten Funktionen
der Shell-Konsole, bietet eine Befehlsvervollst\"{a}ndigung per Tabulatorentaste
und  Kontexthilfe w\"{a}hrend der Befehlseingabe. 
N\"{a}heres hierzu im Kapitel \ilink{Bacula Console Design Document}{_ChapterStart23}. 

\subsection*{Bacula File}
\label{FDDef}
   Bacula File (Datei)-Dienste (bzw. Client-Programme) sind jene
Programme, die auf den Rechnern installiert sind, deren Daten gesichert
werden sollen. Sie sind je nach Betriebssystem verschieden, immer aber
verantwortlich f\"{u}r die Auslieferung der Daten und deren Attribute, die der
Director von ihnen anfordert. Die Datendienste sind auch f\"{u}r den
betriebssystemabh\"{a}ngigen Teil der Wiederherstellung der Daten und deren
Attribute zust\"{a}ndig. N\"{a}heres hierzu im Dokument ``File Services Daemon Design'' im ``Bacula Developer's
Guide''. Auf den Rechnern, derren Daten gesichert werden sollen, l\"{a}uft dieses
Programm als D\"{a}monprozess. Der File-D\"{a}mon wird in dieser Dokumentation auch als
``Client'' bezeichnet (zum Beispiel in den Konfigurationsdatei von Bacula).
Ausser den Unix/Linux File-D\"{a}monen gibt es einen File-D\"{a}mon f\"{u}r Windows
(der in der Regel als kompiliertes Programm erh\"{a}ltlich ist). Der File-D\"{a}mon f\"{u}r Windows l\"{a}uft
unter allen g\"{a}ngigen Windows-Versionen (95, 98, Me, NT, 2000, XP). 

\subsection*{Bacula Storage}
\label{SDDef}
   Den Bacula Storage (Sicherungs)-Dienst leisten Programme, die
Sicherung und Wiederherstellung der Dateien und ihrer Attribute auf das
physikalische Sicherungsmedium bzw. die Volumes leisten. Der Storage-D\"{a}mon ist also f\"{u}r das
Beschreiben und Lesen Ihrer B\"{a}nder (oder eines anderen Sicherungsmediums wie
z.B. Dateien) zust\"{a}ndig. N\"{a}heres hierzu im Kapitel ``Storage Services Daemon
Design'' im ``Bacula Developer's Guide''. Der Sicherungsdienst l\"{a}uft als
D\"{a}monprozess auf dem Rechner, der \"{u}ber das Datensicherungsger\"{a}t verf\"{u}gt (in der
Regel ein Bandlaufwerk). 

\subsection*{Catalog}
\label{DBDefinition}
   Die Catalog (Verzeichnis)-Dienste werden von Programmen
geleistet, die f\"{u}r die Wartung der Datieindizes und Volume-Datenbanken
aller gesicherten Dateien zust\"{a}ndig sind. \"{U}ber einen Verzeichnis-Dienst kann der
Systemadministrator oder Benutzer jede gew\"{u}nschte Datei schnell finden
und wiederherstellen. Durch den Verzeichnisdienst unterscheidet sich Bacula von
einfachen Sicherungsprogrammen wie ``tar'' oder ``bru'', da dieser
Dienst die Aufzeichnung aller verwendeten Volumes, aller gelaufener
Sicherungen und aller gesicherter Dateien pflegt und dadurch eine
effiziente Wiederherstellung und eine Verwaltung der Volumes erlaubt. Bacula
unterst\"{u}tzt momentan die drei Datenbanksysteme MySQL, PostgreSQL
und SQLite, von denen eines vor der Kompilierung von {\bf Bacula} ausgew\"{a}hlt sein
muss. 

Die drei Datenbanksysteme (MySQL, PostgreSQL und SQLite), die z.Z. unterst\"{u}tzt
werden, haben eine ganze Reihe von Besonderheiten wie z.B. schnelle Indizierung,
Baumsuche und Sicherheitsfunktionen. Wir planen die Unterst\"{u}tzung weiterer
gr\"{o}{\ss}erer SQL-Datenbanksysteme, doch hat die momentane Bacula-Version nur
Schnittstellen zu MySQL, PostgreSQL und SQLite. N\"{a}heres hierzu im Kapitel
\ilink{``Catalog Services Design Document''}{_ChapterStart30}.  

MySQL und PostgreSQL sind f\"{u}r viele Betriebssysteme verf\"{u}gbar.
Alternativ, k\"{o}nnen sie auch aus den Quelldateien installiert werden.
N\"{a}heres hierzu im Kapitel \ilink{``Installation und Konfiguration
von MySQL''}{_ChapterStart} in diesem Handbuch. Weitere Informationen zu MySQL
im Internet: \elink{www.mysql.com}{http://www.mysql.com}.
Zu PostgreSQL lesen Sie bitte das Kapitel \ilink{``Installation und
Konfiguration von PostgreSQL''}{_ChapterStart10} in diesem Dokument.
Weiter Informationen zu PostgreSQL finden Sie hier:
\elink{www.postgresql.org}{http://www.postgresql.org}.  

Die Konfiguration und Installation eines SQLite-Datenbanksystems ist noch
einfacher. Einzelheiten dazu im Kapitel \ilink{``Installation und Konfiguration
von SQLite''}{_ChapterStart33} in diesem Handbuch.

\subsection*{Bacula Monitor}
\label{MonDef}
   Der Bacula Monitor-Dienst ist das Programm, welches es dem
Administrator oder Benutzer erlaubt, den aktuellen Zustand des Bacula
Directors, der Bacula File D\"{a}monen und der Bacula Storage D\"{a}monen
zu beobachten. Zur Zeit ist hierf\"{u}r nur eine GTK+-Version
verf\"{u}gbar, die auf Gnome und KDE aufsetzt (oder jedem anderen Fenstermanager,
der den Standard von FreeDesktop.org f\"{u}r das System-Tray unterst\"{u}tzt). 

Um erfolgreich sichern und wiederherstellen zu k\"{o}nnen, m\"{u}ssen die folgenden
vier D\"{a}monprozesse konfiguriert und gestartet sein: Der Director-Dienst, der
File-Dienst, der Storage-Dienst und die Katalog-Datenbank (MySQL, PostgreSQL oder SQLite).

\section{Die Bacula Konfiguration}
\index[general]{Konfiguration!Die Bacula }
\index[general]{Die Bacula Konfiguration }

Damit sich Bacula in Ihrem System zurechtfindet und es weiss welche
Client-Rechner wie zu sichern sind, m\"{u}ssen mehrere Konfigurationsdateien
erstellt werden, die bestimmte Eintr\"{a}ge (bzw. Ressourcen) enthalten. Die
folgende Abbildung gibt hierzu eine \"{U}bersicht:

\addcontentsline{lof}{figure}{Bacula Objects}
\includegraphics{\idir bacula-objects.eps} 

\section{Die in diesem Dokument verwendeten Konventionen}
\index[general]{Die in diesem Dokument verwendeten Konventionen }
\index[general]{Dokument!verwendete Konventionen}

{\bf Bacula} ist in der Entwicklung und daher wird dieses Handbuch nicht in
jedem Fall mit dem Stand des Programmcodes \"{u}bereinstimmen. Steht in diesem
Handbuch vor einem Abschnitt ein Stern (*), bedeutet dies, dass das Beschriebene
noch nicht implementiert ist. Die Kennzeichnung durch ein Pluszeichen (+)
bedeutet, dass die Funktion m\"{o}glicherweise teilweise implementiert ist.

Wenn Sie dieses Handbuch als Teil eines offiziellen Release der
Software lesen, ist diese Kennzeichnung verl\"{a}{\ss}lich. Lesen Sie hingegen die
Online-Version dieses Handbuches auf \elink{ www.bacula.org}{http://www.bacula.org}, denken Sie
bitte daran, dass hier die aktuelle Entwicklungsversion (wie sie im SVN
vorhanden ist) beschrieben wird. In beiden F\"{a}llen wird aber das Handbuch dem
Code ein St\"{u}ckchen hinterherhinken. 

\section{Quick Start}
\index[general]{Quick Start }
\index[general]{Start!Quick }

Um Bacula schnell zu konfigurieren und zum Laufen zu bringen, empfehlen wir,
zuerst den untenstehenden Abschnitt mit den Fachausdr\"{u}cken und das n\"{a}chste
Kapitel \ilink{``Baculas gegenw\"{a}rtiger Zustand''}{_ChapterStart2} durchzusehen.

Lesen Sie dann das Kapitel \ilink{``Mit Bacula beginnen''}{_ChapterStart37}, das
eine kurze \"{U}bersicht dar\"{u}ber gibt, wie man Bacula startet. Lesen 
Sie danach das Kapitel \"{u}ber \ilink{``Die Installation von
Bacula''}{_ChapterStart17}, dann \ilink{``Die Konfiguration
von Bacula''}{_ChapterStart16} und schlie{\ss}lich das Kapitel \ilink{
``Bacula in Betrieb nehmen''}{_ChapterStart1}. 

\section{Terminologie}
\index[general]{Terminologie }

Um die Kommunikation \"{u}ber diese Projekt zu erleichtern, sind hier die
verwendeten Begriffe erl\"{a}utert 

\begin{description}

\item [Administrator]
   \index[fd]{Administrator }
   Die Person bzw. die Personen, die f\"{u}r die Pflege des Bacula-Systems
verantwortlich sind.

\item [Backup]
   \index[fd]{Backup }
   Wir verwenden den Ausdruck {\bf Backup} (Sicherung) wenn wir von einem
Bacula-Job sprechen, bei dem Dateien gesichert werden.

\item [Bootstrap File]
   \index[fd]{Bootstrap File }
   Das bootstrap file (Bootstrap-Datei) ist eine ASCII-Datei, die in kompakter
Form jene Befehle enth\"{a}lt, mit denen Bacula oder das eigenst\"{a}ndige
Dateiextrahierungswerkzeug bextract den Inhalt eines oder mehrerer
Volumes wiederherstellen kann, wie z.B. einen vorher gesicherten Systemzustand.
Mit einer Bootstrap-Datei kann Bacula Ihr System wiederherstellen, ohne auf
eine Catalog-Datenbank angewiesen zu sein. Aus einem Catalog kann eine Bootstrap-Datei
erzeugt werden, um jede gew\"{u}nschte Datei auf den Volumes wiederzufinden. 

\item [Catalog]
   \index[fd]{Catalog }
   Der Catalog (das Verzeichnis) wird verwendet, um zusammenfassende
Informationen \"{u}ber Jobs, Clients und die gesicherten Dateien zu speichern,
sowie Informationen dar\"{u}ber, auf welchen Volumes diese Daten sind. Die
Informationen, die in der Catalog-Datenbank gespeichert sind, erm\"{o}glichen es dem Administrator
bzw. Benutzer zu bestimmen, welche Jobs gelaufen sind, geben Auskunft \"{u}ber ihren
Status und wichtige Eigenschaften der gesicherten Dateien. Der Catalog ist eine
``online resource'', enth\"{a}lt aber nicht die Daten der gesicherten Dateien. Vieles
der Catalog-Informationen ist auch auf den Volumes (z.B. den B\"{a}ndern)
gespeichert. Nat\"{u}rlich sind auf den B\"{a}ndern auch die Kopien der Dateien und
deren Attribute (siehe unten).  

Die Catalog-Datenbank ist eine Besonderheit von Bacula, das es von einfachen Backup- und
Archiv-Programmen wie {\bf dump} und {\bf tar} unterscheidet.  

\item [Client]
   \index[fd]{Client }
   In Baculas Terminologie bezeichnet das Wort Client jenen Rechner,
dessen Daten gesichert werden. Client ist auch ein anderes Wort f\"{u}r
den File-Dienst oder File-D\"{a}mon, der oft auch nur mit FD bezeichnet wird.
Clients werden durch einen Eintrag in den Konfigurationsdatein definiert.

\item [Console]
   \index[fd]{Console }
   Die Console (Konsole) ist ein Programm, das die Schnittstelle zum Director
bildet und \"{u}ber welches der Benutzer oder Systemadministrator Bacula
steuern kann.

\item [Daemon]
   \index[fd]{Daemon }
   D\"{a}monprozess ist ein Unix-Fachausdruck f\"{u}r ein Programm, dass
st\"{a}ndig im Hintergrund l\"{a}uft um spezielle Aufgaben
auszuf\"{u}hren. Auf Windows- und manchen Linux-Systemen werden 
D\"{a}monprozesse Services (Dienste) genannt. 

\item [Directive]
   \index[fd]{Directive }
   Der Ausdruck directive (Anweisung) bezeichnet eine einzelne Angabe
innerhalb eines Konfigurations-Eintrags einer Konfigurationsdatei, welche
einen speziellen Sachverhalt definiert. Beispielsweise definiert die {\bf
Name}-directive den Namen einer Resource. 

\item [Director]
   \index[fd]{Director }
   Baculas wichtigster D\"{a}monprozess, der alle Aktivit\"{a}ten des Bacula-Systems
zeitlich festlegt und beaufsichtigt. Gelegentlich auch als DIR bezeichnet.

\item [Differential]
   \index[fd]{Differential }
   Differentiell ist eine Sicherung, wenn sie alle Dateien einbezieht, die
seit Beginn der letzten Vollsicherung ge\"{a}ndert wurden. Beachten Sie bitte, dass
dies von anderen Sicherungsprogrammen m\"{o}glicherweise anders definiert wird.

\item [File Attributes]
   \index[fd]{File Attributes }
   File Attributes (Dateiattribute) sind all diejenigen Informationen, die
n\"{o}tig sind, um eine Datei und alle ihre Eigenschaften zu identifizieren.
Dazu geh\"{o}ren alle ihre Gr\"{o}{\ss}e, Zeitpunkt der Erzeugung, Zeitpunkt der letzten
\"{A}nderung, Berechtigungen, usw.
Im Normalfall wird der Umgang mit den Attributen vollst\"{a}ndig von Bacula
\"{u}bernommen, so dass sich der Benutzer dar\"{u}ber keine Gedanken machen muss.
Zu den Attributen geh\"{o}rt nicht der Inhalt der Datei. 

\item [File Daemon]
   \index[fd]{File Daemon }
   Derjenige D\"{a}monprozess, welcher auf dem Client-Computer l\"{a}uft, dessen Daten
gesichert werden sollen. Wird manchmal auch als File-Service (Datendienst),
Client-Service (Client-Dienst) oder als FD bezeichnet.

\label{FileSetDef}
\item [FileSet]
\index[fd]{FileSet }
Ein FileSet (Zusammenstellung von Dateien) ist eine Eintrag einer
Konfigurationsdatei, der festlegt, welche Dateien gesichert werden sollen.
Es besteht aus einer Liste mit zu sichernden Dateien oder Verzeichnissen,
eventuell einer Liste mit Dateien die nicht mitgesichert werden sollen und Informationen
dar\"{u}ber, wie diese Dateien zu sichern sind (komprimiert, verschl\"{u}sselt,
signiert). N\"{a}heres hierzu im Abschnitt \ilink{``Definition der FileSet
Resource''}{FileSetResource} im Director-Kapitel dieses Dokuments. 

\item [Incremental]
   \index[fd]{Incremental }
   Inkrementell ist eine Sicherung dann, wenn sie alle Dateien einbezieht, die
seit Beginn der letzten vollen, differentiellen oder inkrementellen Sicherung
ge\"{a}ndert wurden. Normalerweise wird dies entweder durch die
Level-Direktive innerhalb der Definition einer Job Ressource oder in
einem Schedule-Eintrag festgelegt. 

\label{JobDef}
\item [Job]
\index[fd]{Job }
Ein Bacula Job ist ein Konfigurations-Eintrag, der die Art und
Weise definiert, in der Bacula die Daten eines bestimmten Client-Rechners
sichert oder wiederherstellt. Sie besteht aus den Definitionen des {\bf Type}
(Sicherung, Wiederherstellung, \"{U}berpr\"{u}fung, usw.), des {\bf Level} (voll,
inkrementell,...), des {\bf FileSet} und des Speicherorts ({\bf Storage}) an
welchem die Dateien gesichert werden sollen (Speicherger\"{a}t, Media-Pool). N\"{a}heres
hierzu im Abschnitt \ilink{``Definition der Job-Resource''
}{JobResource} im \textbf{Director}-Kapitel dieses Dokuments. 

\item [Monitor]
   \index[fd]{Monitor }
   Dieses Programm hat eine Schnittstelle zu allen D\"{a}monprozessen, um dem
Benutzer oder Systemadministrator die Beobachtung von Baculas Zustand zu
erm\"{o}glichen.

\item [Resource]
   \index[fd]{Resource }
   Eine Resource ist ein Teil einer Konfigurationsdatei, die eine
bestimmte Informationseinheit definiert. Eine
Ressource enth\"{a}lt mehrere Direktiven (einzelne Konfigurations-Anweisungen).
Die Job-Resource beispielsweise definiert
alle Eigenschaften eines bestimmten Jobs: Name, Zeitplan, Volume-Pool, Art der
Sicherung, Level der Sicherung...

\item [Restore]
   \index[fd]{Restore }
   ist eine Ressource innerhalb einer Konfigurationsdatei, die den
Vorgang der Wiederherstellung einer verlorenen oder besch\"{a}digten Datei von
einem Sicherungsmedium beschreibt. Es ist der umgekehrte Vorgang wie bei
einer Sicherung, au{\ss}er dass in den meisten F\"{a}llen bei einem Restore nur
einige wenige Dateien wiederhergestellt werden, w\"{a}hrend bei einer Sicherung
normalerweise alle Dateien eines Systems gesichert werden. Selbstverst\"{a}ndlich
kann Bacula, z.B. nach dem Ausfall einer Festplatte, dazu benutzt werden, ein
vollst\"{a}ndiges Restore aller im System vorhandenen Dateien auszuf\"{u}hren.

\item [Schedule]
   \index[fd]{Schedule }
   Die Schedule (Zeitplan) ist eine Resource innerhalb einer
Konfigurationsdatei, die definiert, wann ein Bacula-Job ausgef\"{u}hrt
wird. Hierzu benutzt die Job-Resource den Namen der Schedule.
N\"{a}heres hierzu im Abschnitt \ilink{``Definition
der Schedule-Resource''}{ScheduleResource} im
``Director''-Kapitel diese Handbuches.

\item [Service]
   \index[fd]{Service }
   Dienst ist die Bezeichnung f\"{u}r einen {\bf Daemon}(D\"{a}monprozess) unter
Windows. Diese Bezeichnung wird in letzter Zeit auch h\"{a}ufig in
Unix-Umgebungen benutzt. Als Dienst werden Programme bezeichnet,
die im st\"{a}ndig Hintergrund laufen.

\item [Storage Coordinates]
   \index[fd]{Storage Coordinates }
   Diejenige Information, die der Storage-Dienst zur\"{u}ckgibt und die eine
Datei eindeutig auf dem Sicherungsmedium kennzeichnen.
Sie besteht aus einem Teil der zu jeder gespeicherten Datei
und einem Teil, der zum ganzen Job geh\"{o}rt.
Normalerweise wird diese Information im Catalog gespeichert, so dass der
Benutzer keine besonderen Kenntnisse der Storage Coordinates braucht.
Zu den Storage Coordinates geh\"{o}ren die Dateiattribute und der eindeutige
Ort der Sicherung auf dem Sicherungs-Volume. 

\item [Storage Daemon]
   \index[fd]{Storage Daemon }
   Der Storage Daemon (Speicher-D\"{a}mon), manchmal auch mit SD bezeichnet,
ist jenes Programm, das die Attribute und die Daten auf ein Sicherungs-Volume
schreibt (normalerweise ein Band oder eine Festplatte).

\item [Session]
   \index[sd]{Session }
Die Session (Sitzung) bezeichnet in der Regel die interne Kommunikation
zwischen dem File-D\"{a}mon und dem Storage-D\"{a}mon. Der File-D\"{a}mon er\"{o}ffnet
eine Session mit dem Storage-D\"{a}mon, um ein FileSet zu sichern
oder wiederherzustellen. Jede Session entspricht einem Bacula-Job (siehe  oben). 

\item [Verify]
   \index[sd]{Verify }
   Ein Verify ist ein Job, bei dem die aktuellen Dateiattribute mit
jenen verglichen werden, die zuvor im Catalog
hinterlegt worden sind. Diese Funktion kann verwendet werden, um \"{A}nderungen an
wichtigen Systemdateien zu erkennen und ist damit Tripwire \"{a}hnlich. Einer
der haupts\"{a}chlichen Vorteile dieser Funktionalit\"{a}t ist es, dass es gen\"{u}gt,
auf dem Rechner, den man sch\"{u}tzen will, den File-D\"{a}mon laufen zu haben.
Director, Storage-D\"{a}mon und der Catalog sind auf
einem anderen Rechner installiert. Wenn der Server dann gef\"{a}hrdet wird, ist es
\"{a}u{\ss}erst unwahrscheinlich, dass die Datenbank mit den Verifikationen davon
mitbetroffen ist.

Verify kann auch zur \"{U}berpr\"{u}fung benutzt werden, ob die Daten des
zuletzt gelaufenen Jobs mit denen \"{u}bereinstimmen, die im Catalog
gespeichert wurden (es werden also die Dateiattribute verglichen).
Verify kann aber auch den Inhalt eines Volumes mit den Originaldateien
auf der Festplatte vergleichen. 

\item [*Archive]
   \index[fd]{*Archive }
   Eine Archive-Funktion wird nach einer Sicherung durchgef\"{u}hrt. Dabei 
werden die Volumes, auf denen die Daten gesichert sind, der aktiven
Benutzung entzogen, als ``Archived'' gekennzeichnet und f\"{u}r weitere
Sicherungen nicht mehr verwendet. Alle Datei- und Job-Eintr\"{a}ge des archivierten
Volumes werden aus dem Catalog entfernt.
NOCH NICHT IMPLEMENTIERT.

\item [Retention Period]
   \index[fd]{Retention Period }
   Bacula kennt verschiedene Arten von Retention Periods
(Aufbewahrungszeitr\"{a}ume). Das sind die File Retention Period,
die Job Retention Period und die Volume Retention Period.
Jede diese Retention-Periods bezieht sich auf die
Zeit, w\"{a}hrend der bestimmte Aufzeichnungen in der Catalog-Datenbank
gehalten werden. Dies sollte nicht mit jener Zeit verwechselt werden w\"{a}hrend
der Daten eines Volume g\"{u}ltig sind. 

Die File Retention Period bestimmt wie lange die Eintr\"{a}ge zu den
Dateien in der Catalog-Datenbank gehalten werden. Diese Zeitspanne ist
wichtig, da diese Eintr\"{a}ge bei weitem den gr\"{o}{\ss}ten Teil des Speicherplatzes in
der Datenbank belegen. Daher muss gew\"{a}hrleistet sein, dass \"{u}berfl\"{u}ssige oder
veraltete Eintr\"{a}ge regelm\"{a}{\ss}ig aus der Datenbank entfernt werden
(hierzu N\"{a}heres im Abschnitt zum {\bf prune}-Befehl in der Beschreibung der Console-Befehle).

Die Job Retention Period ist die Zeitspanne, w\"{a}hrend der Eintr\"{a}ge zu
den Jobs in der Datenbank gehalten werden. Beachten Sie, dass alle Dateieintr\"{a}ge
mit dem Job, mit dem sie gesichert wurden, verbunden sind. Die Eintr\"{a}ge zu den
Dateien k\"{o}nnen gel\"{o}scht sein, w\"{a}hrend die Aufzeichnungen zu den Jobs erhalten
bleiben. In diesem Fall wird man Informationen \"{u}ber gelaufene Sicherungsjobs
haben, jedoch keine Einzelheiten \"{u}ber die Dateien, die dabei gesichert
wurden. Normalerweise werden mit dem L\"{o}schen eines
Job-Eintrags auch alle seine Aufzeichnungen zu den Dateien gel\"{o}scht.

Die Volume Retention Period bestimmt die Mindestzeit, die
ein bestimmtes Volume aufbewart wird, bevor Bacula es wiederverwendet.
Bacula wird in der Regel niemals ein Volume \"{u}berschreiben, dass als
einziges die Sicherungskopie einer bestimmten Datei enth\"{a}lt. Im Idealfall wird
der Catalog f\"{u}r alle benutzten Volumes die Eintr\"{a}ge aller
gesicherten Daeien enthalten. Wenn ein Volume \"{u}berschrieben wird,
werden die Dateieeintr\"{a}ge, die zuvor auf ihm gespeichert waren aus dem
Catalog entfernt. Gibt es allerdings einen sehr gro{\ss}en Pool von
Volumes oder gibt es Volumes, die nie \"{u}berschrieben werden,
kann die Catalog-Datenbank sehr gro{\ss} werden. Um den Catalog in
einer handhabbaren Gr\"{o}{\ss}e zu halten, sollten Informationen zu den Sicherungen
nach der definierten File Retention Period aus ihm entfernt werden.
Bacula hat Mechanismen, um den Catalog entsprechend der
definierten Retention Periods automatisch zu bereinigen.

\item [Scan]
   \index[sd]{Scan }
   Bei einer Scan-Operation wird der Inhalt eines oder mehrerer
Volumes durchsucht. Diese Volumes und die Informationen \"{u}ber
die Dateien, welche sie enthalten, werden wieder in den Bacula-Catalog
eingetragen. Danach k\"{o}nnen die Dateien von diesen Volumes auf
normale Weise wiederhergestellt werden. Diese Funktion ist teilweise
hilfreich, wenn bestimmte Volumes oder Jobs ihre Retention Period
\"{u}berschritten haben und aus dem Catalog entfernt worden sind. Um die
Daten von den Volumes in die Datenbank einzulesen, wird das Programm
bscan verwendet. N\"{a}heres hierzu im Abschnitt \ilink{bscan}{bscan}
im Kapitel ``Bacula Hilfsprogramme'' dieses Handbuches.

\item [Volume]
   \index[sd]{Volume }
   Ein Volume ist eine Einheit, auf der gesichert wird, normalerweise
ein Band oder eine benannte Datei auf der Festplatte auf denen Bacula die
Daten einer oder mehrerer Sicherungsjobs speichert. Alle Volumes
erhalten von Bacula eine digitale Kennzeichnung, das Label, so dass Bacula jederzeit wei{\ss},
welches Volume es tats\"{a}chlich liest. (Normalerweise sollte es mit
Dateien auf der Festplatte keine Verwechslungen geben, doch bei B\"{a}ndern mountet
man aus Versehen leicht das Falsche).
\end{description}

\section{Was Bacula nicht ist}
\index[general]{Was Bacula nicht ist }
\index[general]{nicht ist!Was Bacula }

Bacula ist ein Sicherungs-, Wiederherstellungs- und Verifikationsprogramm,
aber von sich aus noch kein komplettes Rettungsprogramm f\"{u}r den
Katastrophenfall. Allerdings kann Bacula Teil eines Rettungsprogramms sein,
falls Sie sorgf\"{a}ltig planen und die Anweisungen im Kapitel
\ilink{Disaster Recovery}{_ChapterStart38} dieses Handbuches beachten.

Bei sorgf\"{a}ltiger Planung, wie sie im Kapitel ``Disaster Recovery'' dargestellt
ist, kann {\bf Bacula} ein wesentlicher Bestandteil eines
Rettungssystems sein. Wenn Sie zum Beispiel eine Bootdiskette
erstellt haben, dazu eine Bacula-Rettungs-CD, auf der sie die aktuellen
Partitionsdaten Ihrer Festplatte gespeichert haben und eine komplette Bacula
Sicherung vorhalten, ist es m\"{o}glich, Ihr System auf einer leeren Festplatte
wieder herzustellen.

Wenn Sie die den Eintrag {\bf WriteBootstrap} in einem Ihrer Sicherungs-Jobs
verwendet oder auf irgend eine andere Art eine g\"{u}ltige Bootstrap-Datei
gesichert haben, werden Sie damit in der Lage sein, die notwendigen Dateien
wiederherzustellen (auch ohne den Catalog zu verwenden oder von Hand nach Dateien
suchen zu m\"{u}ssen). 


\section{Interaktionen zwischen den Bacula-Diensten}
\index[general]{Interaktionen zwischen den Bacula-Diensten }
\index[general]{Diensten!Interaktionen zwischen den Bacula- }

Das untenstehende Diagramm zeigt typische Interaktionen zwischen den einzelnen
Bacula-Diensten bei einem Sicherungs-Job. Jeder Block steht ungef\"{a}hr f\"{u}r einen
eigenen Prozess (normalerweise ein D\"{a}mon). Im gro{\ss}en und ganzen hat der
Director den \"{U}berblick \"{u}ber die Aktionen und pflegt die
Katalog-Datenbank.

\addcontentsline{lof}{figure}{Interaktionen zwischen den Bacula-Diensten}
\includegraphics{\idir flow.eps} 
