Jobs and Scheduling in Bacula - Page 2

By Deann Corum | Posted Mar 17, 2009
Page 2 of 2   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

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

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

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter