The FreeBSD Diary
Providing practical examples since 1998If you buy from Amazon USA, please support us by using this link.
Bacula: Cross-Platform Client-Server Backups 1 February 2004
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.
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:
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:
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
The above will install an SQLite version of Bacula. You can install
the MySQL version by specifying
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 (
Database setup / reset
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.
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, then I could have done this instead
If you have a password set for the mysql root account, add
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 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.
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
The output from this command is long so I have cut out the non-essential parts. The full text is available.
The good news is no problems. The bad news, if you can call it that, is
btape has made some suggestions for improvement. I altered my storage
device to include the following:
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 which 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.
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:
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:
The bacula user (as opposed to the Bacula daemon) will have a home
Now that you have both a bacula user and a bacula group, you can secure the bacula home directory by issuing this command:
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 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.
Starting the Bacula daemons
To start the bacula daemons on a FreeBSD system, issue the following commands:
You will also need these directives in /etc/rc.conf:
To confirm they are all running:
Starting the Bacula console
The console is your main interface to the
Bacula Director daemon. It
is through the console that you can run jobs, either 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; therefore 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 be concentrating on the command line.
To start the console, I use this command:
You can obtain a list of the command available with the
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
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 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.
Complete documentation is available at
Labeling Your Volumes.
Running a backup job
Bacula comes with a preset backup job which 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
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:
If I had selected
Once the job runs, here's what the output looks like:
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.
The following is a simple restore job. One is included with Bacula by
default. You can use it for just about anything.
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.
Again, as with the running of a job, if I had selected
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
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.
Creating backup Schedules
Bacula comes preset with a simple backup schedule. You can use that or
create any number of new Schedules to meet demand. The
is useful for that task.
For my testing, I wanted to backup files on my Windows XP machine every hour. I created this schedule:
Any Job which 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, and with the level of backup that's right for you.
If you are wondering what the different types of backups mean, please
Creating a client-only install
So far we have been testing 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:
If you are manually compiling from source, look at the
A simple solution, if the platforms are the same, is to copy the
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:
If that script does not exist on your computer, you will need to copy it from
The security considerations
for Bacula are pretty simple. Essentially you want to ensure 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
-g command line options.
I have not talked about Pools
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.
Creating multiple client configuration files
|I created a script to simplify the process of creating multiple client configuration files. You can find that in the samples.
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 6 months ago, I've come to
appreciate the simplicity of Bacula and the complex solutions which
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 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.