Backups to the Future: Eliminate Tape Backups with FreeNAS and Bacula

The future of backups is here, but unfortunately, there aren't any Delorians.

With the FreeNAS system in place, let's start building the Bacula system. The test system used here was built on Fedora 8 (Werewolf) with GNOME, because it includes Bacula and its dependencies in its core RPM library. To add the necessary packages and related dependencies, all you need to do is use the Add/Remove Software utility under the Applications menu. When ready, install the following packages:

  • bacula-client

  • bacula-common

  • bacula-console

  • bacula-gnome

  • bacula-console-gnome

  • bacula-console-wxwidgets

  • bacula-director-common

  • bacula-director-mysql

  • bacula-docs

  • bacula-storage-common

  • bacula-storage-mysql

  • bacula-traymonitor

  • mysql

When the installs are complete, start mysqld, and set it to start runlevel 5 from the Services utility in GNOME or use chkconfig. If you're using a different distribution, you need to use the Bacula source files and make/configure the install to get to the next step. This can be more challenging than using an RPM, because of the numerous command-line install options available.

Next, open a terminal to create the MySQL tables needed for Bacula to operate. Run the following scripts created by the Bacula RPM:

/etc/alternatives /make_bacula_tables
/etc/alternatives /grant_bacula_privileges

After setting up the database, create a local mountpoint (like /mnt/freenas), and mount the FreeNAS share created previously. An easy way to do this on every startup is to add the following line to your /etc/fstab file:

FreeNASServerHostName:/mnt/DATA   /mnt/freenas   nfs   defaults	0 0

To mount the partition immediately, type mount -a.

Before moving on to editing Bacula's configuration files, here's how Bacula works. The Bacula program is composed of three separate dæmons: the director, the storage dæmon and the file dæmon. The director is the boss. It's the main server dæmon that defines jobs, pools, schedules and most of the important settings related to backups. As such, the majority of setup deals with its configuration file /etc/bacula/bacula-dir.conf. The storage dæmon (SD) controls the media written to by Bacula, usually either tapes or disks. These items are configured in the bacula-sd.conf file. The file dæmon (FD), also referred to as the client, runs locally on any system you want to back up. Two other related utilities used here are the GNOME console (gnome-console.conf) and the tray-monitor (tray-monitor.conf) utility.

With this basic knowledge of Bacula's interoperation, open your /etc/bacula/bacual-dir.conf file, and add the following lines (for brevity, I have added only those sections used in our scenario):

JobDefs {
  Name="UserHomes" Type=Backup Client = bacula-fd FileSet =
  "UserHomeFolders" Storage = File Messages = Daemon

Job {
  Name = "WeeklyHomeBackups"
  JobDefs = "UserHomes"
  Level = Full
  Schedule = WeeklyFullandDiffs
  Pool = Weekly
  Priority = 10
  Write Bootstrap = "/var/spool/bacula/WeeklyHomeBackups.bsr"

Job {
  Name = "MonthlyHomeBackups"
  JobDefs = "UserHomes"
  Level = Full
  Schedule = MonthlyFull
  Pool = Monthly
  Priority = 10
  Write Bootstrap = "/var/spool/bacula/MonthlyHomeBackups.bsr"

Schedule {
  Name = "WeeklyFullandDiffs"
  Run = Level=Full Pool=Weekly sun at 3:00
  Run = Level=Differential Pool=Diffs mon-fri at 3:00

Schedule {
  Name = "MonthlyFull"
  Run = Level=Full Pool=Monthly 1st sat at 3:00

FileSet {
  Name = "UserHomeFolders"
  Include {
    Options {
      signature = MD5
    File = /home

Pool {
  Name = Weekly
  Pool Type = Backup
  Recycle = yes                       
  AutoPrune = yes                     
  Volume Retention = 6 days       
  Maximum Volumes = 5
  Label Format = Bkup-Full

Pool {
  Name = Diffs
  Pool Type = Backup
  Recycle = yes 
  AutoPrune = yes           
  Volume Retention = 23 hours 
  Maximum Volumes = 1
  Label Format = Bkup-Diff

Pool {
  Name = Monthly
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 364 days 
  Maximum Volumes = 12
  Label Format = Bkup-Monthly

Although it may seem odd to start at the bottom and discuss the Pool section, it is vital that it is configured correctly. A pool is simply a collection of volumes. Volumes are tapes or disks to which the backup files are written. A pool can contain any number of volumes, but it must have at least one volume. Here, we have set up three pools: a weekly full, a differential and a monthly. This allows us to maintain backups for the current week up until the previous day and a 12-month rotation for our monthly backups.

Then, going from the top section down, there is a Job Definitions (JobDefs) section, and two Jobs modeled around our backup strategy. The JobDefs section defines common properties that several jobs share, like a template. In it, we have listed settings common to both jobs. The Schedule section defines when a given job runs and how often. The schedules listed here run weekly backups every Sunday, daily differentials Monday through Friday and a monthly backup the first Saturday of every month. The Fileset section lists what folders and files to back up and with what options. For this example, we have set Bacula to back up the local users' home folders, a common scenario for backups. Recursion is enabled by default on FileSets, so we need to specify only the parent folder. The backup files also are set to compress using gzip and to hash/encrypt themselves using MD5. Doing both is good practice.

Before saving and closing the file, go through and change any instance of @@Password@@ or like entries to a common password. Rather than cover how each Bacula dæmon authenticates with the other, it's easier simply to change all of them to the same password for the time being and get the system up and running. You can change these passwords later if desired. Change any other password-related fields in the following files to the common password as well: bacula-sd.conf, bacula-fd.conf, bconsole.conf, gnome-console.conf and tray-monitor.conf. After changing the passwords, you also need to change any references to your host in all the .conf files, so each dæmon can communicate with each other. If all of the dæmons run locally, you can use localhost. You also could use an FQDN or IP address. The field you want to edit is listed under each section as Address. So, for example, change the line:

Address =



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Tape Sets

zied's picture


I followed this article with great interest, it's really instructive.

I implemented the same "algorithm" but with tapes.

I'm confused about how many do I need, and when to change ??

can you help please ?

kind regards,

Share what you learn what you don't


uslacker's picture

Did he really tell us to change all the passwords to a default so we can get the system up and running? Then go back later....

Isn't this how we got ourselves in to the security quagmire we've been trying to get out of for years? Too many simple passwords or "we'll do it later.." has left back doors the size of trucks in our networks.
Please, teach us better than this!



Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up and watch now

Sponsored by Skybot