Add more print info to send

[bacula/docs] / docs / manuals / de / old / concepts / state.tex

%%
%%

\chapter{Baculas Stand}
\label{StateChapter}
\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 Job-Steuerung
   \begin{itemize}
   \item Sicherung/Wiederherstellung im Netzwerkes unter der Regie eines
      zentralen 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 \ilink{Console}{UADef} Programm als Benutzer-Schnittstelle zum Director-Dienst.
      Eine shell-, Qt4-GUI-, GNOME-GUI und wxWidgets-Version sind derzeit verf\"{u}gbar.
      Die Qt4-Version der Console, Bacula Administration Tool, kurz bat genannt, bietet
      viele zus\"{a}tzliche Funktionen gegen\"{u}ber der shell-Version.
   \end{itemize}

\item Sicherheit
   \begin{itemize}
   \item die Verifikation der Dateien, die zuvor in das
      Catalog-Verzeichnis aufgenommen wurden, erlaubt eine
      Funktionalit\"{a}t wie sie das Programm Tripwire hat (Intrusion
      Detection).
   \item die Authentifizierung der Komponenten (Dienste) untereinander
      durch CRAM-MD5 Passw\"{o}rter.
   \item eine konfigurierbare \ilink{TLS (ssl)-Verschl\"{u}sselung }{CommEncryption}
      zwischen den einzelnen Komponenten.
   \item bei Bedarf die Berechnung von MD5 oder SHA1 Signaturen der
      Dateidaten.
   \end{itemize}

\item Wiederherstellungs-Funktionen
   \begin{itemize}
   \item leicht verst\"{a}ndliche und erweiterbare  
      \ilink{Konfigurationsdateien}{_ChapterStart40} f\"{u}r jeden einzelnen
       D\"{a}monprozess. 
   \end{itemize}

\item SQL-Datenbank
   \begin{itemize}
   \item eine Catalog-Datenbank zur Aufzeichnung der Volumes,
      Pools, Jobs und der Informationen \"{u}ber die gesicherten
      Dateien.
   \item Unterst\"{u}tzung von SQLite, PostgreSQL und
      MySQL als Catalog-Datenbanksystemen. 
   \item vom Benutzer erweiterbare Datenbankabfragen an SQLite-,
      PostgreSQL und MySQL-Datenbanksysteme. 
   \end{itemize}

\item fortschrittliches Volume- und Pool-Management
   \begin{itemize}
   \item gekennzeichnete \textbf{Volumes}, die ein versehentliches
      \"{u}berschreiben (zumindest durch Bacula) verhindern.  
   \item eine beliebige Anzahl verschiedener Jobs und
      Clients kann auf ein einzelnes Volume gesichert werden. Dies
      bedeutet, dass von Linux-, Unix-, Sun- und Windows-Rechnern auf das gleiche
      Volume gesichert werden kann. Das gleiche gilt f\"{u}r die
      Wiederherstellung. 
   \item eine Sicherung kann sich \"{u}ber mehrere Volumes erstrecken. Sobald ein
      Volume voll ist, fordert Bacula automatisch das n\"{a}chste
      Volume an und setzt die Sicherung fort. 
   \item die Verwaltung von \ilink{Pools
      und Volumes}{PoolResource} erlaubt einen
      flexiblen Umgang mit Volumes (z.B. Gruppen von
      Volumes f\"{u}r die monatliche, w\"{o}chentliche,
      t\"{a}gliche Sicherung, Gruppen von Volumes f\"{u}r
      bestimmte Clients).
   \item das Datenformat der Volumes ist systemunabh\"{a}ngig. Bei Bedarf
      k\"{o}nnen die Daten von Linux-, Solaris- und Windows-Clients in
     dasselbe Volumen gespeichert werden.
   \item jede Bacula-Version kann jedes, mit einer kleineren Version, erstellte Volume lesen.
   \item ein konfigurierbares \ilink{Messages}{MessagesChapter}-Handling.
      Dazu geh\"{o}rt der Versand von Botschaften aller D\"{a}mon-Prozesse
      an den Director-Dienst und die automatische Benachrichtigung des
      Benutzers \"{u}ber das Mailsystem.
   \item Zwischenspeicherung der zu sichernden Daten auf der Festplatte (Spooling) und
      fortlaufende Beschreibung des Bandes mit den zwischengespeicherten Daten 
      verhindert den ``Schoe-Shine-Effekt'' bei einer inkrementellen oder
      differentiellen Sicherung.
   \end{itemize}

\item Unterst\"{u}tzung f\"{u}r fast alle Speicher-Ger\"{a}te
    \begin{itemize}
   \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 Volumes enth\"{a}lt die
      Pr\"{u}fsumme der Daten.
   \item Migration, die M\"{o}glichkeit gesicherte Daten von einem Pool oder Volume,
   in einen anderen Pool oder auf ein anderes Volume zu verschieben.
  \item schreibbare DVD k\"{o}nnen als Backup-Medium verwendet werden
   \end{itemize}

\item Unterst\"{u}tzung verschiedener Bertiebssysteme
   \begin{itemize} 
   \item Programmtechnisch keine Begrenzung der L\"{a}nge der Dateinamen oder
      der Nachrichten. Auf Win32 ist die L\"{a}nge der Dateinamen/Pfade auf 64k begrenzt.
   \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 POSIX ACLs werden - wenn aktiviert -  unter den meisten Betriebssystemen gesichert und wiederhergestellt.
   \item Zugangskontrolllisten f\"{u}r Consolen, die dem Benutzer einen Zugang nur zu den eigenen Daten erlauben.  
   \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 Unterst\"{u}tzung von ANSI- und IBM Band-Labels.
   \item Unterst\"{u}tzung von Unicode-Dateinamen (z.B. Chinesisch) auf
      Win32-Rechnern mit der Bacula-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}


\item Verschiedenes
   \begin{itemize}
   \item Implementierung der Prozesse als Multithread-Programme. 
   \item leicht verst\"{a}ndliche und erweiterbare
   \ilink{Konfigurationsdateien}{DirectorChapter} f\"{u}r jeden einzelnen
   D\"{a}monprozess.
   \end{itemize}
\end{itemize}

\section{Vorteile gegen\"{u}ber anderen Sicherungsprogrammen}
\index[general]{Vorteile gegen\"{u}ber anderen Sicherungsprogrammen}
\index[general]{Sicherungsprogrammen!Vorteile 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 lassen.
\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. Derzeit werden MySQL, PostgreSQL und SQLite unterst\"{u}tzt.
\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 Anwendungen durch Bacula mit
      systemeigenen Befehlen zu stoppen und nach der Sicherung die
     entsprechenden Anwendungen wieder zu starten.  Dies alles kann aus einem
     einzigen Bacula-Job heraus geschehen.
\item Bacula hat ein eingebauten Zeitplaner f\"{u}r die
      Sicherungsjobs.
\item Das Format der 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 hohe Geschwindigkeit durch das Speichern der Datei-Informationen
      in einer SQL-Datenbank anstatt in einzelnen Dateien auf der Festplatte.
\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 ein Bacula-Client 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 Sollten Sie mehr als 4 Milliarden Dateieintr\"{a}ge in Ihrer
      Datenbank gespeichert haben, wird die FileID der Datenbank vermutlich
      \"{u}berlaufen.  Dies w\"{a}re eine ziemlich gro{\ss}e Datenbank, aber
      immerhin ist sie denkbar.  Allerdings k\"{o}nnen Sie die FileID auf 64 Bit
      erweitern (ab Bacula-Version 1.39) und das Problem ist gel\"{o}st,
      dies muss aber von Hand geschehen.
\item Dateien, die nach einer Vollsicherung gel\"{o}scht wurden, werden bei
      einer Wiederherstellung eingeschlossen. Es wird momentan daran gearbeitet,
      dies zu verhindern.
\item differentielle und inkrementelle Sicherungen basieren auf den Zeitstempeln
      der Dateien. Das bedeutet, dass falls Sie nach einen vollst\"{a}ndigen Sicherung
      Verzeichnisse oder Dateien auf dem Client in das FileSet verschieben,
      diese beim n\"{a}chsten inkrementellen Backup nicht gesichert werden.
      Um das Sichern der Daten zu erzwingen, m\"{u}ssen Sie nach dem verschieben
      die Timestamps der Daten aktualisieren, damit Bacula sie als neu erkennt.
\item Datei-System-Module fehlen (dies w\"{a}ren konfigurierbare Routinen,
      um spezielle Dateien zu sichern/wiederherzustellen, das kann aber \"{u}ber RunScripts gel\"{o}st werden).
\item Bacula kann zwei verschiedene Jobs nicht im selben Restore wiederherstellen,
      wenn diese Backup-Jobs gleichzeitig gelaufen sind. Die Ausnahme ist, dass Sie
      Spooling aktiviert haben und die Jobs nach dem spoolen nacheinander auf das
      Volume geschrieben wurden. Es ist also nicht m\"{o}glich, die verschachtelten
      Bl\"{o}cke auf dem Volume in einem Job zu trennen.
\item generell kann Bacula jedes Backup von jedem Client auch auf einem anderen
      Client wiederherstellen. Allerdings gibt es, wenn die Architektur der Rechner
      unterschiedlich ist (z.B. 32Bit zu 64Bit oder Windows zu Unix)
      einige Einschr\"{a}nkungen. Zum Beispiel kennt Linux/Unix keine Solaris door-Dateien.
      Zudem gibt es Hinweise, dass sich Zlib-Kompremierte Dateien von 64Bit-Systemen
      nicht immer korrekt auf 32Bit-Systemen entpacken lassen.
   \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 (Resource-Namen, 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.

\end{itemize}