%%
%%

\chapter{Baculas Stand}
\label{_ChapterStart2}
\index[general]{Baculas momentaner Stand }

(was gegenw\"{a}rtig implementiert und funktionsf\"{a}hig ist und was nicht)

\section{Was implementiert ist}
\index[general]{implementiert!Was ist }
\index[general]{Was implementiert ist }

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

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

\item die M\"{o}glichkeit einen oder mehrere Jobs zur gleichen Zeit auszuf\"{u}hren. 

\item zeitliche Staffelung der Jobs entsprechend ihrer Priorit\"{a}t. 

\item die Wiederherstellung einer oder mehrerer Dateien, die interaktiv
      aus der letzten Sicherung oder einer Sicherung vor einem festgelegten
      Zeitpunkt ausgew\"{a}hlt werden k\"{o}nnen.  

\item die Wiederherstellung aller Dateien eines Systems auf einer
      leeren Festplatte.  Dieser Vorgang kann bei Linux- und
      Solaris-Systemen (mit Einschr\"{a}nkungen) gr\"{o}{\ss}tenteils
      automatisch ablaufen.  N\"{a}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\"{a}ndiger
      Hilfsprogramme wie {\bf bls} und {\bf bextract}.  Unter anderem ist
      es damit m\"{o}glich, Dateien wiederherzustellen, wenn Bacula
      und/oder die \textbf{Catalog}-Datenbank nicht verf\"{u}gbar ist/sind.
      Beachten Sie aber, dass wir hierf\"{u}r den ``restore''-Befehl an der
      \textbf{Console} empfehlen und diese Hilfsprogramme nur f\"{u}r den
      Notfall vorgesehen sind.

\item die M\"{o}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}, \"{u}ber die
      dieser vollkommen gesteuert werden kann.  Die \textbf{Console} ist
      als Shell-Programm, GNOME-GUI und wxWidgets-GUI verf\"{u}gbar.
      Beachten Sie bitte, dass das GNOME-GUI gegen\"{u}ber dem
      Shell-Programm zur Zeit nur sehr wenige zus\"{a}tzliche Funktionen
      aufweist.

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

\item die Authentifizierung der Komponenten (D\"{a}monen) untereinander
      durch CRAM-MD5 Passw\"{o}rter.

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

\item leicht verst\"{a}ndliche und erweiterbare  
      \ilink{Konfigurationsdateien}{_ChapterStart40} f\"{u}r jeden einzelnen
       D\"{a}monprozess. 

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

\item Unterst\"{u}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
      \"{u}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\"{u}r die
      Wiederherstellung. 

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

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

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

\item Implementierung der Prozesse als Multithread-Programme. 

\item Programmtechnisch keine Begrenzung der L\"{a}nge der Dateinamen oder
      der Botschaften. 

\item GZIP-Komprimierung f\"{u}r jede einzelne Datei, die schon der Client
      erledigt, sofern dies vor einer \"{U}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\"{u}tzung von Autochangern \"{u}ber ein einfache Shell-Schnittstelle.
      Damit ist es m\"{o}glich, praktisch mit jedem Autoloader-Programm zu kommunizieren.
      Ein Skript f\"{u}r {\bf mtx} ist bereitgestellt. 

\item unterst\"{u}tzt Autochanger-Barcodes -- entsprechend der Barcodes
      wird das Band gekennzeichnet.

\item automatische Unterst\"{u}tzung mehrerer Autochanger-Magazine.
      Hierbei wird entweder der Barcode oder das Band gelesen.

\item Unterst\"{u}tzung von Autochangern mit mehreren Laufwerken

\item Sicherung/Wiederherstellung als raw-Backup.  Hierbei mu{\ss} die
      Wiederherstellung auf den gleichen Datentr\"{a}ger erfolgen.

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

\item Zugangskontrolllisten f\"{u}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\"{o}{\ss}er sind als 2GB.

\item Unterst\"{u}tzung von 64Bit-Systemen wie z.B. AMD64.

\item es ist m\"{o}glich, die Kommunikation der D\"{a}monen untereinander durch
      STunnel zu verschl\"{u}sseln.
 
\item Unterst\"{u}tzung von ANSI- und IBM Band-Labels.

\item Unterst\"{u}tzung von Unicode-Dateinamen (z.B. Chinesisch) auf
      Win32-Rechnern mit der Version 1.37.28 und h\"{o}her.

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

\end{itemize}

\section{Die Vorteile von Bacula gegen\"{u}ber anderen Sicherungsprogrammen}
\index[general]{Die Vorteile von Bacula gegen\"{u}ber anderen Sicherungsprogrammen}
\index[general]{Sicherungsprogrammen!Die Vorteile von Bacula gegen\"{u}ber anderen}

\begin{itemize}
\item da f\"{u}r jeden Rechner ein eigener Client existiert, k\"{o}nnen die
      Daten von Betriebssystemen aller Art gesichert und wiederhergestellt
      werden, wobei immer gew\"{a}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\"{o}glich, auf jedem Rechner, von dem Daten gesichert werden
      sollen, einen eigenen File-D\"{a}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\"{o}glicht den \"{U}berblick \"{u}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\"{a}hig.

\item durch den modularen, dabei aber einheitlichen Entwurf ist Bacula in
      hohem Ma{\ss}e skalierbar.
  
\item da Bacula D\"{a}monen auf den Client-Rechnern benutzt, ist es
      m\"{o}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\"{u}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\"{o}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\"{u}ber anderen
      vergleichbaren Produkten relativ einfach.

\item laut einem unserer Benutzer ist Bacula genau so schnell wie die
      wichtigen gro{\ss}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\"{a}che zur Verwaltung hat Bacula
      eine umfassende Shell-Schnittstelle f\"{u}r die Wartungsaufgaben, wobei der
      Administrator Werkzeuge wie z.B. ``ssh'' verwenden kann, um jeden Teil von
      Bacula von \"{u}berall (sogar von Zuhause) zu administrieren.

\item Bacula hat eine Rettungs-CD f\"{u}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\"{o}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\"{o}nnen der Rettungs-CD auf einfache Weise zus\"{a}tzliche
         Daten und Programme hinzuf\"{u}gen.

   \end{itemize}

\end{itemize}

\section{Einschr\"{a}nkungen der aktuellen Implementierung}
\index[general]{Einschr\"{a}nkungen der aktuellen Implementierung }
\index[general]{aktuelle Implementierung! Einschr\"{a}nkungen der}

\begin{itemize}
\item Pfade und Dateinamen mit mehr als 260 Zeichen werden auf
      Win32-Systemen nicht unterst\"{u}tzt.  Diese werden zwar gesichert,
      k\"{o}nnen aber nicht wiederhergestellt werden.  Durch Verwendung der
      Direktive {\bf Portable=yes} in Ihrem FileSet k\"{o}nnen Dateien mit langen
      Namen auf Unix- bzw.  Linux-Systemen wiederhergestellt werden.  Lange
      Dateinamen f\"{u}r Win32-Systeme werden in einer sp\"{a}teren Version
      implementiert sein.

\item Sollten Sie mehr als 4 Milliarden Dateieintr\"{a}ge in Ihrer
      Datenbank gespeichert haben, wird der FileID der Datenbank vermutlich
      \"{u}berlaufen.  Dies w\"{a}re eine ziemlich gro{\ss}e Datenbank, aber
      immerhin ist sie denkbar.  Irgendwann einmal wird das Feld f\"{u}r den
     FileID von Bacula von 32 auf 64 Bit erweitert werden und das Problem ist
     gel\"{o}st.  In der Zwischenzeit ist die Verwendung mehrerer Datenbanken
     eine gute L\"{o}sung.
  
\item Dateien, die nach einer Vollsicherung gel\"{o}scht wurden, werden bei
      einer Wiederherstellung eingeschlossen.

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

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

\item Bacula kann die Dateien eines einzelnen Jobs nicht von zwei oder

wiederherstellen.  Daher wird eine Wiederherstellung einige Handarbeit
erfordern, wenn sie auf mehr als ein Sicherungsger\"{a}t oder verschiedene
Medientypen speichern.

   \end{itemize}

\section{Grenzen und Beschr\"{a}nkungen des Software Design}
\index[general]{Restrictions!Design Limitations or }
\index[general]{Design Limitations or Restrictions }

\begin{itemize}
\item Namen (\textbf{Resource}-Namen, \textbf{Volume}-Names und
      \"{a}hnliche) in Baculas Konfigurationsdateien sind auf eine bestimmte
      L\"{a}nge beschr\"{a}nkt .  Momentan liegt die Grenze bei 127 Zeichen.
      Beachten Sie bitte, dass diese Einschr\"{a}nkungen nicht die Dateinamen
      betrifft, die beliebig lang sein k\"{o}nnen.

\item Durch die Nicht-Unicode Windows API, die wir auf Win32-Maschinen
      verwenden, sind wir bei Dateinamen auf 260 Zeichen beschr\"{a}nkt.  Wir
      planen dies in einer zuk\"{u}nftigen Version zu korrigieren, indem wir die
     Unicode-API verwenden.

\end{itemize}
