Using Bacula for backup

Jurjen Bokma

February 2008

Bacula is a nice solution for backing up moderate levels of data in simple networked configurations. It is not as fast as commercial solutions, and more difficult to configure than a crontabbed rsync, but it will handle multiple clients, multiple storages, and multiple backup regimes as long as you don't overask. Here are some of the pitfalls I encountered the last time I reconfigured it.

  1. I use Bacula with PostgreSQL, and the scripts are geared more towards MySQL. The scripts mentioned in /etc/bacula/bacula-dir.conf for dumping the database can easily be replaced by a sing call to pg_dump. This saves me the hassle of understanding the included scripts, which are just wrappers anyway.

  2. Second point is to get authentication right. The passwords and resource names in bacula-dir.conf, bacula-sd.conf, bacula-fd.conf and bconsole.conf must match one another as stated in this FAQ-entry.

  3. Volume recycling is a nice feature, but I prefer to have a new volume for every run, and to manually throw away volumes when space is running out. Must make sure that volumed have been pruned by that time, i.e. the database has forgotten what they contain.

  4. Automatic Volume Labeling isn't completely clear to met yet. Although I have set up everything according to the examples, I still had to 'add' volumes to my storage once. This was a one-time event, and new volumes are automatically added, but I still don't see why it wouldn't work the first time.

  5. If Use Volume Once is set on a pool and only the date (as opposed to only the time) is used to distinguish the file to back up to, no job can run twice a day. (Talking 'bout kicking in open doors, eh?)