
Bacula 1.33 User's Guide
|
Chapter 2
|
|
 |
Introduction
|
Index
|
Getting Started
|
|
|
The Current State of Bacula
In other words, what is and what is not currently implemented
and functional.
What is Implemented
- Network backup/restore with centralized Director.
- Internal scheduler for automatic Job execution.
- Scheduling of multiple Jobs at the same time.
- You may run one Job at a time or multiple simultaneous Jobs.
- Job sequencing using priorities.
- Restore of one or more files selected interactively either for
the current backup or a backup prior to a specified time and date.
- Restore of a complete system starting from bare
metal. This is mostly automated for Linux systems and
partially automated for Solaris. See Disaster Recovery
Using Bacula.
- Listing and Restoration of files using stand-alone bls and
bextract tool programs. Among other things, this permits
extraction of files when Bacula and/or the catalog are not
available.
- Ability to recreate the catalog database by scanning backup Volumes.
- Console interface to the Director
allowing complete control. Both a shell and GNOME GUI versions of
the Console program are available. Note, the GNOME GUI program currently
offers very few additional features over the shell program.
- Verification of files previously cataloged, permitting a Tripwire like
capability (system break-in detection).
- CRAM-MD5 password authentication between each component (daemon).
- A comprehensive and extensible configuration file for each daemon.
- Catalog database facility for remembering Volumes, Pools, Jobs,
and Files backed up.
- Support for SQLite, PostgreSQL, and MySQL Catalog databases.
- User extensible queries to the SQLite, PostgreSQL and MySQL databases.
- Labeled Volumes, preventing accidental overwriting
(at least by Bacula).
- 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.
- Multi-volume saves. When a Volume is full, Bacula
automatically requests the next Volume and continues the backup.
- Pool and Volume library management
providing Volume flexibility (e.g. monthly, weekly, daily Volume sets,
Volume sets segregated by Client, ...).
- Machine independent Volume data format. Linux, Solaris, and Windows
clients can all be backed up to the same Volume if desired.
- A flexible message
handler including routing of messages from any daemon back to the
Director and automatic email reporting.
- Multi-threaded implementation.
- Mechanisms to handle arbitrarily long filenames and messages.
- GZIP compression on a file by file basis done by the Client program
if requested before network transit.
- Computation of MD5 or SHA1 signatures of the file data if requested.
- Autochanger support using a simple shell interface that can interface
to virtually any autoloader program. A script for mtx is
provided.
- Support for autochanger barcodes -- automatic tape labeling from
barcodes.
- Raw device backup.
- All Volume blocks (approx 64K bytes) contain a data checksum.
Advantages of Bacula Over Other Backup Programs
- 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.
- 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.
- Bacula handles multi-volume backups.
- A full comprehensive database of all files backed up. This permits
online viewing of files saved on any particular Volume.
- Automatic pruning of the database (removal of old records) thus
simplifying database administration.
- Any SQL database engine can be used making Bacula very flexible.
- The modular but integrated design makes Bacula very scalable.
- 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).
- Bacula has a built-in Job scheduler.
- The Volume format is documented and there are simple C programs to
read/write it.
- Bacula uses well defined (registered) TCP/IP ports -- no rpcs,
no shared memory.
- Bacula installation and configuration is relatively simple compared
to other comparable products.
- According to one user Bacula is as fast as the big major commercial
application.
- According to another user Bacula is four times as fast as a
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.
Current Implementation Weaknesses
- The graphical user interface is currently in an infant stage.
- Typical of Microsoft, not all files can always be saved on WinNT
and Win2000. 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.
- Windows Unicode filenames (e.g. Chinese) cannot be saved or restored.
- 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.
Other Items Not Implemented (but planned)
- Complete error checking on configuration files.
- Event handlers are not yet implemented (e.g. when Job terminates
do this, ...)
- File System Modules (configurable routines for saving/restoring special files).
- Data encryption between the daemons.
- Data encryption of the Volume contents.
- Backing up each file to two or more devices simultaneously.
- Job data spooling.
Temporary Limitations or Restrictions
- All three daemons (DIR, FD, SD) must be running for a Job to
run. If you use MySQL or PosgreSQL as the catalog, it must also be running.
If you use SQLite as the catalog, it will be started automatically.
This isn't very significant as most other programs have the same
limitation.
- Unicode is not yet supported.
- Supports only IPv4.
Design Limitations or Restrictions
- 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.
- There is no concept of a Pool of backup devices (i.e. if
device /dev/nst0 is busy, use /dev/nst1, ...).
- We recommend that if possible you avoid running multiple
simultaneous backup Jobs. This is because the jobs write to the
archive device at the same time and thus their blocks will be
interleaved, and as a consequence restores will be slower since
it will have to read additional data to get to all the desired
blocks. A future version will have disk spooling which will permit
the bulk of the records for each simultaneous job to be grouped
together largely avoiding the interleaving.
Introduction
|
Index
|
Getting Started
|
|
 |
|
|