%%
%%

\section*{Baculas  Stand}
\label{_ChapterStart2}
\index[general]{Baculas momentaner Stand }
\addcontentsline{toc}{section}{Baculas momentaner Stand}

(was gegenwärtig implementiert und funktionsfähig ist und was nicht)

\subsection*{Was implementiert ist}
\index[general]{implementiert!Was ist }
\index[general]{Was implementiert ist }
\addcontentsline{toc}{subsection}{Was implementiert ist}

\begin{itemize}
\item Sicherung/Wiederherstellung im Netzwerkes unter der Regie eines
zentralen \textbf{Director}-Prozess. 

\item automatische Ausführung von 
   \ilink{Job}{JobDef}s nach einem festgelegten Zeitplan.
   
\item Terminplanung für mehrere Jobs zur gleichen Zeit.

\item die Möglichkeit einen oder mehrere Jobs zur gleichen Zeit auszuführen. 

\item zeitliche Staffelung der Jobs entsprechend ihrer Priorität. 

\item die Wiederherstellung einer oder mehrerer Dateien, die interaktiv
aus der letzten Sicherung oder einer Sicherung vor einem festgelegten
Zeitpunkt ausgewählt werden können.  

\item die Wiederherstellung aller Dateien eines Systems auf einer
leeren Festplatte. Dieser Vorgang kann bei Linux- und Solaris-Systemen (mit
Einschränkungen) größtenteils automatisch ablaufen. Näheres hierzu im Kapitel
\ilink{``Disaster Recovery Using Bacula''}{_ChapterStart38}. Benutzer
berichten, dass dies auch mit Win2K/XP-Systemen funktioniert.  

\item die Ermittlung und Wiederherstellung von Dateien mittels eigenständiger
Hilfsprogramme wie {\bf bls} und {\bf bextract}. Unter anderem ist es damit
möglich, Dateien wiederherzustellen, wenn Bacula und/oder die
\textbf{Catalog}-Datenbank nicht verfügbar ist/sind. Beachten Sie aber, dass wir
hierfür den ``restore''-Befehl an der \textbf{Console} empfehlen und diese
Hilfsprogramme nur für den Notfall vorgesehen sind. 

\item die Möglichkeit, die \textbf{Catalog}-Datenbank durch Auslesen
der \textbf{Volumes} mit dem Hilfsprogramm {\bf bscan} wieder herzustellen.

\item eine \ilink{Konsolen}{UADef}-Schnittstelle zum \textbf{Director}, über die
dieser vollkommen gesteuert werden kann. Die \textbf{Console} ist als
Shell-Programm, GNOME-GUI und wxWidgets-GUI verfügbar. Beachten Sie bitte, dass
das  GNOME-GUI gegenüber dem Shell-Programm zur Zeit nur sehr wenige zusätzliche
Funktionen aufweist.

\item die Verifikation der Dateien, die zuvor in das
\textbf{Catalog}-Verzeichnis aufgenommen wurden, erlaubt eine Funktionalität
wie sie das Programm ``Tripwire'' hat (Intrusion Detection).  

\item die Authentifizierung der Komponenten (Dämonen) untereinander
durch CRAM-MD5 Passwörter.

\item eine konfigurierbare \ilink{TLS (ssl)-Verschlüsselung }{_ChapterStart61}
zwischen den einzelnen Komponenten.

\item leicht verständliche und erweiterbare  
\ilink{Konfigurationsdateien}{_ChapterStart40} für jeden einzelnen
Dämonprozess. 

\item eine \textbf{Catalog}-Datenbank zur Aufzeichnung der \textbf{Volumes},
\textbf{Pools}, \textbf{Jobs} und der Informationen über die gesicherten
Dateien.

\item Unterstützung von \textbf{SQLite}, \textbf{PostgreSQL} und
\textbf{MySQL} \textbf{Catalog}-Datenbanksystemen. 

\item vom Benutzer erweiterbare Datenbankabfragen an \textbf{SQLite}-,
\textbf{PostgreSQL} und \textbf{MySQL}-Datenbanksysteme. 

\item gekennzeichnete \textbf{Volumes}, die ein versehentliches
Überschreiben (zumindest durch Bacula) verhindern.  

\item eine beliebige Anzahl verschiedener \textbf{Jobs} und
\textbf{Clients} kann auf ein einzelnes \textbf{Volume} gesichert werden. Dies
bedeutet, dass von Linux-, Unix-, Sun- und Windows-Rechnern auf das gleiche
\textbf{Volume} gesichert werden kann. Das gleiche gilt für die
Wiederherstellung. 

\item eine Sicherung kann sich über mehrere \textbf{Volumes} erstrecken. Sobald ein
\textbf{Volume} voll ist, fordert {\bf Bacula} automatisch das nächste
\textbf{Volume} an und setzt die Sicherung fort. 
 
\item die Verwaltung von \ilink{\textbf{Pools}
und \textbf{Volumes}}{PoolResource} erlaubt einen anpassungsfähigen Umgang mit
\textbf{Volumes} (z.B. Gruppen von \textbf{Volumes} für die monatliche,
wöchentliche, tägliche Sicherung, Gruppen von \textbf{Volumes} für bestimmte
\textbf{Clients}...). 

\item das Datenformat der \textbf{Volumes} ist systemunabhängig. Bei Bedarf
können die Daten von Linux-, Solaris- und Windows-Clients in
dasselbe \textbf{Volumen} gespeichert werden.

\item ein konfigurierbares \ilink{Messages}-Handling.
Dazu gehört der Versand von Botschaften aller Dämon-Prozesse an den \textbf{Director}
und die automatische Benachrichtigung des Benutzers über das Mailsystem.

\item Implementierung der Prozesse als Multithread-Programme. 

\item Programmtechnisch keine Begrenzung der Länge der Dateinamen oder
der Botschaften. 

\item GZIP-Komprimierung für jede einzelne Datei, die schon der Client
erledigt, sofern dies vor einer Übertragung im Netzwerk angefordert wird.

\item bei Bedarf die Berechnung von MD5 oder SHA1 Signaturen der
Dateidaten.

\item POSIX ACLs werden - wenn aktiviert -  unter den meisten Betriebssystemen gesichert und wiederhergestellt.
 
\item die Unterstützung von Autochangern über ein einfache Shell-Schnittstelle.
Damit ist es möglich, praktisch mit jedem Autoloader-Programm zu kommunizieren.
Ein Skript für {\bf mtx} ist bereitgestellt. 

\item unterstützt Autochanger-Barcodes -- entsprechend der Barcodes
wird das Band gekennzeichnet.

\item automatische Unterstützung mehrerer Autochanger-Magazine. Hierbei wird entweder der Barcode oder das Band gelesen.

\item Unterstützung von Autochangern mit mehreren Laufwerken

\item Sicherung/Wiederherstellung als raw-Backup. Hierbei muß die Wiederherstellung auf den gleichen Datenträger erfolgen.

\item jeder Datenblock (etwa 64KByte) der \textbf{Volumes} enthält die
Prüfsumme der Daten.

\item Zugangskontrolllisten für \textbf{Consolen}, die dem Benutzer einen Zugang nur zu den eigenen Daten erlauben.  

\item Zwischenspeicherung der zu sichernden Daten auf der Festplatte und
fortlaufende Beschreibung des Bandes mit den zwischengespeicherten Daten 
verhindert den ``Schoe-Shine-Effekt'' bei einer inkrementiellen oder
differentiellen Sicherung.

\item Sicherung/Wiederherstellung von Dateien, die größer sind als 2GB.

\item Unterstützung von 64Bit-Systemen wie z.B. AMD64.

\item es ist möglich, die Kommunikation der Dämonen untereinander durch
STunnel zu verschlüsseln.
 
\item Unterstützung von ANSI- und IBM Band-Labels.

\item Unterstützung von Unicode-Dateinamen (z.B. Chinesisch) auf Win32-Rechnern mit der Version 1.37.28 und höher.

\item konsistente Sicherung von geöffneten Dateien von Win32-Systemen (WinXP, Win2003, nicht Win2000) durch Verwendung von Volume Shadow Copy (VSS).

\end{itemize}

\subsection*{Die Vorteile von Bacula gegenüber anderen Sicherungsprogrammen}
\index[general]{Die Vorteile von Bacula gegenüber anderen Sicherungsprogrammen}
\index[general]{Sicherungsprogrammen!Die Vorteile von Bacula gegenüber anderen}
\addcontentsline{toc}{subsection}{Die Vorteile von Bacula gegenüber anderen
Sicherungsprogrammen}

\begin{itemize}
\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,
dass ihre Dateiattribute korrekt gesichert und wiederhergestellt werden.

\item Man kann auch Clients sichern ohne eine Client-Software zu benutzen und
verwendet hierzu NFS oder Samba. Wir empfehlen jedoch, sofern möglich, auf jedem
Rechner, von dem Daten gesichert werden sollen, einen eigenen File-Dämon laufen zu
haben.

\item Bacula kann mit Sicherungen umgehen, die auf mehrere Volumes verteilt
sind.

\item eine umfassende SQL-Datenbank aller gesicherter Dateien ermöglicht den Überblick über alle gespeicherte Dateien in jedem einzelnen Volume.

\item automatische Bereinigung der Datenbank (die Entfernung alter Aufzeichnungen) und dadurch eine Vereinfachung der Datenbankadministration.

\item durch die Verwendung beliebiger SQL-Datenbanksysteme ist Bacula sehr anpassungsfähig.

\item durch den modularen, dabei aber einheitlichen Entwurf ist Bacula in hohem Maße skalierbar.
  
\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.

\item Bacula hat ein eingebautes Steuerungsprogramm für die Sicherungsjobs.

\item Das Format der \textbf{Volumes} ist dokumentiert und es gibt einfache C-Programme mit denen sie gelesen und beschrieben werden können

\item Bacula benutzt eindeutige (bei der IANA registrierte) TCP/IP-Ports -- also weder RPCs noch Shared Memory.

\item Baculas Installation und Konfiguration ist gegenüber anderen vergleichbaren Produkten relativ einfach.  

\item laut einem unserer Benutzer ist Bacula genau so schnell wie die wichtigen großen kommerziellen Programme.

\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.  

\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.

\item Bacula hat eine Rettungs-CD für Linux-Systeme mit den folgenden Eigenschaften:  
   \begin{itemize}
   \item Sie kompilieren sie von Grund auf auf ihrem eigenen System mit einem einzigen einfachen Befehl:
      ``make'' (...OK, Sie brauchen dann noch ``make burn''...). 
   \item die Rettungs-CD verwendet Ihren Kernel
   \item sie schreibt Skripte entsprechend der Parameter Ihrer Festplatte mit denen Sie diese automatisch repartitionieren und formatieren können, um den Ausgangszustand wieder herzustellen.
   
   \item sie hat ein Skript, das Ihr Netzwerk wieder starten wird (mit der korrekten IP-Adresse)  
   
   \item sie hat ein Skript, mit dem Ihre Festplatten automatisch gemountet werden.
      
   \item eine vollwertiger Bacula-FD ist statisch eingebunden  
   
   \item sie können der Rettungs-CD auf einfache Weise zusätzliche Daten und Programme hinzufügen.  
   \end{itemize}

\end{itemize}

\subsection*{Einschränkungen der aktuellen Implementierung}
\index[general]{Einschränkungen der aktuellen Implementierung }
\index[general]{aktuelle Implementierung! Einschränkungen der}
\addcontentsline{toc}{subsection}{Einschränkungen der aktuellen Implementierung}

\begin{itemize}
\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.
Lange Dateinamen für Win32-Systeme werden in einer späteren Version implementiert sein.

\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.
  
\item Dateien, die nach einer Vollsicherung gelöscht wurden, werden bei einer Wiederherstellung eingeschlossen.

\item Datei-System-Module fehlen(dies wären konfigurierbare Routinen, um spezielle Dateien zu sichern/wiederherzustellen).  

\item Verschlüsselung des Dateninhalts der \textbf{Volumes}.  

\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.

   \end{itemize}

\subsection*{Grenzen und Beschränkungen des Software Design}
\index[general]{Restrictions!Design Limitations or }
\index[general]{Design Limitations or Restrictions }
\addcontentsline{toc}{subsection}{Design Limitations or Restrictions}

\begin{itemize}
\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.

\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.

\end{itemize}
