Configure Bacula for Open Source Backups

By Deann Corum | Mar 17, 2009 | Print this Page
http://www.enterprisenetworkingplanet.com/netsysm/article.php/3810891/Configure-Bacula-for-Open-Source-Backups.htm

Since we covered installation and a very basic initial run the last time we looked at Bacula, let&aposs 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&aposs 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 &aposyes&apos to avoid unnecessary operator intervention.

If you&aposre using a DVD device instead of tapes, the Archive Device above might be specified as /dev/hdc with Random Access set to &aposyes&apos.  If you&aposre 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 &aposno&apos.  The Media Type would be &aposFile&apos,  the Autochanger parameter would be set to &aposno&apos,  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.conf above:

Storage {
Name = Autochanger
Address = stash.crystle.com
SDPort = 9103
Password = "xxxxxxverylongpasswordstringxxxxx"
Device = Autochanger
Autochanger = yes
Media Type = LTO
}

Spooling

The parameters Spool Directory, and Maximum Spool Size in bacula-sd.conf are worth noting.  If you&aposre using tapes and running incremental backups, you&aposll 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&aposs 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 Max! imum 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&apost 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&aposs 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&apost 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&aposs 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 &aposlabel&apos 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

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 = 10.0.0.63
Password = xxxxxxverylongpasswordstringxxxxx
AutoPrune = yes
File Retention = 6 months
Job Retention = 6 months
}

WHAT to back up:

#stash-home
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&aposll 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&aposs 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 &aposrestore&apos command.

After typing &aposrestore&apos in bconsole, you are presented with several menu-driven options to choose what Jobs (JobIds) you&aposd like to restore from, which Clients and Pools you&aposd like to restore from, and what files you&aposd like restored - right down to an individual file from a certain date.  After you&aposve 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&aposll 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&aposve used Bacula, I&aposve personally been impressed with what a robust backup system it is. I&aposve known both large-scale users as well as small-business and home users who swear by it.  If you&aposre looking for a robust, well-maintained open-source backup solution, add Bacula to your list and give it a spin.

Note

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