4 \chapter{The Current State of Bacula}
6 \index[general]{Current State of Bacula }
8 In other words, what is and what is not currently implemented and functional.
10 \section{What is Implemented}
11 \index[general]{Implemented!What}
12 \index[general]{What is Implemented}
17 \item Network backup/restore with centralized Director.
18 \item Internal scheduler for automatic
19 \ilink{Job}{JobDef} execution.
20 \item Scheduling of multiple Jobs at the same time.
21 \item You may run one Job at a time or multiple simultaneous Jobs.
22 \item Job sequencing using priorities.
23 \item \ilink{Console}{UADef} interface to the Director allowing complete
24 control. A shell, GNOME GUI and wxWidgets GUI versions of the Console program
25 are available. Note, the GNOME GUI program currently offers very few
26 additional features over the shell program.
31 \item Verification of files previously cataloged, permitting a Tripwire like
32 capability (system break-in detection).
33 \item CRAM-MD5 password authentication between each component (daemon).
35 \ilink{TLS (SSL) communications encryption}{CommEncryption} between each component.
37 \ilink{Data (on Volume) encryption}{DataEncryption}
38 on a Client by Client basis.
39 \item Computation of MD5 or SHA1 signatures of the file data if requested.
43 \item Restore Features
45 \item Restore of one or more files selected interactively either for the
46 current backup or a backup prior to a specified time and date.
47 \item Restore of a complete system starting from bare metal. This is mostly
48 automated for Linux systems and partially automated for Solaris. See
49 \ilink{Disaster Recovery Using Bacula}{RescueChapter}. This is also
50 reported to work on Win2K/XP systems.
51 \item Listing and Restoration of files using stand-alone {\bf bls} and {\bf
52 bextract} tool programs. Among other things, this permits extraction of files
53 when Bacula and/or the catalog are not available. Note, the recommended way
54 to restore files is using the restore command in the Console. These programs
55 are designed for use as a last resort.
56 \item Ability to restore the catalog database rapidly by using bootstrap
57 files (previously saved).
58 \item Ability to recreate the catalog database by scanning backup Volumes
59 using the {\bf bscan} program.
64 \item Catalog database facility for remembering Volumes, Pools, Jobs, and
66 \item Support for MySQL, PostgreSQL, and SQLite Catalog databases.
67 \item User extensible queries to the MySQL, PostgreSQL and SQLite databases.
70 \item Advanced Volume and Pool Management
72 \item Labeled Volumes, preventing accidental overwriting (at least by
74 \item Any number of Jobs and Clients can be backed up to a single Volume.
75 That is, you can backup and restore Linux, Unix, Sun, and Windows machines to
77 \item Multi-volume saves. When a Volume is full, {\bf Bacula} automatically
78 requests the next Volume and continues the backup.
80 \ilink{Pool and Volume}{PoolResource} library management
81 providing Volume flexibility (e.g. monthly, weekly, daily Volume sets, Volume
82 sets segregated by Client, ...).
83 \item Machine independent Volume data format. Linux, Solaris, and Windows
84 clients can all be backed up to the same Volume if desired.
85 \item The Volume data format is upwards compatible so that old Volumes
88 \ilink{message}{MessagesChapter} handler including routing
89 of messages from any daemon back to the Director and automatic email
91 \item Data spooling to disk during backup with subsequent write to tape from
92 the spooled disk files. This prevents tape "shoe shine" during
93 Incremental/Differential backups.
96 \item Advanced Support for most Storage Devices
98 \item Autochanger support using a simple shell interface that can interface
99 to virtually any autoloader program. A script for {\bf mtx} is provided.
100 \item Support for autochanger barcodes -- automatic tape labeling from
102 \item Automatic support for multiple autochanger magazines either using
103 barcodes or by reading the tapes.
104 \item Support for multiple drive autochangers.
105 \item Raw device backup/restore. Restore must be to the same device.
106 \item All Volume blocks (approximately 64K bytes) contain a data checksum.
107 \item Migration support -- move data from one Pool to another or
108 one Volume to another.
109 \item Supports writing to DVD (beta code).
112 \item Multi-Operating System Support
114 \item Programmed to handle arbitrarily long filenames and messages.
115 \item GZIP compression on a file by file basis done by the Client program if
116 requested before network transit.
117 \item Saves and restores POSIX ACLs on most OSes if enabled.
118 \item Access control lists for Consoles that permit restricting user access
120 \item Support for save/restore of files larger than 2GB.
121 \item Support for 64 bit machines, e.g. amd64, Sparc.
122 \item Support ANSI and IBM tape labels.
123 \item Support for Unicode filenames (e.g. Chinese) on Win32 machines on
124 version 1.37.28 and greater.
125 \item Consistent backup of open files on Win32 systems (WinXP, Win2003),
126 but not Win2000, using Volume Shadow Copy (VSS).
127 \item Support for path/filename lengths of up to 64K on Win32 machines
128 (unlimited on Unix/Linux machines).
133 \item Multi-threaded implementation.
134 \item A comprehensive and extensible
135 \ilink{configuration file}{DirectorChapter} for each daemon.
139 \section{Advantages Over Other Backup Programs}
140 \index[general]{Advantages of Bacula Over Other Backup Programs }
141 \index[general]{Programs!Advantages of Bacula Over Other Backup }
144 \item Since there is a client for each machine, you can backup
145 and restore clients of any type ensuring that all attributes
146 of files are properly saved and restored.
147 \item It is also possible to backup clients without any client
148 software by using NFS or Samba. However, if possible, we
149 recommend running a Client File daemon on each machine to be
151 \item Bacula handles multi-volume backups.
152 \item A full comprehensive SQL standard database of all files backed up. This
153 permits online viewing of files saved on any particular Volume.
154 \item Automatic pruning of the database (removal of old records) thus
155 simplifying database administration.
156 \item Any SQL database engine can be used making Bacula very flexible.
157 Drivers currently exist for MySQL, PostgreSQL, and SQLite.
158 \item The modular but integrated design makes Bacula very scalable.
159 \item Since Bacula uses client file servers, any database or
160 other application can be properly shutdown by Bacula using the
161 native tools of the system, backed up, then restarted (all
162 within a Bacula Job).
163 \item Bacula has a built-in Job scheduler.
164 \item The Volume format is documented and there are simple C programs to
166 \item Bacula uses well defined (IANA registered) TCP/IP ports -- no rpcs, no
168 \item Bacula installation and configuration is relatively simple compared to
169 other comparable products.
170 \item According to one user Bacula is as fast as the big major commercial
172 \item According to another user Bacula is four times as fast as another
173 commercial application, probably because that application stores its catalog
174 information in a large number of individual files rather than an SQL database
176 \item Aside from a GUI administrative interface, Bacula has a
177 comprehensive shell administrative interface, which allows the
178 administrator to use tools such as ssh to administrate any part of
179 Bacula from anywhere (even from home).
180 \item Bacula has a Rescue CD for Linux systems with the following features:
182 \item You build it on your own system from scratch with one simple command:
183 make -- well, then make burn.
184 \item It uses your kernel
185 \item It captures your current disk parameters and builds scripts that allow
186 you to automatically repartition a disk and format it to put it back to what
188 \item It has a script that will restart your networking (with the right IP
190 \item It has a script to automatically mount your hard disks.
191 \item It has a full Bacula FD statically linked
192 \item You can easily add additional data/programs, ... to the disk.
197 \section{Current Implementation Restrictions}
198 \index[general]{Current Implementation Restrictions }
199 \index[general]{Restrictions!Current Implementation }
202 \item If you have over 4 billion file entries stored in your database, the
203 database FileId is likely to overflow. This is a monster database, but still
204 possible. Bacula's FileId fields have been modified so that they can be
205 upgraded from 32 to 64 bits in version 1.39 or later, but you must
207 \item Files deleted after a Full save will be included in a restoration. This
208 is typical for most similar backup programs (we have a project to
210 \item Bacula's Differential and Incremental backups are based on
211 time stamps. Consequently, if you move files into an existing
212 directory or move a whole directory into the backup fileset
213 after a Full backup, those files will probably not be backed
214 up by an Incremental save because they will have old dates.
215 You must explicitly update the date/time stamp on all moved
216 files (we have a project to correct this).
217 \item File System Modules (configurable routines for
218 saving/restoring special files) are not yet implemented.
219 \item Bacula supports doing backups and restores to multiple
220 devices of different media type and multiple Storage daemons.
221 However, if you have backed up a job to multiple storage
222 devices, Bacula can do a restore from only one device, which
223 means that you will need to manually edit the bootstrap file
224 to split it into two restores if you split the backup across
226 \item Bacula cannot restore two different jobs in the same
227 restore if those jobs were run simultaneously, unless you had
228 data spooling turned on and the spool file held the full
229 contents of both jobs. In other terms, Bacula cannot restore
230 two jobs in the same restore if the jobs' data blocks were
231 intermixed on the backup medium. This poses no restrictions
232 for normal backup jobs even if they are run simultaneously.
235 \section{Design Limitations or Restrictions}
236 \index[general]{Restrictions!Design Limitations or }
237 \index[general]{Design Limitations or Restrictions }
240 \item Names (resource names, Volume names, and such) defined in Bacula
241 configuration files are limited to a fixed number of
242 characters. Currently the limit is defined as 127 characters. Note,
243 this does not apply to filenames, which may be arbitrarily long.