Jobs and Scheduling in Bacula - Page 2

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

 By Deann Corum
Page 2 of 2   |  Back to Page 1
Print Article

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

This article was originally published on Mar 18, 2009
Get the Latest Scoop with Networking Update Newsletter