Bacula Tapes Bacula is an open-source, enterprise-level computer backup system for heterogeneous networks. Bacula is by far the most popular Open Source backup program. It is designed to automate backup tasks that had often required intervention from a systems administrator or computer operator. Bacula supports Linux, UNIX, Windows, and macOS backup clients, and a range of professional backup devices including tape libraries.

Bacula is a vast program, entailing the initial configuration of the server and its daemons, preparing media and day to day operation. In the next 4 posts I will cover the initial configuration to provide a system that will retain backups for a full 12 months. The fifth and final post I will cover preparing media. Day to day operation, I feel, is not one of those things that can be learnt in books, and need hands on experience. However, with the system configured, you will be in a perfect position to gain this experience.

Throughout the posts I will shamelessly quote the main Bacula Documentation as I see no sense in duplicating the good work that has already been done by the Bacula team. However, I will also go into detail where necessary to point out parts that I feel need extra explanation, relative to the configurations I have made.

Objectives & Requirements

The objective is to have full backups that we can restore from for a time period of the last 12 months

The schedule that I will follow to achieve this is as follows:

  • Monthly Full backup, with a retention period of just under 12 months, This will require a minimum number of 12 backup volumes.
  • Weekly Differential backup against the monthly full backup, with a retention period of just under 1 month. This will require a minimum number of 4 backup volumes.
  • Daily Incremental backup against the previous backup (whether it be full, differential or incremental), with a retention period of 2 weeks. This will require a minimum number of 12 backup volumes.

bacula-dir.conf

The bacula-dir.conf controls the Director daemon. I have arranged the configuration file into an extremely simple configuration that simply points to smaller configuration files that will be included and run on the daemon startup. With so many modules of the daemon to consider and it all being only expressed on your screen in text, I have made the bacula-dir.conf file more of a visual representation of the parts that constitute the daemon. All the configuration details are hidden away where we can deal with them later, one at a time, so as not to get overwhelmed.

For now the various Bacula resources are declared as Includes files, with the syntax of @filename. 18.2.3

bacula-dir.conf

# general settings -----------------------------------------------------------

# definition of director
@/usr/local/etc/bacula/Includes/director.conf

# definition of catalog 
@/usr/local/etc/bacula/Includes/catalog.conf

# definition of how messages from bacula are handled
@/usr/local/etc/bacula/Includes/messages.conf

# storage settings -----------------------------------------------------------

# definition of storage daemons
@/usr/local/etc/bacula/Includes/storage.conf

# definition of storage volumes
@/usr/local/etc/bacula/Includes/pools.conf

# clients settings -----------------------------------------------------------

# definition of which clients to backup
@/usr/local/etc/bacula/Includes/clients.conf

# definition of which files on clients to backup
@/usr/local/etc/bacula/Includes/filesets.conf

# backups settings -----------------------------------------------------------

# definition of which jobs to run
@/usr/local/etc/bacula/Includes/jobs.conf

# definition of when to run the jobs
@/usr/local/etc/bacula/Includes/schedules.conf

… so far, so good.

General Bacula Configuration

This section pertains to the settings in Bacula that are system wide, such as the director, catalog & messaging.

Define Director

The Director resource defines the attributes of the Directors running on the network. In the resource the Director’s name and its access password used for authenticating the Console program is declared. Only a single Director resource definition may appear in the Director’s configuration file.

Includes/director.conf

Director {
  Name =                     bacula.pbdigital.org-dir
  DIRport =                  9101
  QueryFile =                "/usr/local/share/bacula/query.sql"
  WorkingDirectory =         "/var/db/bacula"
  PidDirectory =             "/var/run"
  Maximum Concurrent Jobs =  20
  Password =                 "secret"
  Messages =                 Daemon
}

Of note I will outline the following directives:

  • Name - The director name used by other modules of Bacula to reference. I use the convention of hostname-dir.

  • DIRport - This is a registered IANA port of the Director. Unless you have a very specific use case, you should probably not change this.

  • QueryFile - Location of canned SQL statements for the Query command of the Console.

  • WorkingDirectory - The directory in which the Director may put its status files.

  • Password - Specifies the password that bconsole must use to connect to the director.

  • Messages - Specifies where to deliver Director messages that are not associated with a specific Job.

For more details see The Director Resource [19.2].

Define Catalog

The Catalog Resource defines what catalog to use for the jobs that are run.

In a more complex installation of Bacula, there may be as many Catalogs (databases) defined as you wish. For example, you may want each Client to have its own Catalog database, or you may want backup jobs to use one database and verify or restore jobs to use another database. This is beyond the scope of this tutorial.

Includes/catalog.conf

Catalog {
  Name =        MyCatalog
  dbaddress =   "127.0.0.1"
  dbname =      "bacula"
  dbuser =      "bacula"
  dbpassword =  "secret"
}

Of note I will outline the following directives:

  • Name - The name of the Catalog. This is no necessary relation to the database server name. This name will be specified in the Client resource directive indicating that all catalog data for that Client is maintained in this Catalog.

  • dbaddress - Host address of database server. This directive is optional. If not specified, Bacula will connect to local host.

  • dbname - This specifies the name of the database.

  • dbuser - This specifies what user name to use to log into the database.

  • dbpassword - This specifies the password to use when logging into the database.

NOTE! The directives dbaddress, dbname, dbuser & dbpassword are not listed in the Bacula manuals, however they are used in the current sample configuration files.

For more details see The Catalog Resource [19.17].

Define Messages

The Messages resource defines how messages are to be handled and destinations to which they should be sent.

Even though each daemon has a full message handler, within the File daemon and the Storage daemon, you will normally choose to send all the appropriate messages back to the Director. This permits all the messages associated with a single Job to be combined in the Director and sent as a single email message to the user, or logged together in a single file.

Each message that Bacula generates (i.e. that each daemon generates) has an associated type such as INFO, WARNING, ERROR, FATAL, etc. Using the message resource, you can specify which message types you wish to see and where they should be sent. In addition, a message may be sent to multiple destinations. For example, you may want all error messages both logged as well as sent to you in an email. By defining multiple messages resources, you can have different message handling for each type of Job (e.g. Full backups versus Incremental backups).

In general, messages are attached to a Job and are included in the Job report. There are some rare cases, where this is not possible, e.g. when no job is running, or if a communications error occurs between a daemon and the director. In those cases, the message may remain in the system, and should be flushed at the end of the next Job. However, since such messages are not attached to a Job, any that are mailed will be sent with the mail daemon that Bacula uses.

Includes/messages.conf

Messages {
  Name =             Standard
  mailcommand =      "/usr/local/sbin/bsmtp -h localhost -f \"no-reply@pbdigital.org\" -s \"Bacula: %t %e of %c %j %l\" %r"
  operatorcommand =  "/usr/local/sbin/bsmtp -h localhost -f \"no-reply@pbdigital.org\" -s \"Bacula: Intervention needed for %j\" %r"
  mail =             root@bacula.pbdigital.org = all, !skipped
  operator =         root@bacula.pbdigital.org = mount
  console =          all, !skipped, !saved
  append =           "/var/log/bacula.log" = all, !skipped
  catalog =          all
}

# Message delivery for daemon messages (no job).
Messages {
  Name =             Daemon
  mailcommand =      "/usr/local/sbin/bsmtp -h localhost -f \"no-reply@pbdigital.org\" -s \"Bacula: Daemon Message\" %r"
  mail =             root@bacula.pbdigital.org = all, !skipped
  console =          all, !skipped, !saved
  append =           "/var/log/bacula.log" = all, !skipped
}

Of note I will outline the following directives:

  • Name - The name of the Messages resource. The name you specify here will be used to tie this Messages resource to a Job and/or to the daemon.

  • mailcommand - Specify exactly how to send mail from your Bacula system with the mailcommand directive. I have implemented a singular return address (no-reply@pbdigital.org) as described in the following note.

NOTE! If you use the mailcommand directive to send to two or more email addresses, you will need to replace the %r in the from field (-f part) with a single valid email address in both the mailcommand and the operatorcommand. What this does is, it sets the email address that emails would display in the FROM field, which is by default the same email as they’re being sent to. However, if you send email to more than one address, then you’ll have to set the FROM address manually, to a single address. For example, a ‘no-reply@mydomain.com’, is better since that tends to tell (most) people that its coming from an automated source.

  • operatorcommand - This resource specification is similar to the mailcommand except that it is used for Operator messages.

  • mail - Send the message to the email addresses that are given as a comma separated list in the address field. Mail messages are grouped together during a job and then sent as a single email message when the job terminates. The advantage of this destination is that you are notified about every Job that runs.

  • operator - Send the message to the email addresses that are specified as a comma separated list in the address field. This is similar to mail above, except that each message is sent as received. Thus there is one email per message.

NOTE!: If you look closely above in messages.conf , the operator directive has been set to only send mount messages.

  • console - Send the message to the Bacula console.

  • append - Append the message to the filename given in the address field. If the file already exists, it will be appended to. If the file does not exist, it will be created.

WARNING! Using the append directive as we have will create a file that you must cycle from time to time as it will grow indefinitely. However, it will also keep all your messages if they scroll off the console.

  • catalog - Send the message to the Catalog database. The message will be written to the table named Log and a timestamp field will also be added. This permits Job Reports and other messages to be recorded in the Catalog so that they can be accessed by reporting software.

For more details see The Message Resource [22].

Wrapping Up

At the moment we are still a long way from starting up Bacula, but we will progress surely in the following posts. Next I will discuss the storage side of Bacula; the storage resource and the pools resource. You can jump to it here.