
#include "bacula_template.inc" title="Features" num=2

<h1>The Current State of Bacula</h1>
In other words, what is and what is not currently implemented
and functional.
<h2>What is Implemented</h2>
<ul>
  <li>Network backup/restore with centralized Director.</li>
  <li>Internal scheduler for automatic <a href="bacula.html#JobDef">Job</a> execution.</li>
  <li>Scheduling of multiple Jobs at the same time.</li>
  <li>You may run one Job at a time or multiple simultaneous Jobs.</li>
  <li>Job sequencing using priorities.</li>
  <li>Restore of one or more files selected interactively either for
      the current backup or a backup prior to a specified time and date.</li>
  <li>Restore of a complete system starting from bare
      metal. This is mostly automated for Linux systems and
      partially automated for Solaris. See <a href="rescue.html">Disaster Recovery
      Using Bacula</a>. This is also reported to work on Win2K/XP systems.
      </li>
  <li>Listing and Restoration of files using stand-alone <b>bls</b> and
      <b>bextract</b> tool programs.  Among other things, this permits
      extraction of files when Bacula and/or the catalog are not
      available. Note, the recommended way to restore files is using
      the restore command in the Console. These programs are designed
      for use as a last resort. </li>
  <li>Ability to recreate the catalog database by scanning backup Volumes 
      using the <b>bscan</b> program.</li>
  <li><a href="bacula.html#UADef">Console</a> interface to the <a href="director.html">Director</a>
       allowing complete control. A shell, GNOME GUI and wxWidgets GUI versions of
       the Console program are available. Note, the GNOME GUI program currently
       offers very few additional features over the shell program. </li>
  <li>Verification of files previously cataloged, permitting a Tripwire like
      capability (system break-in detection).</li>
  <li>CRAM-MD5 password authentication between each component (daemon).</li>
  <li>A comprehensive and extensible <a href="dirdconf.html#ConfigFile">configuration file</a> for each daemon.</li>
  <li>Catalog database facility for remembering Volumes, Pools, Jobs,
      and Files backed up.</li> 
  <li>Support for SQLite, PostgreSQL, and MySQL Catalog databases.</li> 
  <li>User extensible queries to the SQLite, PostgreSQL and MySQL databases.</li> 
  <li>Labeled Volumes, preventing accidental overwriting 
      (at least by Bacula).</li> 
  <li>Any number of Jobs and Clients can be backed up to a single
      Volume. That is, you can backup and restore Linux, Unix, Sun, and  
      Windows machines to the same Volume.</li>
  <li>Multi-volume saves.  When a Volume is full, <b>Bacula</b>
      automatically requests the next Volume and continues the backup.</li>
  <li><a href="dirdconf.html#PoolResource">Pool and Volume</a> library management
      providing Volume flexibility (e.g. monthly, weekly, daily Volume sets,
      Volume sets segregated by Client, ...). </li> 
  <li>Machine independent Volume data format. Linux, Solaris, and Windows
      clients can all be backed up to the same Volume if desired. </li> 
  <li>A flexible <a href="messagesres.html#MessageResource"> message</a> 
      handler including routing of messages from any daemon back to the
      Director and automatic email reporting.</li>
  <li>Multi-threaded implementation.</li>
  <li>Programmed to handle arbitrarily long filenames and messages.</li>
  <li>GZIP compression on a file by file basis done by the Client program
      if requested before network transit.</li>
  <li>Computation of MD5 or SHA1 signatures of the file data if requested.</li>
  <li>Saves and restores POSIX ACLs if enabled.</li>         
  <li>Autochanger support using a simple shell interface that can interface
      to virtually any autoloader program. A script for <b>mtx</b> is
      provided.</li>
  <li>Support for autochanger barcodes -- automatic tape labeling from
      barcodes.</li>
  <li>Automatic support for multiple autochanger magazines either using barcodes
      or by reading the tapes.</li>
  <li>Raw device backup/restore. Restore must be to the same device. </li>
  <li>All Volume blocks (approx 64K bytes) contain a data checksum.</li>
  <li>Access control lists for Consoles that permit restricting user 
      access to only their data.</li>
  <li>Data spooling to disk during backup with subsequent write to tape
      from the spooled disk files. This prevents tape &quot;shoe shine&quot;
      during Incremental/Differential backups.</li>
  <li>Support for save/restore of files larger than 2GB.</li>
  <li>Support for 64 bit machines, e.g. amd64.</li>
  <li>Ability to encrypt communications between daemons using stunnel.</li>
</ul>

<h2>Advantages of Bacula Over Other Backup Programs</h2>
<ul>
  <li>Since there is a client for each machine, you can backup
      and restore clients of any type ensuring that all attributes of
      files are properly saved and restored.</li>
  <li>It is also possible to backup clients without any client software by
      using NFS or Samba. However, if possible, we recommend running
      a Client File daemon on each machine to be backed up.</li>
  <li>Bacula handles multi-volume backups.</li>
  <li>A full comprehensive SQL standard database of all files backed up.
      This permits online viewing of files saved on any particular
      Volume.</li>
  <li>Automatic pruning of the database (removal of old records) thus
      simplifying database administration.</li>
  <li>Any SQL database engine can be used making Bacula very flexible.</li>
  <li>The modular but integrated design makes Bacula very scalable.</li>
  <li>Since Bacula uses client file servers, any database or other 
      application can be properly shutdown by Bacula using the native 
      tools of the system, backed up, then restarted (all within a 
      Bacula Job).</li>
  <li>Bacula has a built-in Job scheduler.</li>
  <li>The Volume format is documented and there are simple C programs to
      read/write it.</li>
  <li>Bacula uses well defined (registered) TCP/IP ports -- no rpcs, 
      no shared memory.</li>
  <li>Bacula installation and configuration is relatively simple compared 
      to other comparable products.</li>
  <li>According to one user Bacula is as fast as the big major commercial
      application.</li>
  <li>According to another user Bacula is four times as fast as
      another commercial application, probably because that application
      stores its catalog information in a large number of individual
      files rather than an SQL database as Bacula does.</li>
</ul>


<h2>Current Implementation Restrictions</h2>
<ul>
  <li>Typical of Microsoft, not all files can always be saved on WinNT,
      Win2K and WinXP when they are in use by another program.
      Anyone knowing the magic incantations please step
      forward.  The files that are skipped seem to be in exclusive use
      by some other process, and don't appear to be too important.
      </li>
  <li>Unicode filenames (e.g. Chinese) cannot be saved or restored.
      This appears to be a problem
      only on Mac machines that are using remote mounted Windows
      volumes. </li>
  <li>If you have over 4 billion file entries stored in your database,
      the database FileId is likely to overflow. This is a monster database,
      but still possible. At some point, Bacula's FileId fields will be 
      upgraded from 32 bits to 64 bits and this problem will go away. In
      the mean time, a good workaround is to use multiple databases.
      </li>
  <li>Files deleted after a Full save will be included in a restoration.</li>
  <li>Event handlers are not yet implemented (e.g. when Job terminates
      do this, ...)</li>
  <li>File System Modules (configurable routines for saving/restoring special files).</li>
  <li>Data encryption of the Volume contents.</li>
  <li>Bacula cannot backup or restore files from two or more different
      storage devices or different media types.</li>
  <li>There is no concept of a Pool of backup devices (i.e. if 
      device /dev/nst0 is busy, use /dev/nst1, ...).</li>
</ul>

<h2>Design Limitations or Restrictions</h2>
<ul>
  <li>Names (resource names, Volume names, and such) defined in Bacula
      configuration files are limited to a fixed number of characters.
      Currently the limit is defined as 127 characters.  Note, this does
      not apply to filenames, which may be arbitrarily long.</li>
</ul>

<page_prev name="Introduction" url="bacula.html">
<page_next name="Getting Started" url="quickstart.html">
