Published on (
 See this if you're having trouble printing code examples

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:

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:

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:

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

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.

Database Setup / Reset

The official Bacula documentation covers database setup and reset, should you wish to start again with a fresh database after your initial testing.

Before you use Bacula, you need to create and define its database tables. Bacula comes with scripts to do just that. On my FreeBSD system, these files are under the port directory. Because I'm sitting in Second Cup, using my laptop, I prefer to use SQLite, instead of MySQL.

# cd /usr/ports/sysutils/bacula/work/bacula-1.32c/src/cats
# ./make_sqlite_tables

If you don't have SQLite available, Bacula provides it as a package. See the Bacula database URL above for more information. If I had MySQL installed, I could have done this instead:

# 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 the above commands and you will be prompted for the password.

You now have a working database suitable for use by Bacula. This database can be cleared out from time to time, especially as you reuse old tapes. Please refer to the Catalog Maintenance and Automatic Volume Recycling documentation. You can recycle volumes manually or automatically.

Testing Your Tape Drive

If you are not using a tape drive, you can skip this section.

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

I used btape to test my tape drive. I will be using a FreeBSD system. Please adjust the paths for your operating system. The tape drive I use is /dev/sa1, but I will actually test the non-rewinding raw device at /dev/nrsa1 instead.

The output from this command is long so I have cut out the non-essential parts. The full text is available.

# /usr/local/sbin/btape -c /usr/local/etc/bacula-sd.conf /dev/nrsa1
Tape block granularity is 1024 bytes.
btape: butil.c:149 Using device: /dev/nrsa1 for writing.

=== Append files test ===

This test is essential to Bacula.

I'm going to write one record in file 0,
two records in file 1,
         and three records
in file 2

btape: btape.c:380 Rewound /dev/nrsa1
btape: btape.c:845 Wrote one record of 64412 bytes.
btape: btape.c:847 Wrote block to device.


The above Bacula scan should have output identical to what
Please double check it ...
=== Sample correct output ===

=== End Append files test ===

The good news is no problems. The bad news, if you can call it that, is btape has some suggestions for improvement. I altered my storage device to include the following:

Hardware End of Medium = No BSF at EOM = yes

I also ran btape again to make sure it was still OK. It was. I suggest you also run this test.

Running as Non-root

It is a good idea to run daemons with the lowest possible privileges. In other words, if you can, don't run applications as root that do not have to be root. The Storage Daemon and the Director Daemon do not need to be root. The File Daemon needs to be root in order to access all files on your system. In order to run as non-root, you need to create a user and a group. Choosing bacula as both the user name and the group name sounds like a good idea to me.

The FreeBSD port creates this user and group for you (actually, as I write this, the port doesn't do that, but it soon will). Here is what those entries looked like on my FreeBSD laptop:

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

I used vipw to create this entry. I selected User and Group IDs of 1002, as they were unused on my system.

I also created a group in /etc/group:


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/

This ensures that only the bacula user can access this directory. It also means that if we run the Director and the Storage daemon as bacula, those daemons also have restricted access. This would not be the case if they were running as root.

It is important to note that the storage daemon actually needs to be in the operator group for normal access to devices such as tape drives. (At least on a FreeBSD system; that's how things are set up by default.) Such devices are normally owned by the root user and the operator group. It is easier and less error prone to make Bacula a member of that group than it is to play around with system permissions.

Starting the Bacula Daemons

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

/usr/local/etc/rc.d/ 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

Starting the Bacula Console

Bacula's console is your main interface to the Director daemon. Here you can run jobs and backup or restore manually. You can query system status, examine the Catalog contents, as well as label, mount, and unmount tapes. The Console communicates with the Bacula Director via the network, so the two programs do not need to reside on the same machine.

There are two consoles available. One runs from the command line, the other is a GNOME GUI. I will concentrate on the command line.

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 commands available with the help command. One of the first commands I issue is autodisplay on, which can be abbreviated to au on. Autodisplay will automatically display any messages from Bacula without you having to enter the messages command.

The status all command not only displays the status of each system component, it is also a quick and easy way to verify that all components are up and running and that all is well.

*status all
Using default Catalog name=MyCatalog DB=bacula
laptop-dir Version: 1.32c (30 Oct 2003) i386-portbld-freebsd4.8
freebsd 4.8-STABLE
Daemon started 02-Nov-2003 12:42, 1 Job run.
Last Job *Console*.2003-11-02_13.12.18 finished at 02-Nov-2003 13:12
Files=0 Bytes=0 Termination Status=Error
Console connected at 02-Nov-2003 13:12
No jobs are running.

Scheduled Jobs:
Level       Type    Scheduled         Name          Volume

Incremental Backup  03-Nov-2003 01:05 Client1       *unknown*
Full        Backup  03-Nov-2003 01:10 BackupCatalog *unknown*
Connecting to Storage daemon File at

laptop-sd Version: 1.32c (30 Oct 2003) i386-portbld-freebsd4.8
freebsd 4.8-STABLE
Daemon started 02-Nov-2003 12:42, 0 Jobs run.
Device /tmp is not open.
No jobs running.
Connecting to Client laptop-fd at
Failed to connect to Client laptop-fd.
02-Nov-2003 13:13 laptop-dir: *Console*.2003-11-02_13.12.48 Fatal
error: Director and File daemon passwords or names not the same.

As you can see, there is a problem with my File Daemon. That is my fault. I was running a client-only installation of Bacula on my laptop, but for this article, I installed the full server. That meant /usr/local/etc/bacula-fd.conf contained the wrong name for the Director. It was referring to another Director. Once I changed it to the correct value (laptop-fd) and restarted bacula-fd, all was well. I verified the status using this command:

Connecting to Client laptop-fd at

laptop-fd Version: 1.32c (30 Oct 2003) i386-portbld-freebsd4.8
freebsd 4.8-STABLE
Daemon started 02-Nov-2003 16:20, 0 Jobs run.
Director connected at: 02-Nov-2003 16:20
No jobs running.

We have verified that each daemon is up and running, and that the Director can contain both the Storage and the File daemon. Things are looking good!

Labeling a Volume

A Volume is either a tape or a disk. Bacula puts a label on each Volume for identification by writing a special header at the start of the Volume. In the case of tapes, you should also physically label the tape with the same name. This will allow you to identify Volumes when you need them. When the time comes to restore a particular file, Bacula will tell you what Volumes are needed.

Use the label command to label a Volume. In the following example, I'm just going to label a file store, not a tape store.

Using default Catalog name=MyCatalog DB=bacula
Automatically selected Storage: File
Enter new Volume name: estVolume1
Automatically selected Pool: Default
Connecting to Storage daemon File at
Sending label command for Volume "TestVolume1" Slot 0 ...
3000 OK label. Volume=TestVolume1 Device=/tmp
Catalog record for Volume "TestVolume1", Slot 0 successfully created.
Requesting mount FileStorage ...
3906 cannot mount non-tape.
Do not forget to mount the drive!!!

Complete documentation is available at Labeling Your Volumes.

Running a Backup Job

Bacula comes with a preset backup job that will get you started. It will backup 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.

Bacula runs jobs automatically at the time set within the Schedule resource for the Job in question. For more information, please refer to the Job Resource documentation.

Here's how to run a job manually:

A job name must be specified.
The defined Job resources are:
     1: Client1
     2: BackupCatalog
     3: RestoreFiles
Select Job resource (1-3): 1
Run Backup job
JobName:  Client1
FileSet:  Full Set
Level:    Incremental
Client:   laptop-fd
Storage:  File
Pool:     Default
When:     2003-11-02 16:30:33
Priority: 10
OK to run? (yes/mod/no): yes
Run command submitted.

If I had selected mod, I would have been able to modify any of the job parameters, such as level of backup (incremental, differential, full), use another storage device, or change the run time.

Here's the output of the job as it runs:

02-Nov-2003 16:52 laptop-dir: Start Backup JobId 2,
02-Nov-2003 16:52 laptop-sd: Volume "TestVolume1" previously
written, moving to end of data.
02-Nov-2003 16:52 laptop-dir: Bacula 1.32c (30Oct03): 02-Nov-2003
JobId:                  2
Job:                    Client1.2003-11-02_16.52.00
Backup Level:           Incremental, since=2003-11-02 16:30:40
Client:                 laptop-fd
FileSet:                "Full Set" 2003-11-02 16:30:40
Start time:             02-Nov-2003 16:52
End time:               02-Nov-2003 16:52
FD Files Written:       1,116
SD Files Written:       1,116
FD Bytes Written:       14,729,577
SD Bytes Written:       14,895,089
Rate:                   359.3 KB/s
Software Compression:   None
Volume name(s):         TestVolume1
Volume Session Id:      2
Volume Session Time:    1067808016
Last Volume Bytes:      14,946,342
Non-fatal FD errors:    0
SD Errors:              0
FD termination status:  OK
SD termination status:  OK
Termination:            Backup OK

02-Nov-2003 16:52 laptop-dir: Begin pruning Jobs.
02-Nov-2003 16:52 laptop-dir: No Jobs found to prune.
02-Nov-2003 16:52 laptop-dir: Begin pruning Files.
02-Nov-2003 16:52 laptop-dir: No Files found to prune.
02-Nov-2003 16:52 laptop-dir: End auto prune.


This information will also be sent to you via email, depending on the settings within your Director configuration file. (Look for the Messages resource). You will notice that this backup was JobId 2. What happened to Job 1? When I first ran this job, it failed because the directory specified in the FileSet did not exist. I created and populated the directory, and then re-ran the job, which produced the output shown above.

Restoring Files

Here's a simple restore job. Bacula includes one by default. You can use it for just about anything.

In the following example, I will restore the entire file set, demonstrating how to be selective about what files are restored. I will do a few directory listings so you can see how that works.

Using default Catalog name=MyCatalog DB=bacula

First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.

To select the JobIds, you have the following choices:
     1: List last 20 Jobs run.
     2: List Jobs where a given File is saved.
     3: Enter list of JobIds to select.
     4: Enter SQL list command.
     5: Select the most recent backup for a client.
     6: Select backup for a client before a specified time.
     7: Enter a list of files to restore.
     8: Enter a list of files to restore before a specified time.
     9: Cancel.
Select item:  (1-9): 3
Enter JobId(s), comma separated, to restore: 2
You have selected the following JobId: 2
Building directory tree for JobId 2 ...
1 Job inserted into the tree and marked for extraction.
Automatically selected Storage: File

You are now entering file selection mode where you add and
remove files to be restored. All files are initially added.
Enter "done" to leave this mode.

cwd is: /
$ ls
$ cd usr
cwd is: /usr/
$ ls
$ cd ports/sysutils
cwd is: /usr/ports/sysutils/
$ ls
$ cd bacula/work/
cwd is: /usr/ports/sysutils/bacula/work/
$ ls
$ cd bacula-1.32c
cwd is: /usr/ports/sysutils/bacula/work/bacula-1.32c/
$ ls
$ done
Bootstrap records written to /var/db/bacula/restore.bsr

The restore job will require the following Volumes:


1116 files selected to restore.

Automatically selected Client: laptop-fd
Run Restore job
JobName:    RestoreFiles
Bootstrap:  /var/db/bacula/restore.bsr
Where:      /tmp/bacula-restores

Replace:    always
FileSet:    Full Set
Client:     laptop-fd
Storage:    File
When:       2003-11-02 16:59:53
Priority:   10
OK to run? (yes/mod/no): yes
Run command submitted.
Restore command done.

Again, as with the running of a job, if I had selected mod instead of yes, I would have been able to modify any of the job parameters, including the path to which the files should be restored. You should choose the restore location carefully, to ensure there is sufficient disk space available.

The output from this job is rather long, listing every file restored, so I won't include it here. That is the default action, but you can change it in the configuration file.

The restored files are at /tmp/bacula-restores. 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 \

No differences. That's rather convenient, considering I just did a backup and restore. I would be concerned if there was a difference.

This was just a simple example. Bacula has a chapter devoted to the restore command.

Creating Backup Schedules

Bacula comes preset with a simple backup schedule. You can use that or create new Schedules to meet demand. The Director configuration documentation is useful for that task. For my testing, I wanted to backup 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:

You can go wild with this scheduling, creating whatever frequency you need. But as you can see, one schedule, for one job, can create many different instances of that combination. You can backup as frequently as you need with the level of backup that's right for you.

If you are wondering what the different types of backups mean, please read the Level documentation in the Director configuration documentation.

Creating a Client-only Install

So far we have tested Bacula on the server. In this section I will install the Bacula client on a client machine. I will also show you the changes you need to make to the Bacula server.

With the FreeBSD port, installing a client-only version of Bacula is done with this command:

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

If you are manually compiling from source, look at the --enable-client-only option documented in the Installing Bacula documentation.

A simple solution, if the platforms are the same, is to copy the bacula-fd binary and bacula-fd.conf configuration file from one box to another. Don't forget to copy the startup file too.

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.

The Bacula documentation has a section on Adding a Second Client.

Remember to restart the daemons when you make changes to the Bacula configuration files. For a FreeBSD system, this is easiest done with this command:

# /usr/local/etc/rc.d/ 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

If that script does not exist on your computer, you will need to copy it from another.

Security Considerations

The security considerations for Bacula are pretty simple. Essentially, you want to ensure that the Bacula database files are not world-writable. The configuration files should not be world-readable. The Bacula ports should be protected from untrusted networks. You can also run the daemons as non-root, as outlined previously in this article, by using the -u and -g command line options.

Suggested Reading

I have not talked about Catalogs or Pools. A Catalog Resource defines what catalog should be used for a given job. You could have a catalog for each Client.

A Pool Resource defines the set of Volumes that can be used for a backup. This gives you the ability to store all incremental backups on one set of Volumes and all full backups on another set. You can do this by defining the Pools accordingly.

Bacula: A Solution with Wide Applications

I was first told about Bacula by an acquaintance on IRC. I don't recall the original discussion, but I immediately became interested in the application. Since that brief conversation six months ago, I've come to appreciate the simplicity of Bacula and the complex solutions that can be created with just a few components. The ability to use multiple Directors and multiple Storage Devices makes for a powerful combination.

Over that time, I've come to see how the Bacula community supports new people and how problems are quickly resolved. I feel this is imporant with any project. The Bacula mailing lists are low volume, with good responses to questions.

I've found Bacula to be ideal for backing up my small network of about a dozen computers. Whether you have one computer or hundreds, Bacula can give you the backups you need with the flexibility you want.

Dan Langille runs a consulting group in Ottawa, Canada, and lives in a house ruled by felines.

Return to the

Copyright © 2009 O'Reilly Media, Inc.