Bacula: backups that don’t suck

Good systems administrators know that implementing a robust backup procedure is one of their most important duties. Unfortunately, it’s also one of the most complex and least fun. When the phone rings and there’s a panic-stricken user on the other end who has just lost a crucial document, you need to be confident that you can promptly recover his missing files. Failure to do so can bring about a speedy end to a promising career in systems administration. So what’s a budding sysadmin to do? Download the latest release of Bacula and watch those backup woes disappear into the dark of night.

Led by head developer Kern Sibbald, the Bacula team has built an open source backup solution that is fast, reliable, and exceptionally configurable. Bacula is not a monolithic application, but rather a collection of programs that together provide a robust backup, recovery, and verification toolset suitable for five or 500 systems.

Getting started

For this review we tested Bacula on a single CentOS 4 server using the file system as our backup medium. In our production environment we use Bacula to manage more than 500GB of backups from multiple clients using a tape robot. However, the lengthy process of configuring the tape robot and multiple clients makes this a daunting task for the first-time user. We recommend you stick with a single host for your test drive if you’ve not worked with Bacula before.

Bacula is available as a package using the standard package management tools yum or apt-get, but we prefer to install the application from source. When you’re just getting started with Bacula, building from source gives you a better feel for how the application operates.

After downloading and uncompressing the project’s source code you’ll need to run the configure script. Bacula’s configure script is well written and produces meaningful debug output but requires a large number of command-line settings. To simplify the configuration process the development team has included a suggested list of options that handle most environments. Start with these settings and modify them where appropriate. Case in point: the choice of database. Bacula is a database-driven application and requires MySQL, SQLite, or PostgreSQL. Make sure you have one of these databases installed prior to configuring Bacula. Once you’ve run the configure script, you can build Bacula using the normal make; make install process.

Next, you must create the Bacula database and tables and set appropriate access permissions. Located in Bacula’s bin directory, the script create_bacula_database will create Bacula’s database after determining what database you are using. After a successful termination of this script, executing make_bacula_tables will create and populate the database tables. Finally, grant_bacula_privileges will establish the necessary access controls. A word of warning: grant_bacula_privileges creates an unrestricted access policy for the user bacula. You should modify this policy to suit your needs. At a minimum you should consider setting passwords for the MySQL users root and bacula.

After successfully building and installing Bacula, the next step is setting up the config files. That can take some time, but once you’ve gotten them working you won’t have to touch them again except when you add a new client or fileset.

To understand the configuration files, you need to understand how Bacula operates. Bacula comprises four main modules: the director, the storage daemon, the file daemon, and the console. The director is the “boss” of Bacula, providing job scheduling, backup media descriptions, and access control. In a typical Bacula deployment there is only one director.

The storage daemon handles all communications with the defined backup architecture: disks, single tape drives, tape robots, and optical drives. As with the director, there is usually only one storage daemon running per Bacula installation, but the storage daemon may have many backup devices defined.

The file daemon is installed on each client machine and provides the communications link between the storage daemon and the client. It needs access to all files that will be backed up on that client.

The console handles communications between the administrator and Bacula. The adminstrator can start or stop jobs, estimate backup sizes, and review messages from Bacula. Consoles are available that use wxWidgets, GNOME, and Web browsers, but we prefer the TTY version of bconsole.

The bacula-dir.conf file, which controls the director, contains detailed information on the clients to be backed up, job definitions, filesets, and job schedules. One of the outstanding features of Bacula is how close the configuration files as supplied come to being ready to rumble. While a large installation with many clients will require significant editing to the configuration files, our test of Bacula required us to only to give Bacula a list of files to back up.

Bacula typically installs to a subdirectory named bacula in the home directory of the user that is deploying the software. The configuration files are located in the bin subdirectory of /home/user/bacula. Switch to this directory and edit bacula-dir.conf. Search for the section of text beginning with “# By default this is defined to point to the Bacula build directory to give a reasonable FileSet to backup to disk storage during initial testing.” Directly below these lines should be: File = /home/username/bacula/bacula-2.2.8. This is the FileSet definition, which controls what files and directories are to be backed up. You may change this definition to a directory of your choice or leave it as is during testing.

Your first backup

By default Bacula uses the filesystem as its backup media. To keep things simple we won’t attempt to configure Bacula to use a tape drive — we’ll stick with the preconfigured definitions.

Change directories to Bacula’s bin folder. Execute the bacula script with start as an argument: ./bacula start. You should see the following three lines:

If Bacula successfully started, that’s great — you’re ready to run your first backup. If not, carefully read the error messages and double-check the bacula-dir.conf file. Make sure you’ve pointed Bacula to the directory you wish to be backed up and that the directory exists and is readable.

The final step in taking Bacula for a test drive is using the console to initiate the job. From the Bacula bin directory execute the bconsole script. Bconsole should return an asterisk prompt. At the prompt enter run. Bconsole will display a list of defined jobs for you to pick from. Since we’re only backing up one machine (our test box) you should only have one job resource to choose from. Select the job and press Enter. Bacula will prompt you with a short list of settings, including client name, backup type (full, differential, or incremental) and the storage device. If all the settings look correct, enter yes to kick off the backup.

After a short wait, Bacula should return a “backup completed successfully” message with details including the file(s) backed up, the amount of space the backup consumed, compression ratios, and so on. Congratulations — you’ve just run your first Bacula backup.

Only the beginning

Of course at this point we’ve barely scratched the surface of Bacula’s many features — the user manual is 665 pages long. New users should read the excellent tutorial before embarking on a multi-client Bacula installation.

Despite its apparent complexity, Bacula is straightforward to install and configure, comes with excellent documentation, and works right out of the box. If you have been considering moving from basic tar or rdump backup processes to a more substantial package, you can’t go wrong by choosing Bacula. It definitely doesn’t suck.