## Bacula Features

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).

- 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 DataImmortality.
- All data backed up by Bacula will have DataImmortatilty 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!).
- *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.
- The File Services module is machine dependent and provides file services for machines for backup, restore, and archiving.
- The Catalog module handles the file indexes and the media database. It is normally a third party SQL engine such as MySQL or PostgreSQL.
- 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.
- *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.
- 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 "Tripwire" capability. For more details see the Verify command.
- *If a Storage daemon is running on a remote machine, you can schedule an Update 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 rdist.
- *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, ...
- The administrator should be able to easily determine a number of things:
  - *which files are not currently backed up.
  - *how many tapes are necessary to do a full backup at any point in time.
  - how many tapes are currently have data on them.
  - The number of files and size, ... of data saved on each tape (if this feature is turned on).
- *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).
- *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.
- 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, ...
- *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.
- *Bacula should be able to do raw partition backup/restore.
- *Any usable part of a bad tape can be recovered.
- Data verification using checksums.
- Unattended backups.
- Handles all types of files (links, named pipes, ...) with all modes and options (not yet fully implemented).
- Multiple volume backup.
- Media Volume labels.
- Log all important events.
- *If appropriate authorizations are given, a user should be able to restore his own files.
- *The administrator may want multiple copies of a file to be maintained on various backup media.
- The administrator may want to force multiple copies of a file on different volumes.
- *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.
- All media are labeled
- 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.
- Each block has a 32 bit checksum to ensure data integrity.
- *Compression and encryption are done at the file level.