oreilly.comSafari Books Online.Conferences.


Bacula: Cross-Platform Client-Server Backups

by Dan Langille

When people ask around about open source backup solutions, Amanda usually comes up first. I started there, but before I finished my implementation, I found what I think is a much better solution: Bacula. It may sound campy, but it works well. The design is well thought-out, and features include:

  • Support for multiple platforms, including Windows clients.
  • Use tape and/or disk as storage devices.
  • Schedule different jobs at different times/days.
  • Backups that can span multiple tapes.
  • More than one backup per tape.
  • Optionally fingerprint each file as it is backed up.
  • Backup catalogs are retained within a database (SQLite or MySQL. There is also a PostgreSQL option in beta).
  • Auto-changer support.

I've been working with Bacula for four months now, and I'm impressed at how well it works and how flexible it is. I've been able to set up backups for both FreeBSD and Windows clients.

In the rest of this article, I'll show you how to configure Bacula to perform backups of your Unix and Windows boxes.

Bacula Documentation and Flexibility

Bacula is well documented and fairly easy to start using. Like any powerful tool, there are more features than you will probably use, but not all features appeal to everyone. Whatever your needs, Bacula can play a powerful role in your backup solution.

The key to its power is its flexibility. The scheduling capabilities allow you to decide when a job will run and how often that job will run. Bacula is aware of holidays. It can also handle machines that connect to the network infrequently -- laptops, for example. If you need to run a script before or after the job, on the client or the server, it can be done. Windows clients? Done.

The flexibility doesn't end just with the backups. The restores are also well thought-out. You can restore to a point in time, using all relevant backups. Bacula lists the required tapes and you supply them. For the ultimate in control, you can browse the files and decide which ones you want.


Bacula is a client-server solution and is composed of several distinct parts:

  • The Director is the most complex part of the system. It keeps track of all clients and files to be backed up. This daemon talks to the clients and to the storage devices.

  • A Client or File Daemon runs on each computer that will be backed up by the Director. Some other backup solutions refer to this as the Agent.

  • The Storage Daemon communicates with the backup device, which may be tape or disk.

  • The Console is the primary interface between you and the Director. I use the command line Console, but there is also a Gnome GUI Console.

Each File Daemon will have an entry in the Director configuration file. Other important entries include Jobs and FileSets. A FileSet identifies a set of files to backup. A Job specifies a single FileSet, the type of backup (incremental, full, etc.), when to do the backup, and what Storage Device to use.

Backup jobs can be run automatically or manually. Restores are similar.

Daemon Communication

This section contains background information on how the various Bacula components communicate with each other. You can safely skip over this section if you don't want to know the details.

The Daemons talk to each other on specific ports as specified within their Resource statements. They also use shared passwords. Each Client has a password that the Director knows. These passwords must match. On the Director, the password appears in the Client statement. On the Client, the password appears in the Director statement. It is because of this password that the configuration files must be secured.

You don't normally have to worry about these passwords. They are contained within the configuration files. You do not need to type them, but you should ensure that the password files are not world-readable. Bacula uses CRAM-MD5 authentication to avoid having to exchange passwords over the network.

All communication is over the network. This means each component may reside on a different machine. The ability to have multiple storage devices on multiple machines is a very nifty feature. Any single backup cannot write to multiple storage devices simultaneously, but Bacula can write different job streams to multiple storage devices simultaneously.

Similarly, the console can be installed on any machine. It can connect to the Director, which could be on the same machine or on another machine. If your needs demand it, you can install multiple Directors and have them backup to the same or different storage devices. A given Client can be backed up by multiple Directors.

Bacula Installation

The Bacula server supports multiple platforms:

  • Linux (Gentoo, SuSE, Mandrake, Debian, RedHat, ...)
  • Solaris
  • FreeBSD

The Bacula client, in addition to the platforms listed above for the server, is supported on:

  • Windows (Win95/98/Me, WinNT/2K/XP)
  • OpenBSD
  • FreeBSD
  • Irix

It's also said to work on other systems, such as AIX, BSDI, and Mac-Darwin.

Bacula stores details of each backup in a database. You can use either SQLite or MySQL. (There is also a PostgreSQL option under development; I'm working on that now.) Before you install Bacula, decide which you want to use. I recommend MySQL until the PostgreSQL port is available; it will come with a conversion script.

I won't provide detailed Bacula installation instructions, as that is well covered on its site. You can either install from source, in which case the documentation is your friend, or you can use the packages or port for your chosen operating system.

I know that FreeBSD has a port that is installed with the following command:

# cd /usr/ports/sysutils/bacula/
# make install

The above will install an SQLite version of Bacula. You can install the MySQL version by specifying WITH_MYSQL on the make command:

# cd /usr/ports/sysutils/bacula/
# make -DWITH_MYSQL install

Warning: FreeBSD 4.x (prior to 4.10-RELEASE) and FreeBSD 5.x (version 5.2.1 and prior) have a pthreads bug that could cause you to lose data. Please refer to platform/freebsd/pthreads-fix.txt in your Bacula source directory for full details.


Bacula has many configuration options. My goal here is to get you up and running your first backup. From that point, you'll be able to customize your configuration further to suit your own needs. The default install for Bacula should be enough to get you started. I'll highlight a few items to point you in the right direction.

Client/File Daemon configuration (usr/local/etc/bacula-fd.conf)

I use the following configuration on my laptop. This defines the File Daemon (or client) that will be contacted by the Director and on which a Job will run.

Director {
  Name     = laptop-dir
  Password = "laptop-client-password"

FileDaemon {
  Name             = laptop-fd
  FDport           = 9102
  WorkingDirectory = /var/db/bacula
  Pid Directory    = /var/run

# Send all messages except skipped files back to Director
Messages {
  Name     = Standard
  director = undef-dir = all, !skipped

This client will only respond to a Director with the name laptop-dir and the password laptop-client-password. As the Director resource documentation says: There may be any number of Director resources in the Client configuration file. Each one specifies a Director that is allowed to connect to this Client.

Storage Devices (/usr/local/etc/bacula-sd.conf)

I really like Bacula's concept of a storage device. It doesn't care if it is backing up to tape or disk. It's just a storage device. Here is the configuration file from my laptop:

Storage {
  Name             = laptop-sd
  SDPort           = 9103
  WorkingDirectory = "/var/db/bacula"
  Pid Directory    = "/var/run"

# List Directors who are permitted to contact Storage daemon
Director {
  Name     = laptop-dir
  Password = "TlDGBjTWkPWOS/0HN93F8ROacI3KlgIUZagdNS7+g7Up"

Device {
  Name           = FileStorage
  Media Type     = File
  Archive Device = /tmp
  LabelMedia     = yes;
  Random Access  = yes;
  AutomaticMount = yes;
  RemovableMedia = no;
  AlwaysOpen     = no;

# Send all messages to the Director,
# mount messages also are sent to the email address
Messages {
  Name     = Standard
  director = laptop-dir = all

As with the Client configuration file, the password must be supplied by the Director with the given name.

I have another Bacula installation that uses a DAT drive. I have included that device here in case it helps you.

Device {
  Name           = PythonArchive
  Media Type     = DDS-2
  Archive Device = /dev/sa1
  AutomaticMount = yes;
  AlwaysOpen     = yes;
  RemovableMedia = yes;

  # as recommended by btape
  Hardware End of Medium = No
  BSF at EOM             = yes

  Autochanger     = Yes
  Changer Device  = /dev/pass2
  Changer Command = "/usr/local/sbin/mtx-changer %c %o %S %a"

This tape drive has an auto-changer with a four-tape capacity. Note that you also must let the Director know this device contains an auto-changer. If you are going to use an auto-changer, I recommend using mtx.

Director Configuration (/usr/local/etc/bacula-dir.conf)

The Director's configuration is by necessity the largest of the daemons, defining each Client, Job, FileSet, and Storage Device. Here is my configuration. I have omitted the Schedule, Pool, and Messages resources to keep things simple. Those will be present in your default Director configuration file.

Director {
  Name                    = laptop-dir
  DIRport                 = 9101
  QueryFile               = "/usr/local/etc/query.sql"
  WorkingDirectory        = "/var/db/bacula"
  PidDirectory            = "/var/run"
  Maximum Concurrent Jobs = 1
  Password                = "lLftflC4QtgZnWEB6vAGcOuSL3T6n+P7jeH+HtQOCWwV"
  Messages                = Standard  

Job {
  Name            = "Client1"
  Type            = Backup  
  Client          = laptop-fd
  FileSet         = "Full Set"
  Schedule        = "WeeklyCycle"
  Storage         = File
  Messages        = Standard
  Pool            = Default
  Write Bootstrap = "/var/db/bacula/Client1.bsr"
  Priority        = 10

FileSet {
  Name    = "Full Set"
  Include = signature=MD5 {
# If you backup the root directory, the following two excluded
#   files can be useful
# Exclude = { /proc /tmp /.journal /.fsck }

Client {
  Name           = laptop-fd
  Address        =
  FDPort         = 9102
  Catalog        = MyCatalog
  Password       = "laptop-client-password"
  File Retention = 30 days
  Job Retention  = 6 months
  AutoPrune      = yes

# Definiton of file storage device
Storage {
  Name       = File
  Address    =
  SDPort     = 9103
  Password   = "TlDGBjTWkjTS/0HNMPF8ROacI3KlgIUZllY6NS7+gyUp"
  Device     = FileStorage
  Media Type = File  

The password in this case must match that of any connecting Console.

We have defined the Job Client1 to backup our laptop. It will backup the files defined by FileSet Full Set. The backup will be performed on the File storage device. This storage device is actually located at and is indeed a FileStorage device, which means we are backing up to disk.

For a real backup, this isn't the best solution. We're just backing up files from the laptop to somewhere else on the laptop. But it is sufficient for demonstration and testing.

Here is that DAT drive I mentioned in the Storage Devices section above.

Storage {
  Name        = PythonArchive
  Address     =
  SDPort      = 9103
  Password    = "the DDS-2 password"
  Device      = DDS-2
  Media Type  = DDS-2
  Autochanger = yes

Included in this declaration is the AutoChanger statement, which must appear in the Director's Storage resource if you want the Director to prompt you for the Slot when labeling tapes. It is not required to make the autochanger work.

Pages: 1, 2, 3

Next Pagearrow

Sponsored by: