Serious backup for the home network: Bacula configuration

Jurjen Bokma

January 2010

Bacula is my backup solution of choice. It features thorough documentation, and clients for all the OS'es I employ: Linux, OpenBSD and Windows. And it is flexible enough to allow me to do full backups only once a month, differential once a week, and incrementals every day, so as long as I have space, I can do some kind of archiving-lite with the incrementals.

Figure 1.  A network with a Bacula server
A network with two IP ranges separated by a firewall, and the Bacula server in one range, while the backed-up hosts are in the other.

As we can see in , I have taken the precaution to shield off the network area in which the bacula server resides. The backup server, Backup.datanet is quarantained in a separate IP range, a separate domain, and a separate segment of the network. This is because inside the backup, file permissions are meaningless, and an intruder with read access on the backup server could see anything they like. And intruder with write access could do serious damage and be discovered only at restore time, when it is too late by definition for measures.

For a bit of background, the Bacula workflow uses three daemons:

  • The file daemon runs on the host that must be backed up, and retrieves the files that go into backup.

  • The storage daemon runs on the host where the backups are kept, and receives the files that go into backup from the file daemon across the network.

  • The director daemon orchestrates the communication between all the storage daemons and file daemons in a network. In my case, it runs on the machine where the backups are kept, but it could run elsewhere.

And then there is the console program (not a daemon), that forms the interface between the director and the backup admin (that would be me).

Procedure 31.  Installing the Bacula server
  1. Backup.datanet is a Shuttle a barebones PC with a large (1TB) harddisk, and a BIOS that cat do Wake-on-LAN. Backing up to harddisk is rather more risky than to tape, as harddisks can be wiped in seconds with a single command, and backing up to a single harddisk is bound to fail at some point (my last disk did, that's why I'm reconfiguring now), but is is still way better than nothing. I installed Ubuntu LTS (Hardy) and laid the disk out with LVM and mounted a large partition on /srv/backup. And I wrote a small file /etc/init.d/wol that reads:

    ethtool -s eth0 wol g

    which I fixed into the startup sequence by saying:

    sudo update-rc.d wol start 80 S .

    So now the machine will react to wake-on-LAN as long as the power stays on.

  2. Backup.datanet runs the Bacula director and the Bacula Storage Daemon, as well as a PostgreSQL database to keep track of what files from what backed up hosts have ended up in what backup volumes. The database will come in handy when we start doing restores, which is kind of the purpose of making backups.

    sudo apt-get install bacula-director-pgsql bacula-server bacula-sd-pgsql bacula-console-qt postfix


In the following procedures, many randomly generated passwords are used. A suitable command to generate one of these is:

apg -a1 -m60 -x60 -n1 -M ncl

(Please refer to the docs to look up the options used)


All the Bacula daemons, as well as the console, use passwords for authentication. Although the added security of this can be questioned as far as the backup host and the firewalled machines are concerned, it is probably a good thing for the laptop. To keep track of the random string spaghetti, note that the director and the console must share a common password so the console can access the director. Also note that the director employs a limited-privilege monitor to question the storage daemon and the file daemon on progress. This password is a single one for the director, and is shared between multiple storage and file daemons. And lastly, the password used by the director to make the file daemon or storage daemon actually transfer files can be set on a per-file-daemon and per-storage-daemon basis.

Procedure 32.  Configuring Bacula on the Bacula server
  1. The program bconsole runs on the same host as the bacula-director daemon, and it has its configuration in /etc/bacula/bconsole.conf

    # Bacula User Agent (or Console) Configuration File
    Director {
    Name = localhost-dir
    DIRport = 9101
    address = localhost
    Password = "Uc2TYaIUHKwR1tYCQtpOHHVVYujUefDaKcZwqcyqjmVhBbkMT9xbeeGJsPpg"

  2. Unfinished...