Preventing race conditions with multiple stage backups with bacula

Heads up! This post was written when Metric Marketing was known as Canada's Web Shop.
headshot

So, say you've got two different types of backups that need to happen. For example, collecting all of your servers' data with bacula, and also sending all that backup data offsite for offsite storage. You don't want a race condition happening where the offsite backup starts happening before the bacula backup finishes, for any of a multitude of reasons. Mine is because I want my offsite backup to pull from the data gathered by bacula, reducing the extra bandwidth that would have to happen if I went straight from the servers to offsite.  You could time them far enough apart that one job SHOULD have enough time to finish before the next starts, but you've got even more time for your backups to get out of sync there. And what happens if one backup runs longer some day? I need my offsite backups to start only after bacula has finished, so I can guarantee the offsite data we have is current, not yesterday's stuff.

How?

A combination of bacula scheduling and threading, and bacula's post-job scripts. You can schedule a job in order of importance by just incrementing the time the job starts just slightly later than the other jobs. They will then queue up in that order when the time comes. I have the majority of my jobs running at a specific time, let's say 23:05. I have the last job that I want to finish starting at 23:10. In the job definition for the last run job, place a

Run After  = command

with command being your offsite backup script. I just use a simple bash script that elevates privileges, runs bextract from the bacula stores, and does whatever it needs to to push them offsite. Check the manual for other fun stuff you can do before and after your jobs.

Like what you read? Sign up for our Newsletter.