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