git.sur5r.net Git - bacula/docs/blob - docs/manual-de/state.tex

   1 %%
   2 %%
   3
   4 \section*{The Current State of Bacula}
   5 \label{_ChapterStart2}
   6 \index[general]{Current State of Bacula }
   7 \addcontentsline{toc}{section}{Current State of Bacula}
   8
   9 In other words, what is and what is not currently implemented and functional.
  10
  11 \subsection*{What is Implemented}
  12 \index[general]{Implemented!What is }
  13 \index[general]{What is Implemented }
  14 \addcontentsline{toc}{subsection}{What is Implemented}
  15
  16 \begin{itemize}
  17 \item Network backup/restore with centralized Director.
  18 \item Internal scheduler for automatic
  19    \ilink{Job}{JobDef} execution.
  20 \item Scheduling of multiple Jobs at the same time.
  21 \item You may run one Job at a time or multiple simultaneous Jobs.
  22 \item Job sequencing using priorities.
  23 \item Restore of one or more files selected interactively either for  the
  24    current backup or a backup prior to a specified time and date.
  25 \item Restore of a complete system starting from bare  metal. This is mostly
  26    automated for Linux systems and  partially automated for Solaris. See
  27    \ilink{Disaster Recovery Using Bacula}{_ChapterStart38}. This is also
  28    reported to work on Win2K/XP systems.
  29 \item Listing and Restoration of files using stand-alone {\bf bls} and  {\bf
  30    bextract} tool programs. Among other things, this permits  extraction of files
  31    when Bacula and/or the catalog are not  available. Note, the recommended way
  32    to restore files is using  the restore command in the Console. These programs
  33    are designed  for use as a last resort.
  34 \item Ability to recreate the catalog database by scanning backup Volumes
  35    using the {\bf bscan} program.
  36 \item
  37    \ilink{Console}{UADef} interface to the Director  allowing complete
  38    control. A shell, GNOME GUI and wxWidgets GUI versions of  the Console program
  39    are available. Note, the GNOME GUI program currently  offers very few
  40    additional features over the shell program.
  41 \item Verification of files previously cataloged, permitting a Tripwire like
  42    capability (system break-in detection).
  43 \item CRAM-MD5 password authentication between each component (daemon).
  44 \item Configurable
  45    \ilink{TLS (ssl) encryption}{_ChapterStart61} between each component.
  46 \item A comprehensive and extensible
  47    \ilink{configuration file}{_ChapterStart40} for each daemon.
  48 \item Catalog database facility for remembering Volumes, Pools, Jobs,  and
  49    Files backed up.
  50 \item Support for SQLite, PostgreSQL, and MySQL Catalog databases.
  51 \item User extensible queries to the SQLite, PostgreSQL and MySQL databases.
  52 \item Labeled Volumes, preventing accidental overwriting  (at least by
  53    Bacula).
  54 \item Any number of Jobs and Clients can be backed up to a single  Volume.
  55    That is, you can backup and restore Linux, Unix, Sun, and  Windows machines to
  56    the same Volume.
  57 \item Multi-volume saves. When a Volume is full, {\bf Bacula}  automatically
  58    requests the next Volume and continues the backup.
  59 \item
  60    \ilink{Pool and Volume}{PoolResource} library management
  61    providing Volume flexibility (e.g. monthly, weekly, daily Volume sets,  Volume
  62    sets segregated by Client, ...).
  63 \item Machine independent Volume data format. Linux, Solaris, and Windows
  64    clients can all be backed up to the same Volume if desired.
  65 \item A flexible
  66    \ilink{ message}{MessageResource}  handler including routing
  67    of messages from any daemon back to the  Director and automatic email
  68    reporting.
  69 \item Multi-threaded implementation.
  70 \item Programmed to handle arbitrarily long filenames and messages.
  71 \item GZIP compression on a file by file basis done by the Client program  if
  72    requested before network transit.
  73 \item Computation of MD5 or SHA1 signatures of the file data if requested.
  74 \item Saves and restores POSIX ACLs if enabled.
  75 \item Autochanger support using a simple shell interface that can interface
  76    to virtually any autoloader program. A script for {\bf mtx} is  provided.
  77 \item Support for autochanger barcodes -- automatic tape labeling from
  78    barcodes.
  79 \item Automatic support for multiple autochanger magazines either using
  80    barcodes or by reading the tapes.
  81 \item Raw device backup/restore. Restore must be to the same device.
  82 \item All Volume blocks (approx 64K bytes) contain a data checksum.
  83 \item Access control lists for Consoles that permit restricting user access
  84    to only their data.
  85 \item Data spooling to disk during backup with subsequent write to tape from
  86    the spooled disk files. This prevents tape ``shoe shine''  during
  87    Incremental/Differential backups.
  88 \item Support for save/restore of files larger than 2GB.
  89 \item Support for 64 bit machines, e.g. amd64.
  90 \item Ability to encrypt communications between daemons using stunnel.
  91 \item Support ANSI and IBM tape labels.
  92 \item Support for Unicode filenames (e.g. Chinese) on Win32 machines.
  93
  94 \end{itemize}
  95
  96 \subsection*{Advantages of Bacula Over Other Backup Programs}
  97 \index[general]{Advantages of Bacula Over Other Backup Programs }
  98 \index[general]{Programs!Advantages of Bacula Over Other Backup }
  99 \addcontentsline{toc}{subsection}{Advantages of Bacula Over Other Backup
 100    Programs}
 101
 102 \begin{itemize}
 103 \item Since there is a client for each machine, you can backup
 104    and restore clients of any type ensuring that all attributes
 105    of files are properly saved and restored.
 106 \item It is also possible to backup clients without any client
 107    software by using NFS or Samba.  However, if possible, we
 108    recommend running a Client File daemon on each machine to be
 109    backed up.
 110 \item Bacula handles multi-volume backups.
 111 \item A full comprehensive SQL standard database of all files backed up.  This
 112    permits online viewing of files saved on any particular  Volume.
 113 \item Automatic pruning of the database (removal of old records) thus
 114    simplifying database administration.
 115 \item Any SQL database engine can be used making Bacula very flexible.
 116 \item The modular but integrated design makes Bacula very scalable.
 117 \item Since Bacula uses client file servers, any database or
 118    other application can be properly shutdown by Bacula using the
 119    native tools of the system, backed up, then restarted (all
 120    within a Bacula Job).
 121 \item Bacula has a built-in Job scheduler.
 122 \item The Volume format is documented and there are simple C programs to
 123    read/write it.
 124 \item Bacula uses well defined (IANA registered) TCP/IP ports -- no rpcs,  no
 125    shared memory.
 126 \item Bacula installation and configuration is relatively simple compared  to
 127    other comparable products.
 128 \item According to one user Bacula is as fast as the big major commercial
 129    applications.
 130 \item According to another user Bacula is four times as fast as  another
 131    commercial application, probably because that application  stores its catalog
 132    information in a large number of individual  files rather than an SQL database
 133    as Bacula does.
 134 \item Aside from a GUI administrative interface, Bacula has a
 135    comprehensive shell administrative interface, which allows the
 136    administrator to use tools such as ssh to administrate any part of
 137    Bacula from anywhere (even from home).
 138
 139 \item Bacula has a Rescue CD for Linux systems with the following features:
 140    \begin{itemize}
 141    \item You build it on your own system from scratch with one simple  command:
 142       make -- well, then make burn.
 143    \item It uses your kernel
 144    \item It captures your current disk parameters and builds scripts that  allow
 145       you to automatically repartition a disk and format it to  put it back to what
 146       you had before.
 147    \item It has a script that will restart your networking (with the right  IP
 148       address)
 149    \item It has a script to automatically mount your hard disks.
 150    \item It has a full Bacula FD statically linked
 151    \item You can easily add additional data/programs, ... to the disk.
 152    \end{itemize}
 153
 154 \end{itemize}
 155
 156 \subsection*{Current Implementation Restrictions}
 157 \index[general]{Current Implementation Restrictions }
 158 \index[general]{Restrictions!Current Implementation }
 159 \addcontentsline{toc}{subsection}{Current Implementation Restrictions}
 160
 161 \begin{itemize}
 162 \item Typical of Microsoft, not all files can always be saved on WinNT,  Win2K
 163    and WinXP when they are in use by another program.  Anyone knowing the magic
 164    incantations, please step  forward. The files that are skipped seem to be in
 165    exclusive use  by some other process, and don't appear to be too important.
 166 \item If you have over 4 billion file entries stored in your database,  the
 167    database FileId is likely to overflow. This is a monster database,  but still
 168    possible. At some point, Bacula's FileId fields will be  upgraded from 32 bits
 169    to 64 bits and this problem will go away. In  the mean time, a good workaround
 170    is to use multiple databases.
 171 \item Files deleted after a Full save will be included in a restoration.
 172 \item Event handlers are not yet implemented (e.g. when Job terminates  do
 173    this, ...)
 174 \item File System Modules (configurable routines for saving/restoring special
 175    files).
 176 \item Data encryption of the Volume contents.
 177 \item Bacula cannot automatically restore files for a single Job
 178    from two or more different storage devices or different media types.
 179    That is, if you use more than one storage device or media type to
 180    backup a single job, the restore process will require some manual
 181    intervention.
 182 \item There is no concept of a Pool of backup devices (i.e. if  device
 183    /dev/nst0 is busy, use /dev/nst1, ...).
 184    \end{itemize}
 185
 186 \subsection*{Design Limitations or Restrictions}
 187 \index[general]{Restrictions!Design Limitations or }
 188 \index[general]{Design Limitations or Restrictions }
 189 \addcontentsline{toc}{subsection}{Design Limitations or Restrictions}
 190
 191 \begin{itemize}
 192 \item Names (resource names, Volume names, and such) defined in Bacula
 193    configuration files are limited to a fixed number of characters.  Currently
 194    the limit is defined as 127 characters. Note, this does  not apply to
 195    filenames, which may be arbitrarily long.
 196 \end{itemize}