4 \chapter{Was ist Bacula?}
6 \index[general]{Bacula!Was ist }
7 \index[general]{Was ist Bacula? }
10 {\bf Bacula} ist ein System von Computerprogrammen, mit denen Sie
11 (oder der System-Administrator) in der Lage sind, Computerdaten innerhalb eines
12 heterogenen Netzwerkes zu sichern, die Sicherungen wiederherzustellen und diese zu \"{u}berpr\"{u}fen. Bacula kann auch auf einem einzigen Computer laufen und auf verschiedene Arten von Medien wie B\"{a}nder oder CDs sichern.
13 Technisch gesprochen ist es ein netzwerkf\"{a}higes
14 Sicherungsprogramm mit Client/Server-Architektur.
15 Bacula ist leistungsf\"{a}hig und vergleichsweise einfach zu benutzen.
16 Dabei hat es viele anspruchsvolle Funktionen zur Verwaltung der Sicherung,
17 die das Auffinden und die Wiederherstellung besch\"{a}digter oder verlorener
18 Dateien erleichtern. Durch seinen modularen Aufbau l\"{a}sst es sich jedem System
19 anpassen: Vom Einzelplatzrechner bis zu einem gro{\ss}en System mit hunderten von
20 Computern, die \"{u}ber ein weitr\"{a}umiges Netzwerk verteilt sind.
21 \section{Wer ben\"{o}tigt Bacula?}
22 \index[general]{Wer ben\"{o}tigt Bacula? }
23 \index[general]{Bacula!Wer ben\"{o}tigt }
26 Wenn Sie momentan Programme wie {\bf tar}, {\bf dump}, oder {\bf
27 bru} zur Datensicherung verwenden und eine Netzwerkl\"{o}sung, gr\"{o}{\ss}ere Flexibilit\"{a}t
28 oder einen Verzeichnis-Dienst suchen, wird Bacula wahrscheinlich die
29 zus\"{a}tzlichen Funktionen zur Verf\"{u}gung stellen, die Sie suchen. Wenn Sie dagegen
30 ein UNIX-Neuling sind oder keine weitergehenden Erfahrung mit
31 anspruchsvollen Sicherungsprogrammen haben, raten wir von Bacula ab, da es in
32 der Einrichtung und der Benutzung sehr viel komplizierter ist als z.B.
33 {\bf tar} oder {\bf dump}.
35 Wenn Bacula wie die oben beschriebenen einfachen Programme funktionieren und
36 nur ein Band in Ihrem Laufwerk beschreiben soll, wird Ihnen der Umgang
37 mit Bacula kompliziert vorkommen. Bacula ist so entworfen, dass es Ihre
38 Daten nach von Ihnen festgelegten Regeln sichert, was bedeutet, dass die
39 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
41 Wenn Sie {\bf Amanda} verwenden und ein Sicherungsprogramm suchen, das auf
42 mehrere Volumes schreiben kann (also nicht durch die Speicherkapazit\"{a}t Ihres
43 Bandlaufwerkes beschr\"{a}nkt ist) wird Bacula wahrscheinlich Ihren Bed\"{u}rfnissen
44 entsprechen. Viele unserer Benutzer finden au{\ss}erdem, dass Bacula
45 einfacher zu konfigurieren und zu benutzen ist als entsprechende andere Programme.
47 Wenn Sie gegenw\"{a}rtig ein anspruchsvolles kommerzielles Programm wie ``Legato'',
48 ``Networker'', ``ARCserveIT'', ``Arkeia'', oder ``PerfectBackup+'' verwenden,
49 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
53 \section{Bacula Komponenten oder Dienste}
54 \index[general]{Bacula Komponenten oder Dienste }
55 \index[general]{Dienste!Bacula Komponenten oder }
58 Bacula besteht aus den folgenden f\"{u}nf Hauptkomponenten bzw. Diensten:
60 \addcontentsline{lof}{figure}{Bacula Applications}
61 \includegraphics{./bacula-applications.eps}
62 (Dank an Aristedes Maniatis f\"{u}r diese und die folgende Grafik)
64 \subsection*{Bacula Director}
66 Der {\bf Bacula Director}-Dienst ist das Programm, das alle Sicherungs-, Wiederherstellungs-, Verifizierungs- und
67 Archivierungsvorg\"{a}nge \"{u}berwacht. Der Systemadministrator verwendet den Bacula Director, um die Zeitpunkte der
68 Sicherungen festzulegen und Dateien wiederherzustellen. N\"{a}heres hierzu im Dokument ``Director Services Daemon
70 im ``Bacula Developer's Guide''.
71 Der Director l\"{a}uft als D\"{a}mon bzw. Dienst (also im Hintergrund).
73 \subsection*{Bacula Console}
75 Der {\bf Bacula Console}-Dienst ist jenes Programm, welches es einem
76 Systemadministrator oder Benutzer erlaubt, mit dem {\bf Bacula Director} zu
77 kommunizieren (siehe oben). Zur Zeit ist die Bacula Console in drei Versionen75%
78 verf\"{u}gbar. Die erste und einfachste ist das Consolen Programm in einer
79 Shell zu starten (also eine TTY-Schnittstelle). F\"{u}r die meisten
80 Systemadministratoren ist dies v\"{o}llig angemessen. Die zweite M\"{o}glichkeit ist ein
81 grafisches GNOME-Interface, das weit davon entfernt
82 ist, vollst\"{a}ndig zu sein, aber schon ganz gut funktioniert und die meisten
83 M\"{o}glichkeiten bietet, die auch die Shell-Konsole hat. Die dritte
84 Version ist eine grafische wxWidgets-Benutzeroberfl\"{a}che, \"{u}ber die Daten
85 interaktiv wiederhergestellt werden k\"{o}nnen. Auch sie hat die meisten Funktionen
86 der Shell-Konsole, bietet eine Befehlsvervollst\"{a}ndigung per Tabulatorentaste
87 und Kontexthilfe w\"{a}hrend der Befehlseingabe.
88 N\"{a}heres hierzu im Kapitel \ilink{Bacula Console
89 Design Document}{_ChapterStart23}.
90 \subsection*{Bacula File}
92 {\bf Bacula File} (Datei)-Dienste (bzw. Client-Programme) sind jene
93 Programme, die auf den Rechnern installiert sind, deren Daten gesichert
94 werden sollen. Sie sind je nach Betriebssystem verschieden, immer aber
95 verantwortlich f\"{u}r die Auslieferung der Daten und deren Attribute, die der
96 Director von ihnen anfordert. Die Datendienste sind auch f\"{u}r den
97 betriebssystemabh\"{a}ngigen Teil der Wiederherstellung der Daten und deren
98 Attribute im Falle einer Wiederherstellung zust\"{a}ndig. N\"{a}heres
99 hierzu im Dokument ``File Services Daemon Design'' im ``Bacula Developer's
100 Guide''. Auf dem Rechner, dessen Daten gesichert werden sollen, l\"{a}uft dieses
101 Programm als D\"{a}monprozess. Der File-D\"{a}mon wird in dieser Dokumentation auch als
102 ``Client'' bezeichnet (zum Beispiel in den Konfigurationsdatei von Bacula).
103 Ausser den Unix/Linux File-D\"{a}monen gibt es einen File-D\"{a}mon f\"{u}r Windows
104 (der in der Regel als kompiliertes Programm erh\"{a}ltlich ist). Der File-D\"{a}mon f\"{u}r Windows l\"{a}uft
105 unter allen g\"{a}ngigen Windows-Versionen (95, 98, Me, NT, 2000, XP).
106 \subsection*{Bacula Storage}
108 Den {\bf Bacula Storage} (Sicherungs)-Dienst leisten Programme, die
109 Sicherung und Wiederherstellung der Dateien und ihrer Attribute auf das
110 physikalische Sicherungsmedium bzw. die \textbf{Volumes} leisten. Der Storage-D\"{a}mon ist also f\"{u}r das
111 Beschreiben und Lesen Ihrer B\"{a}nder (oder eines anderen Sicherungsmediums wie
112 z.B. Dateien) zust\"{a}ndig. N\"{a}heres hierzu im Kapitel ``Storage Services Daemon
113 Design'' im ``Bacula Developer's Guide''. Der Sicherungsdienst l\"{a}uft als
114 D\"{a}monprozess auf dem Rechner, der \"{u}ber das Datensicherungsger\"{a}t verf\"{u}gt (in der
115 Regel ein Bandlaufwerk).
116 \subsection*{Catalog}
118 Die {\bf Catalog} (Verzeichnis)-Dienste werden von Programmen
119 geleistet, die f\"{u}r die Wartung der Datieindizes und \textbf{Volume}-Datenbanken
120 aller gesicherten Dateien zust\"{a}ndig sind. Über einen Verzeichnis-Dienst kann der
121 Systemadministrator oder Benutzer jede gew\"{u}nschte Datei rasch wiederfinden
122 und wiederherstellen. Durch den Verzeichnisdienst unterscheidet sich Bacula von
123 einfachen Sicherungsprogrammen wie ``tar'' oder ``bru'', da dieser
124 Dienst die Aufzeichnung aller verwendeten \textbf{Volumes}, aller gelaufener
125 Sicherungen und aller gesicherter Dateien pflegt und dadurch eine
126 effiziente Wiederherstellung und eine Verwaltung der Volumes erlaubt. Bacula
127 unterst\"{u}tzt momentan drei verschiedene Datenbanksysteme, MySQL, PostgreSQL
128 und SQLite, von denen eines vor der Kompilierung von {\bf Bacula} ausgew\"{a}hlt sein
131 Die drei Datenbanksysteme (MySQL, PostgreSQL und SQLite), die z.Z. unterst\"{u}tzt
132 werden, haben eine ganze Reihe von Besonderheiten wie z.B. schnelle Indizierung,
133 Baumsuche und Sicherheitsfunktionen. Wir planen die Unterst\"{u}tzung weiterer
134 gr\"{o}{\ss}erer SQL-Datenbanksysteme, doch hat die momentane Bacula-Version nur
135 Schnittstellen zu MySQL, PostgreSQL und SQLite. N\"{a}heres hierzu im Kapitel
136 \ilink{``Catalog Services Design Document''}{_ChapterStart30}.
138 Die RPM-Archive von MySQL und PostgreSQL sind Teil der RedHat-Linux- und mehrerer
139 anderer Distributionen, zudem ist die Erstellung der RPMs aus den Quelldateien
140 ganz einfach. N\"{a}heres hierzu im Kapitel \ilink{``Installation und Konfiguration
141 von MySQL''}{_ChapterStart} in diesem Handbuch. Weitere Informationen zu MySQL
142 im Internet: \elink{www.mysql.com}{http://www.mysql.com}.
143 Zu PostgreSQL lesen Sie bitte das Kapitel \ilink{``Installation und
144 Konfiguration von PostgreSQL''}{_ChapterStart10} in diesem Dokument.
145 Weiter Informationen zu PostgreSQL finden Sie hier:
146 \elink{www.postgresql.org}{http://www.postgresql.org}.
148 Die Konfiguration und Installation eines SQLite-Datenbanksystems ist noch
149 einfacher. Einzelheiten dazu im Kapitel \ilink{``Installation und Konfiguration
150 von SQLite''}{_ChapterStart33} in diesem Handbuch.
152 \subsection*{Bacula Monitor}
154 Der {\bf Bacula Monitor}-Dienst ist das Programm, welches es dem
155 Administrator oder Benutzer erlaubt, den aktuellen Zustand des {\bf Bacula
156 Directors}, der {\bf Bacula File D\"{a}monen} und der {\bf Bacula Storage D\"{a}monen}
157 zu beobachten (siehe oben). Zur Zeit ist hierf\"{u}r nur eine GTK+-Version
158 verf\"{u}gbar, die auf Gnome und KDE aufsetzt (oder jedem anderen Fenstermanager,
159 der den Standard von FreeDesktop.org f\"{u}r das System-Tray unterst\"{u}tzt).
161 Um erfolgreich sichern und wiederherstellen zu k\"{o}nnen, m\"{u}ssen die folgenden
162 vier D\"{a}monprozesse konfiguriert und gestartet sein: Der Director-D\"{a}mon, der
163 File-D\"{a}mon, der Storage-D\"{a}mon und MySQL, PostgreSQL oder SQLite.
165 \section{Die Bacula Konfiguration}
166 \index[general]{Konfiguration!Die Bacula }
167 \index[general]{Die Bacula Konfiguration }
169 Damit sich Bacula in Ihrem System zurechtfindet und es weiss welche
170 Client-Rechner wie zu sichern sind, m\"{u}ssen mehrere Konfigurationsdateien
171 erstellt werden, die ``Resourcen'' (bzw. ``Objekte'') enthalten. Die
172 folgende Abbildung gibt hierzu eine Übersicht:
174 \addcontentsline{lof}{figure}{Bacula Objects}
175 \includegraphics{./bacula-objects.eps}
177 \section{Die in diesem Dokument verwendeten Konventionen}
178 \index[general]{Die in diesem Dokument verwendeten Konventionen }
179 \index[general]{Dokument!verwendete Konventionen}
181 {\bf Bacula} ist in der Entwicklung und daher wird dieses Handbuch nicht in
182 jedem Fall mit dem Stand des Programmcodes \"{u}bereinstimmen. Steht in diesem
183 Handbuch vor einem Abschnitt ein Stern (*), bedeutet dies, dass das Beschriebene
184 noch nicht implementiert ist. Die Kennzeichnung durch ein Pluszeichen (+)
185 bedeutet, dass die Funktion m\"{o}glicherweise teilweise implementiert ist.
187 Wenn Sie dieses Handbuch als Teil eines offiziellen Release der
188 Software lesen, ist diese Kennzeichnung verl\"{a}{\ss}lich. Lesen Sie hingegen die
189 Online-Version dieses Handbuches auf \elink{ www.bacula.org}{http://www.bacula.org}, denken Sie
190 bitte daran, dass hier die aktuelle Entwicklungsversion (wie sie im CVS
191 vorhanden ist) beschrieben wird. In beiden F\"{a}llen wird aber das Handbuch dem
192 Code ein St\"{u}ckchen hinterherhinken.
194 \section{Quick Start}
195 \index[general]{Quick Start }
196 \index[general]{Start!Quick }
198 Um Bacula schnell zu konfigurieren und zum Laufen zu bringen, empfehlen wir,
199 zuerst den untenstehenden Abschnitt mit den Fachausdr\"{u}cken und das n\"{a}chste
200 Kapitel \ilink{``Baculas gegenw\"{a}rtiger Zustand''}{_ChapterStart2} durchzusehen.
202 Lesen Sie dann das Kapitel \ilink{``Mit Bacula beginnen''}{_ChapterStart37}, das
203 eine kurze Übersicht dar\"{u}ber gibt, wie man Bacula startet. Lesen
204 Sie danach das Kapitel \"{u}ber \ilink{``Die Installation von
205 Bacula''}{_ChapterStart17}, dann \ilink{``Die Konfiguration
206 von Bacula''}{_ChapterStart16} und schlie{\ss}lich das Kapitel \ilink{
207 ``Bacula in Betrieb nehmen''}{_ChapterStart1}.
209 \section{Terminologie}
210 \index[general]{Terminologie }
212 Um die Kommunikation \"{u}ber diese Projekt zu erleichtern, sind hier die
213 verwendeten Begriffe erl\"{a}utert
217 \item [Administrator]
218 \index[fd]{Administrator }
219 Die Person bzw. die Personen, die f\"{u}r die Pflege des Bacula-Systems
224 Wir verwenden den Ausdruck {\bf Backup} (Sicherung) wenn wir von einem
225 Bacula-Job sprechen, bei dem Dateien gesichert werden.
227 \item [Bootstrap File]
228 \index[fd]{Bootstrap File }
229 Das bootstrap file (Bootstrap-Datei) ist eine ASCII-Datei, die in kompakter
230 Form jene Befehle enth\"{a}lt, mit denen Bacula oder das eigenst\"{a}ndige
231 Dateiextrahierungswerkzeug {\bf bextract} den Inhalt eines oder mehrerer
232 \textbf{Volumes} wiederherstellen kann, wie z.B. einen vorher gesicherten Systemzustand.
233 Mit einer Bootstrap-Datei kann Bacula Ihr System wiederherstellen, ohne auf
234 einen \textbf{Catalog} angewiesen zu sein. Aus einem \textbf{Catalog} kann eine Bootstrap-Datei
235 erzeugt werden, um jede gew\"{u}nschte Datei/Dateien zu entpacken.
239 Der \textbf{Catalog} (das Verzeichnis) wird verwendet, um zusammenfassene
240 Informationen \"{u}ber Jobs, Clients und Dateien zu speichern und Informationen
241 dar\"{u}ber, in welchem \textbf{Volume} oder in welchen \textbf{Volumen} dies geschehen ist. Die
242 Informationen, die im \textbf{Catalog} gespeichert sind, erm\"{o}glichen es dem Administrator
243 bzw. Benutzer zu bestimmen, welche Jobs gelaufen sind, geben Auskunft \"{u}ber ihren
244 Status und wichtige Eigenschaften der gesicherten Dateien. Der Catalog ist eine
245 ``online resource'', enth\"{a}lt aber nicht die Daten der gesicherten Dateien. Vieles
246 der \textbf{Catalog}-Informationen ist auch in den \textbf{Volumes} (z.B. auf den B\"{a}ndern)
247 gespeichert. Nat\"{u}rlich sind auf den B\"{a}ndern auch die Kopien der Dateien und
248 deren Attribute (siehe unten).
250 Der \textbf{Catalog} ist ein Besonderheit Baculas, das es von einfachen Backup- und
251 Archiv-Programmen wie {\bf dump} und {\bf tar} unterscheidet.
255 In Baculas Terminologie bezeichnet das Wort Client jenen Rechner,
256 dessen Daten gesichert werden. Client ist auch ein anderes Wort f\"{u}r
257 den File-Dienst oder File-D\"{a}mon, der oft auch nur mit FD bezeichnet wird.
258 Clients werden in einer Resource der Konfigurationsdatei definiert.
262 Die Console(Konsole) ist ein Programm, das die Schnittstelle zum Director
263 bildet und \"{u}ber welches der Benutzer oder Systemadministrator Bacula
268 (D\"{a}monprozess) ist ein Unix-Fachausdruck f\"{u}r ein Programm, das
269 st\"{a}ndig im Hintergrund l\"{a}uft um spezielle Aufgaben
270 auszuf\"{u}hren. Auf Windows- und manchen Linux-Systemen werden
271 D\"{a}monprozesse {\bf Services}(Dienste) genannt.
274 \index[fd]{Directive }
275 Der Ausdruck directive (Anweisung) bezeichnet eine einzelne Angabe oder
276 eine Niederschrift innerhalb einer Resource einer Konfigurationsdatei, welche
277 einen speziellen Sachverhalt definiert. Beispielsweise definiert die {\bf
278 Name}-directive den Namen einer Resource.
281 \index[fd]{Director }
282 Baculas wichtigster D\"{a}monprozess, der alle Aktivit\"{a}ten des Bacula-Systems
283 zeitlich festlegt und beaufsichtigt. Gelegentlich bezeichnen wir ihn als
287 \index[fd]{Differential }
288 Differentiell ist eine Sicherung, wenn sie alle Dateien einbezieht, die
289 seit Beginn der letzten Vollsicherung ge\"{a}ndert wurden. Beachten Sie bitte, dass
290 dies von anderen Sicherungsprogrammen m\"{o}glicherweise anders definiert wird.
292 \item [File Attributes]
293 \index[fd]{File Attributes }
294 File Attributes (Dateiattribute) sind all diejenigen Informationen, die
295 n\"{o}tig sind, um eine Datei zu identifizieren. Dazu geh\"{o}ren alle ihre
296 Eigenschaften wie Gr\"{o}{\ss}e, Zeitpunkt der Erzeugung, Zeitpunkt der letzten
297 Ä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
298 Gedanken machen muss. Zu den Attributen geh\"{o}rt nicht der Inhalt der
302 \index[fd]{File Daemon }
303 Derjenige D\"{a}monprozess, welcher auf dem Client-Computer l\"{a}uft, dessen Daten
304 gesichert werden sollen. Wird manchmal auch als File-Service (Datendienst),
305 Client-Service (Client-Dienst) oder als FD bezeichnet.
311 Ein FileSet (Zusammenstellung von Dateien) ist eine Resource einer
312 Konfigurationsdatei, die festlegt, welche Dateien gesichert werden sollen.
313 Sie besteht aus einer Liste mit eingeschlossenen Dateien oder
314 Verzeichnissen, einer Liste mit ausgeschlossenen Dateien und Informationen
315 dar\"{u}ber, wie diese Dateien zu sichern sind (komprimiert, verschl\"{u}sselt,
316 signiert). N\"{a}heres hierzu im Abschnitt \ilink{``Definition der FileSet
317 Resource''}{FileSetResource} im \textbf{Director}-Kapitel dieses Dokuments.
320 \index[fd]{Incremental }
321 Inkrementiell ist eine Sicherung dann, wenn sie alle Dateien einbezieht, die
322 seit Beginn der letzten vollen, differentiellen oder inkrementiellen Sicherung
323 ge\"{a}ndert wurden. Normalerweise wird dies entweder durch die {\bf
324 Level}-Direktive innerhalb der Definition einer \textbf{Job Resource} oder in
325 einer \textbf{Schedule}-Resource festgelegt.
331 Ein Bacula-Job ist eine Konfigurations-Resource, die die Art und
332 Weise definiert, in der Bacula die Daten eines bestimmten Client-Rechners
333 sichert oder wiederherstellt. Sie besteht aus den Definitionen des {\bf Type}
334 (Sicherung, Wiederherstellung, Überpr\"{u}fung, usw.), des {\bf Level} (voll,
335 inkrementiell,...), des {\bf FileSet} und des Speicherorts ({\bf Storage}) an
336 welchem die Dateien gesichert werden sollen (Speicherger\"{a}t, Media-Pool). N\"{a}heres
337 hierzu im Abschnitt \ilink{``Definition der Job-Resource''
338 }{JobResource} im \textbf{Director}-Kapitel dieses Dokuments.
342 Dieses Programm hat eine Schnittstelle zu allen D\"{a}monprozessen, um dem
343 Benutzer oder Systemadministrator die Beobachtung von Baculas Zustand zu
347 \index[fd]{Resource }
348 Eine \textbf{Resource} ist ein Teil einer Konfigurationsdatei, die eine
349 bestimmte Informationseinheit definiert, die Bacula verf\"{u}gbar ist. Eine
350 \textbf{Resorce} enth\"{a}lt mehrere Direktiven (einzelne
351 Konfigurations-Anweisungen). Die {\bf Job}-Resource beispielsweise definiert
352 alle Eigenschaften eines bestimmten Jobs: Name, Zeitplan, Volume-Pool, Art der
353 Sicherung, Level der Sicherung...
357 ist eine \textbf{Resource} innerhalb einer Konfigurationsdatei, die den
358 Vorgang der Wiederherstellung einer verlorenen oder besch\"{a}digten Datei von
359 einem Sicherungsmedium beschreibt. Es ist der umgekehrte Vorgang wie bei
360 einer Sicherung, au{\ss}er dass in den meisten F\"{a}llen bei einem \textbf{Restore} nur
361 einige wenige Dateien wiederhergestellt werden, w\"{a}hrend bei einer Sicherung
362 normalerweise alle Dateien eines Systems gesichert werden. Selbstverst\"{a}ndlich
363 kann nach dem Ausfall einer Festplatte Bacula dazu benutzt werden, ein
364 vollst\"{a}ndiges \textbf{Restore} aller im System vorhandenen Dateien auszuf\"{u}hren.
367 \index[fd]{Schedule }
368 Ein \textbf{Schedule} (Zeitplan) ist eine \textbf{Resource} innerhalb einer
369 Konfigurationsdatei, die definiert, wann ein \textbf{Bacula-Job} ausgef\"{u}hrt
370 wird. Hierzu benutzt die \textbf{Job-Resource} den Namen des \textbf{Schedules}.
371 N\"{a}heres hierzu im Abschnitt \ilink{``Definition
372 der Schedule-Resource''}{ScheduleResource} im
373 ``Director''-Kapitel diese Handbuches.
377 (Dienst) ist die Bezeichnung f\"{u}r einen {\bf Daemon}(D\"{a}monprozess) unter
378 Windows (siehe oben). Diese Bezeichnung wird in letzter Zeit auch h\"{a}ufig in
379 Unix-Umgebungen benutzt.
381 \item [Storage Coordinates]
382 \index[fd]{Storage Coordinates }
383 Diejenige Information, die der \textbf{Storage-Dienst} zur\"{u}ckgibt und eine
384 Datei eindeutig im Sicherungsmedium lokalisiert. Sie besteht aus einem Teil der
385 zu jeder gespeicherten Datei geh\"{o}rt und einem Teil, der zum ganzen Job
387 Normalerweise wird diese Information im \textbf{Catalog} gespeichert, so dass der
388 Benutzer keine besonderen Kenntnisse der \textbf{Storage Coordinates} braucht.
389 Zu den \textbf{Storage Coordinates} geh\"{o}ren die Dateiattribute und der eindeutige Ort der Sicherung auf dem Sicherungs-Volume.
391 \item [Storage Daemon]
392 \index[fd]{Storage Daemon }
393 Der \textbf{Storage daemon} (Speicherd\"{a}mon), manchmal auch mit SD bezeichnet,
394 ist jenes Programm, das die Attribute und die Daten auf ein Sicherungs-Volume
395 schreibt (normalerweise ein Band oder eine Festplatte).
398 \index[sd]{Session } (Sitzung) bezeichnet in der Regel die interne Kommunikation
399 zwischen dem File-D\"{a}mon und dem Storage-D\"{a}mon. Der File-D\"{a}mon er\"{o}ffnet
400 eine {\bf Session} mit dem Storage-D\"{a}mon, um ein \textbf{FileSet} zu sichern
401 oder wiederherzustellen. Jede \textbf{Session} entspricht einem \textbf{Bacula-Job} (siehe oben).
405 Ein \textbf{Verify} ist ein Job, bei dem die aktuellen Dateiattribute mit
406 jenen verglichen werden, die zuvor im \textbf{Bacula-Catalog}
407 hinterlegt worden sind. Diese Funktion kann verwendet werden, um Änderungen an
408 wichtigen Systemdateien zu erkennen und ist damit {\bf Tripwire} \"{a}hnlich. Einer
409 der gr\"{o}{\ss}eren Vorteile dieser Funktionalit\"{a}t ist es, dass es gen\"{u}gt,
410 auf dem Rechner, den man sch\"{u}tzen will, den \textbf{File-D\"{a}mon} laufen zu haben.
411 \textbf{Director}, \textbf{Storage-D\"{a}mon} und der \textbf{Catalog} sind auf
412 einem anderen Rechner installiert. Wenn der Server dann gef\"{a}hrdet wird, ist es
413 \"{a}u{\ss}erst unwahrscheinlich, dass die Datenbank mit den Verifikationen davon
416 \textbf{Verify} kann auch zur Überpr\"{u}fung benutzt werden, ob die Daten des
417 zuletzt gelaufenen Jobs mit denen \"{u}bereinstimmen, welche davon im \textbf{Catalog}
418 gespeichert ist (es werden also die Dateiattribute verglichen). *\textbf{Verify}
419 vergleicht auch den Inhalt eines Volumes mit den Originaldateien auf der
423 \index[fd]{*Archive }
424 Eine \textbf{Archive}-Funktion wird nach einer Sicherung durchgef\"{u}hrt. Dabei
425 werden die \textbf{Volumes}, in denen die Daten gesichert sind, der aktiven
426 Benutzung entzogen, als ``Archived'' gekennzeichnet und f\"{u}r weitere
427 Sicherungen nicht mehr verwendet. Alle Dateien, die ein archiviertes
428 \textbf{Volume} enth\"{a}lt, werden aus dem Catalog entfernt. NOCH NICHT
433 Mit der \textbf{Update}-Funktion werden die Dateien auf dem entfernten
434 Rechner durch die entsprechenden vom Host-Rechner ersetzt. Dies entspricht der
435 Funktionalit\"{a}t von {\bf rdist}. NOCH NICHT IMPLEMENTIERT.
437 \item [Retention Period]
438 \index[fd]{Retention Period }
439 Bacula kennt verschiedene Arten von \textbf{Retention Periods} (Zeitspannen
440 w\"{a}hrend derer etwas bewahrt wird, Aufbewahrungszeiten). Die wichtigsten sind
441 die {\bf File Retention Period}, die {\bf Job Retention Period} und die {\bf
442 Volume Retention Period}. Jede dieser Retention-Periods bezieht sich auf die
443 Zeit, w\"{a}hrend der bestimmte Aufzeichnungen in der \textbf{Catalog}-Datenbank
444 gehalten werden. Dies sollte nicht mit jener Zeit verwechselt werden w\"{a}hrend
445 der Daten eines Volume g\"{u}ltig sind.
447 Die \textbf{File Retention Period} bestimmt wie lange die Eintr\"{a}ge zu den
448 Dateien in der \textbf{Catalog}-Datenbank gehalten werden. Diese Zeitspanne ist
449 wichtig, da diese Eintr\"{a}ge bei weitem den gr\"{o}{\ss}ten Teil des Speicherplatzes in
450 der Datenbank belegen. Daher muss gew\"{a}hrleistet sein, dass \"{u}berfl\"{u}ssige oder
451 obsolete Eintr\"{a}ge regelm\"{a}{\ss}ig aus der Datenbank entfernt werden (hierzu N\"{a}heres im Abschnitt zum {\bf Retention}-Befehl in der Beschreibung der \textbf{Console}-Befehle).
453 Die \textbf{Job Retention Period} ist die Zeitspanne, w\"{a}hrend der Eintr\"{a}ge zu
454 den Jobs in der Datenbank gehalten werden. Beachten Sie, dass alle Dateieintr\"{a}ge
455 mit dem Job, mit dem sie gesichert wurden, verbunden sind. Die Eintr\"{a}ge zu den
456 Dateien k\"{o}nnen gel\"{o}scht sein, w\"{a}hrend die Aufzeichnungen zu den Jobs erhalten
457 bleiben. In diesem Fall wird man Informationen \"{u}ber gelaufene Sicherungsjobs
458 haben, jedoch keine Einzelheiten \"{u}ber die Dateien, die dabei gesichert
459 wurden. Normalerweise werden mit dem L\"{o}schen eines
460 Job-Eintrags auch alle seine Aufzeichnungen zu den Dateien gel\"{o}scht.
462 Die \textbf{Volume Retention Period} bestimmt die Mindestzeit, w\"{a}hrend der
463 ein bestimmtes \textbf{Volume} erhalten bleibt, bevor es wiederverwendet wird.
464 Bacula wird in der Regel niemals ein \textbf{Volume} \"{u}berschreiben, das als
465 einziges die Sicherungskopie einer bestimmten Datei enth\"{a}lt. Im Idealfall wird
466 der \textbf{Catalog} f\"{u}r alle benutzten \textbf{Volume} die Eintr\"{a}ge aller
467 gesicherten Daeien enthalten. Wenn ein \textbf{Volume} \"{u}berschrieben wird,
468 werden die Dateieeintr\"{a}ge, die zuvor in ihm gespeichert waren aus dem
469 \textbf{Catalog} entfernt. Gibt es allerdings einen sehr gro{\ss}en Pool von
470 \textbf{Volumes} oder gibt es \textbf{Volumes}, die nie \"{u}berschrieben werden,
471 kann die \textbf{Catalog}-Datenbank riesig werden. Um den \textbf{Catalog} in
472 einer handhabbaren Gr\"{o}{\ss}e zu halten, sollten Informationen zu den Sicherungen
473 nach der definierten \textbf{File Retention Period} aus ihm entfernt werden.
474 Bacula hat Mechanismen, um den \textbf{Catalog} entsprechend der
475 definierten \textbf{Retention Periods} automatisch zu bereinigen.
479 Bei einer \textbf{Scan}-Operation wird der Inhalt eines oder mehrerer
480 \textbf{Volumes} durchsucht. Diese \textbf{Volumes} und die Informationen \"{u}ber
481 die Dateien, welche sie enthalten, werden wieder in den Bacula-\textbf{Catalog}
482 eingetragen. Danach k\"{o}nnen die Dateien in diesen \textbf{Volumes} auf
483 einfache Weise wiederhergestellt werden. Diese Funktion ist teilweise
484 hilfreich, wenn bestimmte \textbf{Volumes} oder \textbf{Jobs} ihre \textbf{Retention Period}
485 \"{u}berschritten haben und aus dem \textbf{Catalog} entfernt worden sind. Um die
486 Daten von den \textbf{Volumes} in die Datenbank einzulesen, wird das Programm
487 {\bf bscan} verwendet. N\"{a}heres hierzu im Abschnitt \ilink{bscan}{bscan} im Kapitel ``Bacula Hilfsprogramme'' dieses Handbuches.
491 Ein \textbf{Volume} ist eine Einheit, auf der gesichert wird, normalerweise
492 ein Band oder eine benannte Datei auf der Festplatte auf welche/s Bacula die
493 Daten einer oder mehrerer Sicherungsjobs speichert. Alle \textbf{Volumes}
494 erhalten von Bacula eine digitale Kennzeichnung, so dass Bacula jederzeit wei{\ss},
495 welches \textbf{Volume} es tats\"{a}chlich liest. (Normalerweise sollte es mit
496 Dateien auf der Festplatte keine Verwechslungen geben, doch bei B\"{a}ndern mountet
497 man aus Versehen leicht das Falsche).
500 \section{Was Bacula nicht ist}
501 \index[general]{Was Bacula nicht ist }
502 \index[general]{nicht ist!Was Bacula }
504 {\bf Bacula} ist ein Sicherungs-, Wiederherstellungs- und Verifikationsprogramm, aber von sich aus noch kein komplettes Rettungsprogramm f\"{u}r den Katastrophenfall. Allerdings kann
505 Bacula Teil eines Rettungsprogramms sein, falls Sie sorgf\"{a}ltig planen und die
506 Anweisungen im Kapitel \ilink{Disaster Recovery}{_ChapterStart38} dieses
509 Bei sorgf\"{a}ltiger Planung, wie sie im Kapitel ``Disaster Recovery'' dargestellt
510 ist, kann {\bf Bacula} ein wesentlicher Bestandteil eines
511 Rettungssystems sein. Wenn Sie zum Beispiel eine Bootdiskette
512 erstellt haben, dazu eine Bacula-Rettungs-CD, auf der sie die aktuellen
513 Partitionsdaten Ihrer Festplatte gespeichert haben und eine komplette Bacula
514 Sicherung vorhalten, ist es m\"{o}glich, Ihr System auf einer leeren Festplatte
517 Wenn Sie die den Befehl {\bf WriteBootstrap} in einem Ihrer Sicherungs-Jobs
518 verwendet oder auf irgend eine andere Art eine g\"{u}ltige
519 \textbf{Bootstrap}-Datei gesichert haben, werden Sie damit in der Lage sein, die notwendigen Dateien zu entpacken (ohne den \textbf{Catalog} zu verwenden
520 oder von Hand nach Dateien suchen zu m\"{u}ssen).
524 \section{Interaktionen zwischen den Bacula-Diensten}
525 \index[general]{Interaktionen zwischen den Bacula-Diensten }
526 \index[general]{Diensten!Interaktionen zwischen den Bacula- }
528 Das untenstehende Diagramm zeigt typische Interaktionen zwischen den einzelnen
529 Bacula-Diensten bei einem Sicherungs-Job. Jeder Block steht ungef\"{a}hr f\"{u}r einen
530 eigenen Prozess (normalerweise ein D\"{a}mon). Im gro{\ss}en und ganzen hat der
531 Director den Überblick \"{u}ber die Aktionen und pflegt die
534 \addcontentsline{lof}{figure}{Interaktionen zwischen den Bacula-Diensten}
535 \includegraphics{./flow.eps}
projects / bacula / docs / blob