4 \section*{Baculas Stand}
6 \index[general]{Baculas momentaner Stand }
7 \addcontentsline{toc}{section}{Baculas momentaner Stand}
9 (was gegenwärtig implementiert und funktionsfähig ist und was nicht)
11 \subsection*{Was implementiert ist}
12 \index[general]{implementiert!Was ist }
13 \index[general]{Was implementiert ist }
14 \addcontentsline{toc}{subsection}{Was implementiert ist}
17 \item Sicherung/Wiederherstellung im Netzwerkes unter der Regie eines
18 zentralen \textbf{Director}-Prozess.
20 \item automatische Ausführung von
21 \ilink{Job}{JobDef}s nach einem festgelegten Zeitplan.
23 \item Terminplanung für mehrere Jobs zur gleichen Zeit.
25 \item die Möglichkeit einen oder mehrere Jobs zur gleichen Zeit auszuführen.
27 \item zeitliche Staffelung der Jobs entsprechend ihrer Priorität.
29 \item die Wiederherstellung einer oder mehrerer Dateien, die interaktiv
30 aus der letzten Sicherung oder einer Sicherung vor einem festgelegten
31 Zeitpunkt ausgewählt werden können.
33 \item die Wiederherstellung aller Dateien eines Systems auf einer
34 leeren Festplatte. Dieser Vorgang kann bei Linux- und Solaris-Systemen (mit
35 Einschränkungen) größtenteils automatisch ablaufen. Näheres hierzu im Kapitel
36 \ilink{``Disaster Recovery Using Bacula''}{_ChapterStart38}. Benutzer
37 berichten, dass dies auch mit Win2K/XP-Systemen funktioniert.
39 \item die Ermittlung und Wiederherstellung von Dateien mittels eigenständiger
40 Hilfsprogramme wie {\bf bls} und {\bf bextract}. Unter anderem ist es damit
41 möglich, Dateien wiederherzustellen, wenn Bacula und/oder die
42 \textbf{Catalog}-Datenbank nicht verfügbar ist/sind. Beachten Sie aber, dass wir
43 hierfür den ``restore''-Befehl an der \textbf{Console} empfehlen und diese
44 Hilfsprogramme nur für den Notfall vorgesehen sind.
46 \item die Möglichkeit, die \textbf{Catalog}-Datenbank durch Auslesen
47 der \textbf{Volumes} mit dem Hilfsprogramm {\bf bscan} wieder herzustellen.
49 \item eine \ilink{Konsolen}{UADef}-Schnittstelle zum \textbf{Director}, über die
50 dieser vollkommen gesteuert werden kann. Die \textbf{Console} ist als
51 Shell-Programm, GNOME-GUI und wxWidgets-GUI verfügbar. Beachten Sie bitte, dass
52 das GNOME-GUI gegenüber dem Shell-Programm zur Zeit nur sehr wenige zusätzliche
55 \item die Verifikation der Dateien, die zuvor in das
56 \textbf{Catalog}-Verzeichnis aufgenommen wurden, erlaubt eine Funktionalität
57 wie sie das Programm ``Tripwire'' hat (Intrusion Detection).
59 \item die Authentifizierung der Komponenten (Dämonen) untereinander
60 durch CRAM-MD5 Passwörter.
62 \item eine konfigurierbare \ilink{TLS (ssl)-Verschlüsselung }{_ChapterStart61}
63 zwischen den einzelnen Komponenten.
65 \item leicht verständliche und erweiterbare
66 \ilink{Konfigurationsdateien}{_ChapterStart40} für jeden einzelnen
69 \item eine \textbf{Catalog}-Datenbank zur Aufzeichnung der \textbf{Volumes},
70 \textbf{Pools}, \textbf{Jobs} und der Informationen über die gesicherten
73 \item Unterstützung von \textbf{SQLite}, \textbf{PostgreSQL} und
74 \textbf{MySQL} \textbf{Catalog}-Datenbanksystemen.
76 \item vom Benutzer erweiterbare Datenbankabfragen an \textbf{SQLite}-,
77 \textbf{PostgreSQL} und \textbf{MySQL}-Datenbanksysteme.
79 \item gekennzeichnete \textbf{Volumes}, die ein versehentliches
80 Überschreiben (zumindest durch Bacula) verhindern.
82 \item eine beliebige Anzahl verschiedener \textbf{Jobs} und
83 \textbf{Clients} kann auf ein einzelnes \textbf{Volume} gesichert werden. Dies
84 bedeutet, dass von Linux-, Unix-, Sun- und Windows-Rechnern auf das gleiche
85 \textbf{Volume} gesichert werden kann. Das gleiche gilt für die
88 \item eine Sicherung kann sich über mehrere \textbf{Volumes} erstrecken. Sobald ein
89 \textbf{Volume} voll ist, fordert {\bf Bacula} automatisch das nächste
90 \textbf{Volume} an und setzt die Sicherung fort.
92 \item die Verwaltung von \ilink{\textbf{Pools}
93 und \textbf{Volumes}}{PoolResource} erlaubt einen anpassungsfähigen Umgang mit
94 \textbf{Volumes} (z.B. Gruppen von \textbf{Volumes} für die monatliche,
95 wöchentliche, tägliche Sicherung, Gruppen von \textbf{Volumes} für bestimmte
98 \item das Datenformat der \textbf{Volumes} ist systemunabhängig. Bei Bedarf
99 können die Daten von Linux-, Solaris- und Windows-Clients in
100 dasselbe \textbf{Volumen} gespeichert werden.
102 \item ein konfigurierbares \ilink{Messages}-Handling.
103 Dazu gehört der Versand von Botschaften aller Dämon-Prozesse an den \textbf{Director}
104 und die automatische Benachrichtigung des Benutzers über das Mailsystem.
106 \item Implementierung der Prozesse als Multithread-Programme.
108 \item Programmtechnisch keine Begrenzung der Länge der Dateinamen oder
111 \item GZIP-Komprimierung für jede einzelne Datei, die schon der Client
112 erledigt, sofern dies vor einer Übertragung im Netzwerk angefordert wird.
114 \item bei Bedarf die Berechnung von MD5 oder SHA1 Signaturen der
117 \item POSIX ACLs werden - wenn aktiviert - unter den meisten Betriebssystemen gesichert und wiederhergestellt.
119 \item die Unterstützung von Autochangern über ein einfache Shell-Schnittstelle.
120 Damit ist es möglich, praktisch mit jedem Autoloader-Programm zu kommunizieren.
121 Ein Skript für {\bf mtx} ist bereitgestellt.
123 \item unterstützt Autochanger-Barcodes -- entsprechend der Barcodes
124 wird das Band gekennzeichnet.
126 \item automatische Unterstützung mehrerer Autochanger-Magazine. Hierbei wird entweder der Barcode oder das Band gelesen.
128 \item Unterstützung von Autochangern mit mehreren Laufwerken
130 \item Sicherung/Wiederherstellung als raw-Backup. Hierbei muß die Wiederherstellung auf den gleichen Datenträger erfolgen.
132 \item jeder Datenblock (etwa 64KByte) der \textbf{Volumes} enthält die
135 \item Zugangskontrolllisten für \textbf{Consolen}, die dem Benutzer einen Zugang nur zu den eigenen Daten erlauben.
137 \item Zwischenspeicherung der zu sichernden Daten auf der Festplatte und
138 fortlaufende Beschreibung des Bandes mit den zwischengespeicherten Daten
139 verhindert den ``Schoe-Shine-Effekt'' bei einer inkrementiellen oder
140 differentiellen Sicherung.
142 \item Sicherung/Wiederherstellung von Dateien, die größer sind als 2GB.
144 \item Unterstützung von 64Bit-Systemen wie z.B. AMD64.
146 \item es ist möglich, die Kommunikation der Dämonen untereinander durch
147 STunnel zu verschlüsseln.
149 \item Unterstützung von ANSI- und IBM Band-Labels.
151 \item Unterstützung von Unicode-Dateinamen (z.B. Chinesisch) auf Win32-Rechnern mit der Version 1.37.28 und höher.
153 \item konsistente Sicherung von geöffneten Dateien von Win32-Systemen (WinXP, Win2003, nicht Win2000) durch Verwendung von Volume Shadow Copy (VSS).
157 \subsection*{Die Vorteile von Bacula gegenüber anderen Sicherungsprogrammen}
158 \index[general]{Die Vorteile von Bacula gegenüber anderen Sicherungsprogrammen}
159 \index[general]{Sicherungsprogrammen!Die Vorteile von Bacula gegenüber anderen}
160 \addcontentsline{toc}{subsection}{Die Vorteile von Bacula gegenüber anderen
161 Sicherungsprogrammen}
164 \item da für jeden Rechner ein eigener Client existiert, können die Daten von Betriebssystemen aller Art gesichert und wiederhergestellt werden, wobei immer gewährleistet ist,
165 dass ihre Dateiattribute korrekt gesichert und wiederhergestellt werden.
167 \item Man kann auch Clients sichern ohne eine Client-Software zu benutzen und
168 verwendet hierzu NFS oder Samba. Wir empfehlen jedoch, sofern möglich, auf jedem
169 Rechner, von dem Daten gesichert werden sollen, einen eigenen File-Dämon laufen zu
172 \item Bacula kann mit Sicherungen umgehen, die auf mehrere Volumes verteilt
175 \item eine umfassende SQL-Datenbank aller gesicherter Dateien ermöglicht den Überblick über alle gespeicherte Dateien in jedem einzelnen Volume.
177 \item automatische Bereinigung der Datenbank (die Entfernung alter Aufzeichnungen) und dadurch eine Vereinfachung der Datenbankadministration.
179 \item durch die Verwendung beliebiger SQL-Datenbanksysteme ist Bacula sehr anpassungsfähig.
181 \item durch den modularen, dabei aber einheitlichen Entwurf ist Bacula in hohem Maße skalierbar.
183 \item da Bacula Dämonen auf den Client-Rechnern benutzt, ist es möglich, dort laufende Datenbank- oder sonstige Anwendungen mit systemeigenen Befehlen zu beenden und nach einer Sicherung die entsprechenden Anwendungen wieder zu starten. Dies alles kann aus einem einzigen Bacula-Job heraus geschehen.
185 \item Bacula hat ein eingebautes Steuerungsprogramm für die Sicherungsjobs.
187 \item Das Format der \textbf{Volumes} ist dokumentiert und es gibt einfache C-Programme mit denen sie gelesen und beschrieben werden können
189 \item Bacula benutzt eindeutige (bei der IANA registrierte) TCP/IP-Ports -- also weder RPCs noch Shared Memory.
191 \item Baculas Installation und Konfiguration ist gegenüber anderen vergleichbaren Produkten relativ einfach.
193 \item laut einem unserer Benutzer ist Bacula genau so schnell wie die wichtigen großen kommerziellen Programme.
195 \item laut einem anderen Benutzer ist Bacula vier mal so schnell wie eine andere kommerzielle Anwendung. Das vielleicht deswegen, weil diese Anwendung ihre Verzeichnisinformationen in vielen einzelnen Dateien anstatt in einer SQL-Datenbank speichert, wie Bacula es tut.
197 \item neben der grafischen Benutzeroberfläche zur Verwaltung hat Bacula eine umfassende Shell-Schnittstelle für die Wartungsaufgaben, wobei der Administrator Werkzeuge wie z.B. ``ssh'' verwenden kann, um jeden Teil von Bacula von überall (sogar von Zuhause) zu administrieren.
199 \item Bacula hat eine Rettungs-CD für Linux-Systeme mit den folgenden Eigenschaften:
201 \item Sie kompilieren sie von Grund auf auf ihrem eigenen System mit einem einzigen einfachen Befehl:
202 ``make'' (...OK, Sie brauchen dann noch ``make burn''...).
203 \item die Rettungs-CD verwendet Ihren Kernel
204 \item sie schreibt Skripte entsprechend der Parameter Ihrer Festplatte mit denen Sie diese automatisch repartitionieren und formatieren können, um den Ausgangszustand wieder herzustellen.
206 \item sie hat ein Skript, das Ihr Netzwerk wieder starten wird (mit der korrekten IP-Adresse)
208 \item sie hat ein Skript, mit dem Ihre Festplatten automatisch gemountet werden.
210 \item eine vollwertiger Bacula-FD ist statisch eingebunden
212 \item sie können der Rettungs-CD auf einfache Weise zusätzliche Daten und Programme hinzufügen.
217 \subsection*{Einschränkungen der aktuellen Implementierung}
218 \index[general]{Einschränkungen der aktuellen Implementierung }
219 \index[general]{aktuelle Implementierung! Einschränkungen der}
220 \addcontentsline{toc}{subsection}{Einschränkungen der aktuellen Implementierung}
223 \item Pfade und Dateinamen mit mehr als 260 Zeichen werden auf Win32-Systemen nicht unterstützt. Diese werden zwar gesichert, können aber nicht wiederhergestellt werden. Durch Verwendung der Direktive {\bf Portable=yes} in Ihrem FileSet können Dateien mit langen Namen auf Unix- bzw. Linux-Systemen wiederhergestellt werden.
224 Lange Dateinamen für Win32-Systeme werden in einer späteren Version implementiert sein.
226 \item Sollten Sie mehr als 4 Milliarden Dateieinträge in Ihrer Datenbank gespeichert haben, wird der FileID der Datenbank vermutlich überlaufen. Dies wäre eine ziemlich große Datenbank, aber immerhin ist sie denkbar. Irgendwann einmal wird das Feld für den FileID von Bacula von 32 auf 64 Bit erweitert werden und das Problem ist gelöst. In der Zwischenzeit ist die Verwendung mehrerer Datenbanken eine gute Lösung.
228 \item Dateien, die nach einer Vollsicherung gelöscht wurden, werden bei einer Wiederherstellung eingeschlossen.
230 \item Datei-System-Module fehlen(dies wären konfigurierbare Routinen, um spezielle Dateien zu sichern/wiederherzustellen).
232 \item Verschlüsselung des Dateninhalts der \textbf{Volumes}.
234 \item Bacula kann die Dateien eines einzelnen Jobs nicht von zwei oder mehreren Speichergeräten oder verschiedenen Speichermedien wiederherstellen. Daher wird eine Wiederherstellung einige Handarbeit erfordern, wenn sie auf mehr als ein Sicherungsgerät oder verschiedene Medientypen speichern.
238 \subsection*{Grenzen und Beschränkungen des Software Design}
239 \index[general]{Restrictions!Design Limitations or }
240 \index[general]{Design Limitations or Restrictions }
241 \addcontentsline{toc}{subsection}{Design Limitations or Restrictions}
244 \item Namen (\textbf{Resource}-Namen, \textbf{Volume}-Names und ähnliche) in Baculas Konfigurationsdateien sind auf eine bestimmte Länge beschränkt . Momentan liegt die Grenze bei 127 Zeichen. Beachten Sie bitte, dass diese Einschränkungen nicht die Dateinamen betrifft, die beliebig lang sein können.
246 \item Durch die Nicht-Unicode Windows API, die wir auf Win32-Maschinen verwenden, sind wir bei Dateinamen auf 260 Zeichen beschränkt. Wir planen dies in einer zukünftigen Version zu korrigieren, indem wir die Unicode-API verwenden.