Configure Bacula for Open Source Backups

Thursday Jun 25th 2009 by Deann Corum

Bacula is a popular and robust open source backup solution. Learn the basics of Bacula configuration with our simple guide.

Since we covered installation and a very basic initial run the last time we looked at Bacula, let's look at some of the more specific configuration options and capabilities this time.

We aren't trying to provide a comprehensive collection of all Bacula capabilities, which are incredibly numerous. Instead, we want to give you an overview of how Bacula's basic options and capabilities might be configured.

Device Resources

Device resources specify the details of a storage device that can be used by the Bacula storage daemon. One of the most common storage devices likely to be used are tape autochangers. In Bacula, storage devices are configured in the bacula-sd.conf file as well as in the bacula-dir.conf file. An autochanger configuration in bacula-sd.conf might look similar to the following:

Autochanger {
Name = Autochanger
Device = Exabyte
Changer Device = /dev/sg0
Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d"

Device {
Name = Exabyte
Media Type = LTO
Archive Device = /dev/nst0
Autochanger = Yes
Hardware End of File = no
Spool Directory = /var/bacula/spool
Random Access = no
AutomaticMount = yes
RemovableMedia = yes
AlwaysOpen = yes
Maximum Spool Size = 300G

Device above refers to the archive device, which in this case, is a tape drive. Autochanger = Yes in the Device section tells Bacula that this device belongs to an automatic tape changer and necessitates the definition of a changer device, which is detailed in the first section. AutomaticMount = yes means that Bacula will automatically access the volume unless the operator explicitly unmounts it in the console. AlwaysOpen = yes tells Bacula to keep the device open unless specifically unmounted, so that the tape drive is always available to Bacula. When using tapes, this should always be set to 'yes' to avoid unnecessary operator intervention.

If you're using a DVD device instead of tapes, the Archive Device above might be specified as /dev/hdc with Random Access set to 'yes'.  If you're archiving to disk, you would put the full absolute path to the disk directory here instead. In that case, Bacula would write to that directory, and would use the Volume name configured in the catalog. Also, the RemovableMedia parameter would be set to 'no'.  The Media Type would be 'File',  the Autochanger parameter would be set to 'no',  and the separate autochanger device configuration would be unnecessary.

In bacula-dir.conf, the device resource must also be defined, and the name must match what is configured in bacula-sd.confabove:

Storage {
Name = Autochanger
Address =
SDPort = 9103
Password = "xxxxxxverylongpasswordstringxxxxx"
Device = Autochanger
Autochanger = yes
Media Type = LTO


The parameters Spool Directory, and Maximum Spool Size in bacula-sd.conf are worth noting.  If you're using tapes and running incremental backups, you'll want to use a disk spool. The reason for this is that it takes a long time for data to come in to the file daemon (bacula-fd) during an incremental backup. If this data is written directly to tape, the tape will start and stop often, causing what's called shoe-shining of the tape.  By writing the data to disk first, then to tape, the tape can be kept in continual motion, reducing wear on the tape.   Of course, the larger the spool device, the better. In the above configuration, the Spool Directory is set to /var/bacula/spool (which can be a link to another directory elsewhere on the system), and the Maximum Spool Size is set to 300G.

The reason for setting a Maximum Spool Size is to keep the spooled data from filling up the entire disk. Bacula becomes very unhappy when the spool device becomes full during a backup so you don't want that to happen.  Make it large, but limit it to keep it from filling your disk. Otherwise, Bacula will happily spool data to disk until the entire disk is full, at which point it will become very unhappy.

It's worth remembering that Bacula writes backup information to the catalog AFTER the data is written to tape. So, once the job is done spooling and the backup data is actually written to tape, Bacula will then write the information about that backup to the catalog.  This is to prevent having backup information written to the catalog for backups that haven't actually been written to backup media yet.

Volumes, Pools and Labels

How Bacula deals with Volumes, Pools and Labels can be confusing for first-time users, so here's a synopsis:

In Bacula, a Volume is a single tape or file on which Bacula will write your backup data.  A Pool is a collection of volumes, configured such that Bacula does not have to limit a backup to the length of a single Volume (tape, or disk). Instead of naming Volumes in Bacula, you define Pools, so that Bacula can simply add data to the next appendable Volume in the Pool. Adding Volumes to a Pool is done using the 'label' command from within the Bacula Console (bconsole).  Bacula will not write to a Volume until it has been labeled from within Bacula.  The Volume label, along with other data, such as the first and last write times, and the number of files and bytes written to a Volume, are stored in the Bacula catalog (database). The Bacula catalog also contains information about the Pool as well as the Volumes in a Pool. The Pool resource is defined in the Bacula Director configuration.

A simple example of a Pool setup in bacula-dir.conf is below:

Pool {
Name = full

Pool Type = Backup
Recycle = yes # automatically recycle Volumes
AutoPrune = yes # Prune expired volumes
Volume Retention = 6 months
Accept Any Volume = yes # write on any volume in the pool

Most of the options above are self-explanatory, however, much more information about how to configure Pools in Bacula can be found in Bacula's online documentation

Page 2: Jobs and Restoring Data

Back to page 1

Jobs in Bacula consist of a FileSet, A Client, a Schedule, and a Pool.  In other words, we have to tell Bacula WHAT to back up, WHERE to back it up FROM, WHEN to run the backup, and WHERE to back it up TO. Typically, one particular Schedule is set up as the Default.  Below are examples of each piece that constitutes a Job in Bacula and finally how the Job directive ties them all together:

WHERE to back up TO:

Pool {
Name = full
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 6 months

Accept Any Volume = yes

WHEN to back up:

Schedule {
Name = default
Run = Level=Full Pool=full mon-sun at 23:00

WHERE to back up FROM:

Client {
Name = stash
Catalog = catalog
Address =
Password = xxxxxxverylongpasswordstringxxxxx
AutoPrune = yes
File Retention = 6 months
Job Retention = 6 months

WHAT to back up:

FileSet {
Name = stash-home
Include {
File = /sdd1/stash.home
Options { signature=MD5 aclsupport=yes }


JOB definition (includes Fileset, Client  Schedule, Pool):

Job {
Write Bootstrap = /var/bacula/bootstrap/stash-home.bsr
FileSet = stash-home
Spool Data = yes
Spool Attributes = yes
RunAfterJob = "su - backup -c "/usr/local/rdb/rdb-driver rdb --trimonly stash.home""
Name = stash-home
Client = stash
Schedule = Default  #full backup every night at 11:00
Storage = Autochanger
Messages = Standard
Priority = 11
Type = Backup
Pool = full

Job RunBefore/RunAfter Directives

In the example above, you'll notice a RunAfterJob directive.  This particular one tells Bacula to run a script to remove some files on the server (where in this case, Bacula is backing the files up from), after those files are backed up to tape.  Of course, Bacula has RunBeforeJob capabilities as well. Bacula can run most any script or command here you chose. Most commonly these directives are used to dump databases to disk, mount and unmount filesystems or devices, or remove files prior to or after backup jobs.

Restoring Data

Oh yeah: Finally, let's get to the point of all this: RESTORING data from backup.  This is the easiest part once you have Bacula running and doing regular backups for you. In bacula-dir.conf, you will have configured a default restore job. However, the parameters of any restore job can be changed from within bconsole after running the 'restore' command.

After typing 'restore' in bconsole, you are presented with several menu-driven options to choose what Jobs (JobIds) you'd like to restore from, which Clients and Pools you'd like to restore from, and what files you'd like restored - right down to an individual file from a certain date.  After you've made your selections, you will be presented with a list of media that will be required to restore your files, and your chosen restore job parameters. You'll be allowed to modify those parameters, including where (which client/directory) you would like the file(s) to be restored, and whether to overwrite the files if they already exist in the restore location.

In the few years I've used Bacula, I've personally been impressed with what a robust backup system it is. I've known both large-scale users as well as small-business and home users who swear by it.  If you're looking for a robust, well-maintained open-source backup solution, add Bacula to your list and give it a spin.


After our last piece on Bacula, some readers noted errors in the terminology we used for two of the components of Bacula, bacula-sd and bacula-fd.  The proper term for these Bacula components are bacula storage daemon, and bacula file daemon, respectively.  The only Bacula component called director is the Bacula Director itself (bacula-dir). 

Article courtesy of Enterprise Networking Planet

Follow Enterprise Storage Forum on Twitter

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved