--- /dev/null
+%%
+%%
+
+\chapter{The Current State of Bacula}
+\label{StateChapter}
+\index[general]{Current State of Bacula }
+
+In other words, what is and what is not currently implemented and functional.
+
+\section{What is Implemented}
+\index[general]{Implemented!What}
+\index[general]{What is Implemented}
+
+\begin{itemize}
+\item Job Control
+ \begin{itemize}
+ \item Network backup/restore with centralized Director.
+ \item Internal scheduler for automatic
+ \ilink{Job}{JobDef} execution.
+ \item Scheduling of multiple Jobs at the same time.
+ \item You may run one Job at a time or multiple simultaneous Jobs
+ (sometimes called multiplexing).
+ \item Job sequencing using priorities.
+ \item \ilink{Console}{UADef} interface to the Director allowing complete
+ control. A shell, Qt4 GUI, GNOME GUI and wxWidgets GUI versions of
+ the Console program are available. Note, the Qt4 GUI program called
+ the Bacula Administration tool or bat, offers many additional
+ features over the shell program.
+ \end{itemize}
+
+\item Security
+ \begin{itemize}
+ \item Verification of files previously cataloged, permitting a Tripwire like
+ capability (system break-in detection).
+ \item CRAM-MD5 password authentication between each component (daemon).
+ \item Configurable
+ \ilink{TLS (SSL) communications encryption}{CommEncryption} between each
+ component.
+ \item Configurable
+ \ilink{Data (on Volume) encryption}{DataEncryption}
+ on a Client by Client basis.
+ \item Computation of MD5 or SHA1 signatures of the file data if requested.
+ \end{itemize}
+
+
+\item Restore Features
+ \begin{itemize}
+ \item Restore of one or more files selected interactively either for the
+ current backup or a backup prior to a specified time and date.
+ \item Restore of a complete system starting from bare metal. This is mostly
+ automated for Linux systems and partially automated for Solaris. See
+ \ilink{Disaster Recovery Using Bacula}{RescueChapter}. This is also
+ reported to work on Win2K/XP systems.
+ \item Listing and Restoration of files using stand-alone {\bf bls} and {\bf
+ bextract} 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.
+ \item Ability to restore the catalog database rapidly by using bootstrap
+ files (previously saved).
+ \item Ability to recreate the catalog database by scanning backup Volumes
+ using the {\bf bscan} program.
+ \end{itemize}
+
+\item SQL Catalog
+ \begin{itemize}
+ \item Catalog database facility for remembering Volumes, Pools, Jobs, and
+ Files backed up.
+ \item Support for MySQL, PostgreSQL, and SQLite Catalog databases.
+ \item User extensible queries to the MySQL, PostgreSQL and SQLite databases.
+ \end{itemize}
+
+\item Advanced Volume and Pool Management
+ \begin{itemize}
+ \item Labeled Volumes, preventing accidental overwriting (at least by
+ Bacula).
+ \item 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.
+ \item Multi-volume saves. When a Volume is full, {\bf Bacula} automatically
+ requests the next Volume and continues the backup.
+ \item
+ \ilink{Pool and Volume}{PoolResource} library management
+ providing Volume flexibility (e.g. monthly, weekly, daily Volume sets, Volume
+ sets segregated by Client, ...).
+ \item Machine independent Volume data format. Linux, Solaris, and Windows
+ clients can all be backed up to the same Volume if desired.
+ \item The Volume data format is upwards compatible so that old Volumes
+ can always be read.
+ \item A flexible
+ \ilink{message}{MessagesChapter} handler including routing
+ of messages from any daemon back to the Director and automatic email
+ reporting.
+ \item Data spooling to disk during backup with subsequent write to tape from
+ the spooled disk files. This prevents tape "shoe shine" during
+ Incremental/Differential backups.
+ \end{itemize}
+
+\item Advanced Support for most Storage Devices
+ \begin{itemize}
+ \item Autochanger support using a simple shell interface that can interface
+ to virtually any autoloader program. A script for {\bf mtx} is provided.
+ \item Support for autochanger barcodes -- automatic tape labeling from
+ barcodes.
+ \item Automatic support for multiple autochanger magazines either using
+ barcodes or by reading the tapes.
+ \item Support for multiple drive autochangers.
+ \item Raw device backup/restore. Restore must be to the same device.
+ \item All Volume blocks (approximately 64K bytes) contain a data checksum.
+ \item Migration support -- move data from one Pool to another or
+ one Volume to another.
+ \item Supports writing to DVD.
+ \end{itemize}
+
+\item Multi-Operating System Support
+ \begin{itemize}
+ \item Programmed to handle arbitrarily long filenames and messages.
+ \item GZIP compression on a file by file basis done by the Client program if
+ requested before network transit.
+ \item Saves and restores POSIX ACLs on most OSes if enabled.
+ \item Access control lists for Consoles that permit restricting user access
+ to only their data.
+ \item Support for save/restore of files larger than 2GB.
+ \item Support for 64 bit machines, e.g. amd64, Sparc.
+ \item Support ANSI and IBM tape labels.
+ \item Support for Unicode filenames (e.g. Chinese) on Win32 machines on
+ version 1.37.28 and greater.
+ \item Consistent backup of open files on Win32 systems (WinXP, Win2003,
+ and Vista)
+ but not Win2000, using Volume Shadow Copy (VSS).
+ \item Support for path/filename lengths of up to 64K on Win32 machines
+ (unlimited on Unix/Linux machines).
+ \end{itemize}
+
+\item Miscellaneous
+ \begin{itemize}
+ \item Multi-threaded implementation.
+ \item A comprehensive and extensible
+ \ilink{configuration file}{DirectorChapter} for each daemon.
+ \end{itemize}
+\end{itemize}
+
+\section{Advantages Over Other Backup Programs}
+\index[general]{Advantages of Bacula Over Other Backup Programs }
+\index[general]{Programs!Advantages of Bacula Over Other Backup }
+
+\begin{itemize}
+\item 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.
+\item 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.
+\item Bacula handles multi-volume backups.
+\item A full comprehensive SQL standard database of all files backed up. This
+ permits online viewing of files saved on any particular Volume.
+\item Automatic pruning of the database (removal of old records) thus
+ simplifying database administration.
+\item Any SQL database engine can be used making Bacula very flexible.
+ Drivers currently exist for MySQL, PostgreSQL, and SQLite.
+\item The modular but integrated design makes Bacula very scalable.
+\item 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).
+\item Bacula has a built-in Job scheduler.
+\item The Volume format is documented and there are simple C programs to
+ read/write it.
+\item Bacula uses well defined (IANA registered) TCP/IP ports -- no rpcs, no
+ shared memory.
+\item Bacula installation and configuration is relatively simple compared to
+ other comparable products.
+\item According to one user Bacula is as fast as the big major commercial
+ applications.
+\item 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.
+\item Aside from several GUI administrative interfaces, Bacula has a
+ comprehensive shell administrative interface, which allows the
+ administrator to use tools such as ssh to administrate any part of
+ Bacula from anywhere (even from home).
+\item Bacula has a Rescue CD for Linux systems with the following features:
+ \begin{itemize}
+ \item You build it on your own system from scratch with one simple command:
+ make -- well, then make burn.
+ \item It uses your kernel
+ \item It captures your current disk parameters and builds scripts that allow
+ you to automatically repartition a disk and format it to put it back to what
+ you had before.
+ \item It has a script that will restart your networking (with the right IP
+ address)
+ \item It has a script to automatically mount your hard disks.
+ \item It has a full Bacula FD statically linked
+ \item You can easily add additional data/programs, ... to the disk.
+ \end{itemize}
+
+\end{itemize}
+
+\section{Current Implementation Restrictions}
+\index[general]{Current Implementation Restrictions }
+\index[general]{Restrictions!Current Implementation }
+
+\begin{itemize}
+\item It is very unusual to attempt to restore two Jobs
+ that ran simultaneously in a single restore, but if
+ you do, please be aware that unless you had
+ data spooling turned on and the spool file held the full
+ contents of both Jobs during the backup, the restore will not
+ work correctly. In other terms, Bacula cannot restore
+ two jobs in the same restore if the Jobs' data blocks were
+ intermixed on the backup medium. The problem is resolved by
+ simply doing two restores, one for each Job.
+\item Bacula can generally restore any backup made from one client
+ to any other client. However, if the architecture is significantly
+ different (i.e. 32 bit architecture to 64 bit or Win32 to Unix),
+ some restrictions may apply (e.g. Solaris door files do not exist
+ on other Unix/Linux machines; there are reports that Zlib compression
+ written with 64 bit machines does not always read correctly on a 32 bit
+ machine).
+\end{itemize}
+
+\section{Design Limitations or Restrictions}
+\index[general]{Restrictions!Design Limitations or }
+\index[general]{Design Limitations or Restrictions }
+
+\begin{itemize}
+\item 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.
+\item Command line input to some of the stand alone tools -- e.g. btape,
+ bconsole is restricted to several hundred characters maximum.
+\end{itemize}
+
+\section{Items to Note}
+\index[general]{Items to Note}
+\begin{itemize}
+\item Bacula's Differential and Incremental \textsl{normal} backups are based
+ on time stamps. Consequently, if you move files into an existing directory
+ or move a whole directory into the backup fileset after a Full backup, those
+ files will probably not be backed up by an Incremental save because they will
+ have old dates. This problem is corrected by using Accurate mode backups
+ or by explicitly updating the date/time stamp on all moved files.
+\item In older versions of Bacula ($<=$ 3.0.x), if you have over 4 billion file
+ entries stored in your database, the database FileId is likely to overflow.
+\item In non \textsl{Accurate} mode, files deleted after a Full save will be
+ included in a restoration. This is typical for most similar backup programs.
+\end{itemize}
projects / bacula / docs / blobdiff