Bacula is available through package management tools (rpms) and it can be also installed from the source. In the following installation Bacula is installed from the source. Bacula user manual is over hundreds of pages long. Although, its a good read it is quite easy to get lost in this maze. In the following guide Bacula has been installed from the source on a CentOS 5 box. The official user manual instructions are availablehere.

Sections:

  • Requirements
  • Overview of Bacula System
  • Download Source
  • Building Bacula from the source
  • Configuring MySQL for Bacula
  • Before starting with the Configuration - Terminology
  • Configuring Bacula
  • Starting Bacula
  • Communicating with Bacula - Bconsole
  • Common Problems
  • Notes
  • References

Requirements

Overview of Bacula

Bacula contains four daemons which communicate with each other to manage backups. Each daemon process has its configuration file to setup various parameters. This configuration will be explained in a later section. The four daemons are listed below,

  • Director - The director daemon talks to clients, storage devices, and console. It orchestrates the entire process.
  • Client/File Daemon - The Client/File daemon runs on a machine to be backed up.
  • Storage Daemon - The Storage daemon communicates with the backup device, which may be a tape or a disk.
  • Console - The Console is the primary interface between the user and the Director.

Download source

Download Bacula source from sourceforge site. The source code has been ramified into many files as per their module

  • bacula-<version>.tar.gz : Core source code of Bacula
  • depkgs : Contains dependency packages for Bacula
  • bacula-docs-<version>.tar.gz : Bacula documentation
  • bacula-gui-<version>.tar.gz : This file contains non-core GUI programs

Building Bacula from source

  • cd to bacula source directory
  • Set the configure options as needed. The Bacula documentation has listed all the configure options. In this test installation the GUI is not enabled. Following are the options used for our testing configuration. Refer wiki for information on CFLAGS: http://en.wikipedia.org/wiki/CFLAGS . 
    CFLAGS="-g -O2" \
    ./configure \
    --sbindir=/usr/local/bacula/bin \
    --sysconfdir=/usr/local/bacula/bin \
    --with-pid-dir=/usr/local/bacula/bin/working \
    --with-subsys-dir=/usr/local/bacula/bin/working \
    --enable-smartalloc \
    --with-mysql \
    --with-working-dir=/usr/local/bacula/ \
    --with-dump-email=root@localhost \
    --with-job-email=root@localhost \
    --with-smtp-host=localhost \
    --with-readline \
  • The output of config is stored in config.out file. Verify that all paths specified are correct.
  • To change the config options re-run the ./config command after make distclean .
  • Run the make command. Check for any errors. 
    make
  • Run make install. 
    make install

Configuring MySQL for Bacula

  • Bacula install directory contains scripts for manipulating the database. These files are of the form *_bacula_* (e.g. create_bacula_database).
  • Create unrestricted access rights for the user 'bacula'. None of the userids are password protected by default. Please assign passwords using mysqladmin command or change the *_bacula_* MySQL scripts. 
    ./grant_mysql_privileges
  • Create the MySQL database for Bacula 
    ./create_mysql_database
  • Creates MySQL tables used by Bacula 
    ./make_mysql_tables
  • To verify user privileges - connect to mysql database and do select * from user;
  • Check Bacula database tables by connecting to bacula database and then do show tables;
  • Check table information to get some idea about how Bacula stores catalog information.
  • To reinitialize the database and throw away test database do ./drop_mysql_tables ./make_mysql_tables .
  • Check Bacula manual for more details about reinitializing database, upgrading MySQL.

Terminology

I wish I knew this link before I started with the configuration: Terminology.

  • Storage Coordinates: In simple terms it is location of a file on a backup/storage device. This information is saved in the Catalog database.
  • Catalog: Bacula keeps record of backups by storing some metadata in the database. Catalog services are comprised of the software programs responsible for maintaining file indexes and volume databases for all backup data. The database stores statistical information about a backup. The catalog maintains a record of volumes, running jobs, completed jobs. Currently, Bacula can only handle a single database server that is defined while configuring Bacula source. However, there may be as many Catalogs (databases) defined as you wish.
  • Volume: This is where Bacula stores the backup data. All volumes have a label name to identify them uniquely.
  • Pool: A group of volumes so that a backup is not restricted to the length of a single volume.

Bacula Configuration

A brief introduction to Bacula configuration files ca be found over here. Following is the configuration diagram from the Bacula manual which explains authentication between daemons.

http://www.bacula.org/en/rel-manual/Conf-Diagram.png

Client/File daemon configuration

A complete description of the Client/File daemon configuration file is available here. Following is a general overview of file daemon resources:

  • Client: defines clients name.
  • Director: defines the Director's name and password.
  • Messages: defines where messages are to be sent. 
# Default  Bacula File Daemon Configuration file
# For Bacula release 2.4.2 (26 July 2008) -- redhat
#

FileDaemon {                          # this is me
  Name = backup-fd
  FDport = 9102                       # where we listen for the director
  WorkingDirectory = /usr/local/bacula/
  Pid Directory = /usr/local/bacula/bin/working
  Maximum Concurrent Jobs = 20
}

# List Directors who are permitted to contact this File daemon

Director {
  Name = backup-dir
  Password = "client-password"
}

# Restricted Director, used by tray-monitor to get the
#  status of the file daemon

Director {
  Name = backup-mon
  Password = "uJOttaeW7ibBK6fOLKciwdCDpDcZQyLkylkpg+GLa+gF"
  Monitor = yes
}

# Send all messages except skipped files back to Director

Messages {
  Name = Standard
  director = backup-dir = all, !skipped, !restored
}

Storage daemon configuration

A complete description of the Client/File daemon configuration file is available here. Following is a general overview of storage daemon resources:

  • Storage: defines storage resource's name.
  • Director: defines the Director's name and password.
  • Devices: defines characteristics of the storage device (e.g.: tape drive)
  • Messages: defines where messages are to be sent. 
# Default Bacula Storage Daemon Configuration file
# For Bacula release 2.4.2 (26 July 2008) -- redhat

Storage {                        # definition of myself
  Name = backup-sd
  SDPort = 9103                  # Director's port
  WorkingDirectory = "/usr/local/bacula/"
  Pid Directory = "/usr/local/bacula/bin/working"
  Maximum Concurrent Jobs = 20
}

# List Directors who are permitted to contact Storage daemon

Director {
  Name = backup-dir
  Password = "storage-password"
}

# Restricted Director, used by tray-monitor to get the
#  status of the storage daemon

Director {
  Name = backup-mon
  Password = "l70S3MgAcpVYq8qIzBvdrU6E2iaKJyVY+ettl2A7pR3H"
  Monitor = yes
}

# Devices supported by this Storage daemon
# To connect, the Director's bacula-dir.conf must have the
#  same Name and MediaType.

Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /tmp
  LabelMedia = yes;                   # lets Bacula label unlabeled media
  Random Access = Yes;
  AutomaticMount = yes;               # when device opened, read it
  RemovableMedia = no;
  AlwaysOpen = no;
}


# Send all messages to the Director,
# mount messages also are sent to the email address

Messages {
  Name = Standard
  director = backup-dir = all
}

Director daemon configuration

A detailed description of all the directives can be referenced here. Following is a quick overview of all the Director directives.

  • Director: defines the Director's name and its access password used for authenticating the Console program. Only one definition per configuration file is allowed.
  • Job: defines the job type backup or restore, client name, FileSet name, and Schedule name.
  • JobDefs: optional resource that provides default options for the Job directive.
  • Schedule: defines when the job is to be run. Only one schedule can be referenced by a particular job.
  • FileSet: defines the set of files to be backed up for each client. Only one FileSet can be referenced by a particular job.
  • Client: defines which Client is to be backed up. Only one Client can be referenced by a particular job.
  • Storage: defines on what physical device the Volumes should be mounted.
  • Pool: defines the pool of Volumes that can be used for a particular Job.
  • Catalog: defines in what database to keep the metadata (file list and the Volume names) about the backup.
  • Messages: defines where messages are to be sent or logged. 
#  For Bacula release 2.4.2 (26 July 2008) -- redhat

Director {                            # define myself
  Name = backup-dir
  DIRport = 9101                     # where we listen for UA connections
  QueryFile = "/usr/local/bacula/bin/query.sql"
  WorkingDirectory = "/usr/local/bacula/"
  PidDirectory = "/usr/local/bacula/bin/working"
  Maximum Concurrent Jobs = 1
  Password = "console-password"         # Console password
  Messages = Daemon
}

JobDefs {
  Name = "DefaultJob"
  Type = Backup
  Level = Incremental
  Client = backup-fd
  FileSet = "Full Set"
  Schedule = "WeeklyCycle"
  Storage = File
  Messages = Standard
  Pool = Default
  Priority = 10
}


JobDefs {
  Name = "BobJobDef"
  Type = Backup
  Level = Full
  Client = bob-fd
  FileSet = "Bob File Set"
  Schedule = "DailyFourPM"
  Storage = File
  Messages = Standard
  Pool = Default
  Priority = 10
}

# Define the main daily/nightly save backup job

Job {
  Name = "Client1"
  JobDefs = "DefaultJob"
  Write Bootstrap = "/usr/local/bacula//Client1.bsr"
}

# second client
Job {
  Name = "Client2"
  JobDefs = "BobJobDef"
  Write Bootstrap = "/usr/local/bacula//Client2.bsr"
}

# Backup the catalog database (after the nightly save)
Job {
  Name = "BackupCatalog"
  JobDefs = "DefaultJob"
  Level = Full
  FileSet="Catalog"
  Schedule = "WeeklyCycleAfterBackup"
  RunBeforeJob = "/usr/local/bacula/bin/make_catalog_backup bacula bacula"
  RunAfterJob  = "/usr/local/bacula/bin/delete_catalog_backup"
  Write Bootstrap = "/usr/local/bacula//BackupCatalog.bsr"
  Priority = 11                   # run after main backup
}


# Standard Restore template, to be changed by Console program
#  Only one such job is needed for all Jobs/Clients/Storage ...

Job {
  Name = "RestoreFiles"
  Type = Restore
  Client=backup-fd
  FileSet="Full Set"
  Storage = File
  Pool = Default
  Messages = Standard
  Where = /bacula-restores
}

# Added another restore template - just clone of above
Job {
  Name = "RestoreBobFiles"
  Type = Restore
  Client=bob-fd
  FileSet="Bob File Set"
  Storage = File
  Pool = Default
  Messages = Standard
  Where = /bacula-restores
}


# List of files to be backed up
FileSet {
  Name = "Full Set"
  Include {
    Options {
      signature = MD5
    }
    File = /home/shan/bacula/bacula-2.4.2
  }
  Exclude {
    File = /proc
    File = /tmp
    File = /.journal
    File = /.fsck
  }
}

FileSet {
  Name = "Bob File Set"
  Include {
    Options {
      signature = MD5
    }
    File = /var/log/mysql
  }
}

# When to do the backups, full backup on first sunday of the month,
#  differential (i.e. incremental since full) every other sunday,
#  and incremental backups other days
Schedule {
  Name = "WeeklyCycle"
  Run = Full 1st sun at 23:05
  Run = Differential 2nd-5th sun at 23:05
  Run = Incremental mon-sat at 23:05
}

# This schedule does the catalog. It starts after the WeeklyCycle
Schedule {
  Name = "WeeklyCycleAfterBackup"
  Run = Full sun-sat at 23:10
}

# for test purpose 
Schedule {
  Name = "DailyFourPM"
  Run = Full Daily at 00:32
}

# This is the backup of the catalog
FileSet {
  Name = "Catalog"
  Include {
    Options {
      signature = MD5
    }
    File = /usr/local/bacula//bacula.sql
  }
}

# Client (File Services) to backup
Client {
  Name = backup-fd
  Address = backup.lab.ac.uab.edu
  FDPort = 9102
  Catalog = MyCatalog
  Password = "client-password"          # password for FileDaemon
  File Retention = 30 days            # 30 days
  Job Retention = 6 months            # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
}

# Second Client (File Services) to backup
#  You should change Name, Address, and Password before using

Client {
  Name = bob-fd
  Address = bob.lab.ac.uab.edu
  FDPort = 9102
  Catalog = MyCatalog
  Password = "client-password"        # password for FileDaemon 2
  File Retention = 30 days            # 30 days
  Job Retention = 6 months            # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
}


# Definition of file storage device
Storage {
  Name = File
# Do not use "localhost" here
  Address = backup.lab.ac.uab.edu                # N.B. Use a fully qualified name here
  SDPort = 9103
  Password = "storage-password"
  Device = FileStorage
  Media Type = File
}

# Generic catalog service

Catalog {
  Name = MyCatalog
  dbname = "bacula"; dbuser = "bacula"; dbpassword = ""
}

# Reasonable message delivery -- send most everything to email address
#  and to the console
Messages {
  Name = Standard
  mailcommand = "/usr/local/bacula/bin/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: %t %e of %c %l\" %r"
  operatorcommand = "/usr/local/bacula/bin/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: Intervention needed for %j\" %r"
  mail = root@localhost = all, !skipped
  operator = root@localhost = mount
  console = all, !skipped, !saved
  append = "/usr/local/bacula//log" = all, !skipped
}

# Message delivery for daemon messages (no job).

Messages {
  Name = Daemon
  mailcommand = "/usr/local/bacula/bin/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula daemon message\" %r"
  mail = root@localhost = all, !skipped
  console = all, !skipped, !saved
  append = "/usr/local/bacula//log" = all, !skipped
}

# Default pool definition

Pool {
  Name = Default
  Pool Type = Backup
  Recycle = yes                       # Bacula can automatically recycle Volumes
  AutoPrune = yes                     # Prune expired volumes
  Volume Retention = 365 days         # one year
}

# Scratch pool definition
Pool {
  Name = Scratch
  Pool Type = Backup
}

# Restricted console used by tray-monitor to get the status of the director

Console {
  Name = backup-mon
  Password = "console-password"
  CommandACL = status, .status
}

Console configuration

Make sure that password in the console resource of the director and in the director resource of the console are same. 

# Bacula User Agent (or Console) Configuration File

Director {
  Name = backup-dir
  DIRport = 9101
  address = backup.lab.ac.uab.edu  # use FQDN 
  Password = "console-password"
}

Starting Bacula service

You may start Bacula service using the command, 

./bacula start

To stop the service change the 'start' option to 'stop'.

Verify that Bacula service is running properly by using status option 

./bacula status

or 

ps augx | grep -i bacula

Starting Bacula in the debugging mode

To start Bacula service in a debugging mode specify -d switch with an integer meaning debugging level. 

./bacula start -d100

Using bconsole

Start the bconsole by 

./bconsole

Type help to get list of all commands: 

help

Following is the list of commands to get started with:
To get status of the client: 

status client

To get director status, running and terminated jobs information: 

status dir

To see list of jobs: 

list jobs

To start a backup job: 

run

To see recent messages: 

messages

To restore a backup: 

restore select

CPs - Common Problems

If there is a problem in communication between daemon services then,

  • Check for password entries.
  • Check whether Bacula service is running or not
  • Start Bacula in a debugging mode.
  • If ports are open and the Bacula service is running, check for network problems. Try connecting via telnet, or ping the client/storage/server.

In my case, the PID directory mentioned in the configure options was missing or may be it never gets created automatically. So I had to create the 'working' directory where Bacula would refer for the PID files.

Notes

  • Backup levels: Bacula supports three back up levels.
    • full (complete dumps)
    • differential (files changed since last full backup)
    • incremental (changed files since the last backup of any sort) backups

Brief Tutorial

Brief Tutorial: http://www.bacula.org/en/rel-manual/Brief_Tutorial.html