The FreeBSD Diary

This article originally appeared on the ONLamp website.

Backup solutions are many and varied. Make sure you choose the right backup software. When people go looking for Open Source backup solutions, Amanda is usually mentioned first. When I started looking for a backup solution, 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.

• support for multiple platforms, including windows clients
• use tape and/or disk as storage devices
• schedule different jobs at different times/days
• backups 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

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

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 decides the tapes required and you supply them. Or, 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:

• 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 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.

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 which 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. Do not make them world-readable. A CRAM-MD5 authentication is used so no passwords are exchanged on the network.

NOTE: There are no special steps to create a password. It is plain random text. Just make up something.

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.

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 whatever machine you want. 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.

The Bacula server is supported on multiple platforms:

• Linux (Gentoo, SuSE, Mandrake, Debian, RedHat, ...)
• Solaris
• FreeBSD
• OSX/Darwin (see http://fink.sourceforge.net/)

• Windows (Win95/98/Me, WinNT/2K/XP)
• OpenBSD
• FreeBSD
• Irix
• Said to work on other systems (AIX, BSDI, ...)

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 (but only until the PostgreSQL port is available; it will come with a conversion script).

I won't provide detailed installation instructions, as that is well covered by the existing Bacula documentation. 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 which 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

After installing, customization of the configuration files is the next step.

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 further customize your configuration to suit your own needs. The default install for Bacula should be enough to get you started. All I will be doing is highlighting a few items to point you in the right direction.

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

The following is the configuration used on my laptop. This defines the File Daemon (or client) which 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
}

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

I really like the way Bacula has a 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 which 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/nsa1
  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 a auto-changer with a capacity of 4 tapes. 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. Each Client, Job, FileSet, and Storage Device is defined in this file. Here is what is in my installation. Not shown here are the Schedule, Pool, and Messages resources. Those will be present in your default Director configuration file but I have omitted them to keep things simple.

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
}

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

The password in this case is the one which must match the password 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 laptop.example.org 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 above in the Storage Devices section.

Storage {
  Name        = PythonArchive
  Address     = undef.example.org
  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.

The official 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 the tables that it needs to use. 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

# 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.

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 their own little quirks which need to be catered for.

To complicate matters even more, each operating system can have its own little quirks. What works on one OS may not work on another.

Fortunately, Bacula comes with a handy little utility for testing your drive.

btape is what I used 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/nsa1 but I will actually test the non-rewinding and raw device instead: /dev/nrsa1.

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.
*test


=== 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.

[snip]

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

=== End Append files test ===
*

   Hardware End of Medium = No
   BSF at EOM = yes

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:Bacula Daemon:/var/db/bacula:/sbin/nologin

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

I also created a group in /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/

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

/usr/local/etc/rc.d/bacula-dir start
/usr/local/etc/rc.d/bacula-sd start
/usr/local/etc/rc.d/bacula-fd start

bacula_dir_enable="YES"
bacula_sd_enable="YES"
bacula_fd_enable="YES"

$ 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


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

To start the console, I use this command:

$ bconsole
Connecting to Director laptop:9101
1000 OK: laptop-dir Version: 1.32c (30 Oct 2003)
*

You can obtain a list of the command available with the help command. One of the first commands I issue is autodisplay on, which can be abbreviated to au on. Turning on autodisplay means that any messages from Bacula are displayed automatically without you entering 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.example.org:9103

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 laptop.example.org:9102
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:

*status client=laptop-fd
Connecting to Client laptop-fd at laptop.example.org:9102

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.
====
*

A Volume is either a tape or a disk. Bacula puts a label on each Volume so it can identify it. Bacula does this 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 quickly identify Volumes when they are needed, either for backup or for restore. When the time comes to restore a particular file, Bacula will tell you what Volumes are needed.

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

*label
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 laptop.example.org:9103 ...
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!!!

Jobs are run automatically by Bacula at the time set out within the Schedule resource for the Job in question. For more information, please refer to the Job Resource documentation.

The following is the procedure to manually run a job:

*run
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.

Once the job runs, here's what the output looks like:

*
02-Nov-2003 16:52 laptop-dir: Start Backup JobId 2, Job=Client1.2003-11-02_16.52.00
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 16:52
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 upon 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.

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

*restore
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
usr/
$ cd usr
cwd is: /usr/
$ ls
ports/
$ cd ports/sysutils
cwd is: /usr/ports/sysutils/
$ ls
bacula/
$ cd bacula/work/
cwd is: /usr/ports/sysutils/bacula/work/
$ ls
*bacula-1.32c/
$ cd bacula-1.32c
cwd is: /usr/ports/sysutils/bacula/work/bacula-1.32c/
$ ls
*autoconf/
*.cvsignore
*ABOUT-NLS
*COPYING
*ChangeLog
*CheckList
*INSTALL
*Makefile.in
*README
*README.AIX
*ReleaseNotes
*VERIFYING
*configure
*kernstodo
*doc/
*examples/
*intl/
*platforms/
*po/
*rescue/
*scripts/
*src/
*configure.bak
*configure.lineno
*config.log
*config.status
*config.out
*Makefile
$ done
Bootstrap records written to /var/db/bacula/restore.bsr

The restore job will require the following Volumes:

   TestVolume1


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 and ensure there is sufficient disk space available.

The output from this job is rather long and will not be included here. It lists every file restored. That is the default action, but you can change that 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 /usr/ports/sysutils/bacula/work/bacula-1.32c
#

No differences were found. 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.

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
}

• 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 the month at 1:05 AM.
• Every hour, on the hour, an incremental backup will be done.

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, and 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.

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.

It is important to remember that when you make changes to the Bacula configuration files, you must restart the daemons which use those files. For a FreeBSD system, this is easiest done with this command:

# /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
#

A Pool Resource defines the set of Volumes which 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.

A Catalog Resource defines what catalog should be used for a given job. You could have a catalog for each Client.

Over that time, I've come to see how the Bacula community supports new people and how problems are quickly resolved. I feel that is imporant with any project. The 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.

This is a list of things I like to keep track of.

• script for creating many client FDs
• Script for initiating a job via web page - I don't know where this is!
• Reporting job status for multiple clients