Hack 41 Perform Client-Server Cross-Platform Backups with Bacula

Don't let the campy name fool you. Bacula is a powerful, flexible, open source backup program. .

Having problems finding a backup solution that fits all your needs? One that can back up both Unix and Windows systems? That is flexible enough to back up systems with irregular backup needs, such as laptops? That allows you to run scripts before or after the backup job? That provides browsing capabilities so you can decide upon a restore point? Bacula may be what you're looking for.

4.8.1 Introducing Bacula

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

Director: 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.
Client/File Daemon: The Client (or File) Daemon runs on each computer which will be backed up by the Director. Some other backup solutions refer to this as the Agent.
Storage Daemon: The Storage Daemon communicates with the backup device, which may be tape or disk.
Console: 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 FileSets and Jobs. A FileSet identifies a set of files to back up. 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 and restore jobs can be run automatically or manually.

4.8.2 Installation

Bacula stores details of each backup in a database. You can use either SQLite or MySQL, and starting with Bacula Version 1.33, PostgreSQL. Before you install Bacula, decide which database you want to use.

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

The existing Bacula documentation provides detailed installation instructions if you're installing from source. To install instead the SQLite version of the FreeBSD port:

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

Or, if you prefer to install the MySQL version:

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

Don't use the clean target with your make command, because there are some scripts in the work directory you'll need to use.

4.8.3 Configuration Files

Bacula installs several configuration files that should work for your environment with few modifications.

4.8.3.1 File Daemon on the backup client

The first configuration file, /usr/local/etc/bacula-fd.conf, is for the File Daemon. This file needs to reside on each machine you want to back up. For security reasons, only the Directors specified in this file will be able to communicate with this File Daemon. The name and password specified in the Director resource must be supplied by any connecting Director.

You can specify more than one Director { } resource. Make sure the password matches the one in the Client resource in the Director's configuration file.

The FileDaemon { } resource identifies this system and specifies the port on which it will listen for Directors. You may have to create a directory manually to match the one specified by the Working Directory.

4.8.3.2 Storage Daemon on the backup server

The next configuration file, /usr/local/etc/bacula-sd.conf, is for the Storage Daemon. The default values should work unless you need to specify additional storage devices.

As with the File Daemon, the Director { } resource specifies the Director(s) that may contact this Storage Daemon. The password must match that found in the Storage resource in the Director's configuration file.

4.8.3.3 Director on the backup server

The Director's configuration is by necessity the largest of the daemons. Each Client, Job, FileSet, and Storage Device is defined in this file.

In the following example configuration, I've defined the Job Client1 to back up the files defined by the FileSet Full Set on a laptop. The backup will be performed to the File storage device, which is really a disk located at laptop.example.org.

This isn't an optimal solution for a real backup, as I'm just backing up files from the laptop to somewhere else on the laptop. It is sufficient for demonstration and testing, though.

# more /usr/local/etc/bacula-dir.conf   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 {       /usr/ports/sysutils/bacula/work/bacula-1.32c     }   # If you backup the root directory, the following two excluded   #   files can be useful   #     Exclude = { /proc /tmp /.journal /.fsck }   }   Client {     Name           = laptop-fd     Address        = laptop.example.org     FDPort         = 9102     Catalog        = MyCatalog     Password       = "laptop-client-password"     File Retention = 30 days     Job Retention  = 6 months     AutoPrune      = yes   }   # Definition of file storage device   Storage {     Name       = File     Address    = laptop.example.org     SDPort     = 9103     Password   = "TlDGBjTWkjTS/0HNMPF8ROacI3KlgIUZllY6NS7+gyUp"     Device     = FileStorage     Media Type = File   }

Note that the password given by any connecting Console must match the one here.

4.8.4 Database Setup

Now that you've modified the configuration files to suit your needs, use Bacula's scripts to create and define the database tables that it will use.

To set up for MySQL:

# cd /usr/ports/sysutils/bacula/work/bacula-1.32c/src/cats # ./grant_mysql_privileges # ./create_mysql_database # ./make_mysql_tables

If you have a password set for the MySQL root account, add -p to these commands and you will be prompted for the password. You now have a working database suitable for use by Bacula.

4.8.5 Testing Your Tape Drive

Some tape drives are not standard. They require their own proprietary software and can be temperamental when used with other software. Regardless of what software it uses, each drive model can have its own little quirks that need to be catered to. Fortunately, Bacula comes with btape, a handy little utility for testing your drive.

My tape drive is at /dev/sa1. Bacula prefers to use the non-rewind variant of the device, but it can handle the raw variant as well. If you use the rewinding device, then only one backup job per tape is possible. This command will test the non-rewind device /dev/nrsa1:

# /usr/local/sbin/btape -c /usr/local/etc/bacula-sd.conf /dev/nrsa1

4.8.6 Running Without Root

It is a good idea to run daemons with the lowest possible privileges. The Storage Daemon and the Director Daemon do not need root permissions. However, the File Daemon does, because it needs to access all files on your system.

In order to run daemons with nonroot accounts, you need to create a user and a group. Here, I used vipw to create the user. I selected a user ID and group ID of 1002, as they were unused on my system.

bacula:*:1002:1002::0:0:Bacula Daemon:/var/db/bacula:/sbin/nologin

I also added this line to /etc/group:

bacula:*:1002:

The bacula user (as opposed to the Bacula daemon) will have a home directory of /var/db/bacula, which is the default location for the Bacula database.

Now that you have both a bacula user and a bacula group, you can secure the bacula home directory by issuing this command:

# chown -R bacula:bacula /var/db/bacula/

4.8.7 Starting the Bacula Daemons

To start the Bacula daemons on a FreeBSD system, issue the following command:

# /usr/local/etc/rc.d/bacula.sh start

To confirm they are all running:

# ps auwx | grep bacula root 63416 0.0 0.3 2040 1172 ?? Ss 4:09PM 0:00.01     /usr/local/sbin/bacula-sd -v -c /usr/local/etc/bacula-sd.conf root 63418 0.0 0.3 1856 1036 ?? Ss 4:09PM 0:00.00     /usr/local/sbin/bacula-fd -v -c /usr/local/etc/bacula-fd.conf root 63422 0.0 0.4 2360 1440 ?? Ss 4:09PM 0:00.00     /usr/local/sbin/bacula-dir -v -c /usr/local/etc/bacula-dir.conf

4.8.8 Using the Bacula Console

The console is the main interface through which you run jobs, query system status, and examine the Catalog contents, as well as label, mount, and unmount tapes. There are two consoles available: one runs from the command line, and the other is a GNOME GUI. I will concentrate on the command-line console.

To start the console, I use this command:

#  /usr/local/sbin/console -c /usr/local/etc/console.conf Connecting to Director laptop:9101 1000 OK: laptop-dir Version: 1.32c (30 Oct 2003) *

You can obtain a list of the available commands with the help command. The status all command is a quick and easy way to verify that all components are up and running. To label a Volume, use the label command.

Bacula comes with a preset backup job to get you started. It will back up the directory from which Bacula was installed. Once you get going and have created your own jobs, you can safely remove this job from the Director configuration file.

Not surprisingly, you use the run command to run a job. Once the job runs, the results will be sent to you via email, according to the Messages resource settings within your Director configuration file.

To restore a job, use the restore command. You should choose the restore location carefully and ensure there is sufficient disk space available.

It is easy to verify that the restored files match the original:

# diff -ruN \   /tmp/bacula-restores/usr/ports/sysutils/bacula/work/bacula-1.32c \   /usr/ports/sysutils/bacula/work/bacula-1.32c #

4.8.9 Creating Backup Schedules

For my testing, I wanted to back up files on my Windows XP machine every hour. I created this schedule:

Schedule {   Name = "HourlyCycle"   Run  = Full 1st sun at 1:05   Run  = Differential 2nd-5th sun at 1:05   Run  = Incremental Hourly }

Any Job that uses this schedule will be run at the following times:

A full backup will be done on the first Sunday of every month at 1:05 AM.
A differential backup will be run on the 2nd, 3rd, 4th, and 5th Sundays of every month at 1:05 AM.
Every hour, on the hour, an incremental backup will be done.

4.8.10 Creating a Client-only Install

So far we have been testing Bacula on the server. With the FreeBSD port, installing a client-only version of Bacula is easy:

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

You will also need to tell the Director about this client by adding a new Client resource to the Director configuration file. You will also want to create a Job and FileSet resource.

When you change the Bacula configuration files, remember to restart the daemons:

# /usr/local/etc/rc.d/bacula.sh restart Stopping the Storage daemon Stopping the File daemon Stopping the Director daemon Starting the Storage daemon Starting the File daemon Starting the Director daemon #

4.8.11 See Also

The Bacula web site (http://www.bacula.org/)
http://www.onlamp.com/pub/a/onlamp/2004/01/09/bacula.html (the original Bacula article from ONLamp)