
<h2>Bacula Features</h2>

DO NOT USE!

THIS FILE IS OUT OF DATE AND NO LONGER USED IN THE
MANUAL. HOWEVER, IT IS KEPT FOR HISTORIC REASONS
(ONE OF MY FIRST LIST OF IDEAS OF WHAT BACULA SHOULD BE).


<ul>

<li>The Storage module handles the storage media (floppy,
  tapes of all types, disk, ...). *It writes the data in a
  machine independent manner and such that the data will always
  be recoverable -- we call this <b>DataImmortality</b>.

<li>All data backed up by Bacula will have <b>DataImmortatilty</b>
which means that it can be restored at any future time. The 
current version of Bacula will always be able to read volumes any
prior version of Bacula has written (not yet true!).

<li>*Can have multiple Director, File, Catalog, and Storage modules.
Normally, only a single Director, a single File, and a single
Catalog service run on any one machine.

<li>The File Services module is machine dependent and provides file services
for machines for backup, restore, and archiving.

<li>The Catalog module handles the file indexes and the media
database. It is normally a third party SQL engine such as MySQL or
PostgreSQL.


<li>Virtually everything is configurable through a text file
  or a GUI that modifies the text file.  The GUI will most
  likely be a set of CGI based programs that work through
  the Administrator's Browser.

<li>*Data can be encrypted and or compressed at any
point between File, Director, and Storage modules,
using
  any of a number of standard encryption/compression techniques.

<li>The File daemon on request can maintain an MD5 checksum of the file
  information and can detect changes. Thus the system may
  also serve as to detect changed files similar to the
  &quot;Tripwire&quot; capability. For more details see the
  Verify command.
  
<li>*If a Storage daemon is running on a remote machine, you can
schedule an <b>Update</b> function from one machine to another.
Thus the Director can request the File daemon to perform an
Update of a FileSet to a specific Storage daemon located on
another machine. In this mode, any files in the FileSet that
do not exist on the remote system and any files that have changed
will be transferred to the remote system. This function is 
equivalent to <b>rdist</b>.


<li>*There are various user configurable notification events.  A
  user script can get control for notification. 

  For example, a script can get control with a list of all files
  that have been changed, or backed up, or a subset of those
  files notification only if the contents of the file changes,
  only if the access time changes, ...  as in Tripwire.

  The administrator might want be notified if only one copy
  of a particular file exists on the backup tapes, or he
  might want to be notified if there are more than 100 copies
  of a file, ...

<li>The administrator should be able to easily determine a number
  of things:
  <ul>
  <li>*which files are not currently backed up.
  <li>*how many tapes are necessary to do a full backup at any point
    in time.
  <li>how many tapes are currently have data on them. 
  <li>The number of files and size, ... of data saved on each tape
      (if this feature is turned on).
  </ul>
  
<li>*There should be a simple way of consolidating tapes (i.e. if a
  tape only contains one or two files for which there is no other
  backup, perhaps the administrator would want to copy those
  files to another tape and free up the original tape for reuse).

<li>*The administrator should be able to examine the state of his
  system and backup for any period of time.  If the data is
  archived (i.e. the browse time is one month and he wants to see
  one year ago), that information should be easily obtained.

<li>Bacula keeps track of a lot of things: total tape errors, tape drive
  errors, tape volume errors, number of times tape mounted,
  writes to tape, mounts on drive, ...
 
<li>*Using Media Pools, the Administrator may disable saving
the File information to the Catalog. Thus Bacula
becomes a simple backup/restore tool. In this mode an ordinary
file is kept containing the backup information (date, level, 
...) so that incremental backups can still be done 
automatically.

<li>*Bacula should be able to do raw partition backup/restore.

<li>*Any usable part of a bad tape can be recovered.

<li>Data verification using checksums.

<li>Unattended backups.

<li>Handles all types of files (links, named pipes, ...) with all
  modes and options (not yet fully implemented).

<li>Multiple volume backup.

<li>Media Volume labels.

<li>Log all important events.

<li>*If appropriate authorizations are given, a user should be able to
  restore his own files.

<li>*The administrator may want multiple copies of a file to be
  maintained on various backup media.   

<li>The administrator may want to force multiple copies of a file
  on different volumes.
  
<li>*To reduce the enormous volume of identical files across
multiple machines, Bacula will have a way of specifying 
that a certain set of files are to be backed up only once no
matter how many times this file is duplicated on other machines.

<li>All media are labeled</li>

<li>The basic unit of data on a Volume is a block
   (there are records within blocks).  Recovery from a damaged
   tape volume can be done at the block level preventing total
   loss of information if a tape is bad.</li>
  
<li>Each block has a 32 bit checksum to ensure data integrity.</li>
  
<li>*Compression and encryption are done at the file level.</li>

</ul>
