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.

Today I will look at configuring the Jobs & Schedules resources. These are part of the bacula-dir.conf file. These are responsible for the running of the backups; the Jobs define who and what to back up and the Schedule defines when to backup.

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.

BACKUPS SECTION

Jobs Resource

The Job resource defines a Job (Backup, Restore, …) that Bacula must perform. Each Job resource definition contains the name of a Client and a FileSet to backup, the Schedule for the Job, where the data are to be stored, and what media Pool can be used. In effect, each Job resource must specify What, Where, How, and When or FileSet, Storage, Backup/Restore/Level, and Schedule respectively. Note, the FileSet must be specified for a restore job for historical reasons, but it is no longer used.

The Includes/jobs.conf file follows the format of where a Default job is set up and then the following jobs parse the Default Job template via the JobDefs directive, and then have specific directives overridden where needed on successive Jobs. For example to make a new job unique all we have to declare is the Name & FileSet directives. Have a look through the file and this will become apparent.

Includes/jobs.conf

JobDefs {
  Name =             "DefaultJob"
  Type =             Backup
  Level =            Incremental
  Accurate =         yes
  Write Bootstrap =  "/var/db/bacula/%c.bsr"
  Client =           bacula.pbdigital.org-fd
  FileSet =          bacula.pbdigital.org-fs
  Messages =         Standard
  Pool =             Default
  Schedule =         "WeeklyCycle"
  Storage =          bacula.pbdigital.org-sd-usb
  Priority =         10
}

# Define the main nightly save backup job
#   By default, this job will back up to disk in /tmp
Job {
  Name =     "bacula.pbdigital.org"
  JobDefs =  "DefaultJob"
}

# Backup the catalog database (after the nightly save)
Job {
  Name =             "BackupCatalog"
  JobDefs =          "DefaultJob"
  Level =            Full
  Write Bootstrap =  "/var/db/bacula/%n.bsr"
  FileSet =          "Catalog"
  Pool =             Default
  Schedule =         "WeeklyCycleAfterBackup"
  Priority =         11
  RunBeforeJob =     "/usr/local/share/bacula/make_catalog_backup.pl MyCatalog"
  RunAfterJob  =     "/usr/local/share/bacula/delete_catalog_backup"
}

# Standard Restore template, to be changed by Console program
#  Only one such job is needed for all Jobs/Clients/Storage ...
#
Job {
  Name =      "RestoreFiles"
  Type =      Restore
  Client=     bacula.pbdigital.org-fd
  FileSet=    bacula.pbdigital.org-fs
  Messages =  Standard
  Pool =      Default
  Storage =   bacula.pbdigital.org-sd-usb
  Where =     /tmp/bacula-restores
}

Of note I will outline the following directives:

  • Name - The Job name. This name can be specified on the Run command in the console program to start a job. If the name contains spaces, it must be specified between quotes. It is generally a good idea to give your job the same name as the Client that it will backup. This permits easy identification of jobs.

    When the job actually runs, the unique Job Name will consist of the name you specify here followed by the date and time the job was scheduled for execution.

  • Type - The Type directive specifies the Job type, which may be one of the following: Backup, Restore, Verify, or Admin. For our purposes we will use Backup.

    Normally you will have at least one Backup job for each client you want to save. Normally, unless you turn off cataloging, most all the important statistics and data concerning files backed up will be placed in the catalog.

    There is more detailed information on the other types of jobs in the Bacula manual, [19.3] and this is definitely worth a read.

  • Level - The Level directive specifies the default Job level to be run. Each different Job Type (Backup, Restore, …) has a different set of Levels that can be specified. The Level is normally overridden by a different value that is specified in the Schedule resource.

    I have chosen Incremental here as this is the most common level that I use when running a Job from the bconsole.

    Note, Incremental means “all files specified in the FileSet that have changed since the last successful backup of the same Job using the same FileSet and Client, will be backed up”.

  • Accurate - In accurate mode, the File daemon knows exactly which files were present after the last backup. So it is able to handle deleted or renamed files.

  • Write Bootstrap - The writebootstrap directive specifies a file name where Bacula will write a bootstrap file for each Backup job run. This directive applies only to Backup Jobs. If the Backup job is a Full save, Bacula will erase any current contents of the specified file before writing the bootstrap records. If the Job is an Incremental or Differential save, Bacula will append the current bootstrap record to the end of the file.

    For more details see the Bootstrap File chapter [47] in the Bacula documentation.

  • Client - The Client directive specifies the Client (File daemon) that will be used in the current Job. Only a single Client may be specified in any one Job. The Client runs on the machine to be backed up, and sends the requested files to the Storage daemon for backup, or receives them when restoring.

  • FileSet - The FileSet directive specifies the FileSet that will be used in the current Job. The FileSet specifies which directories (or files) are to be backed up, and what options to use (e.g. compression, …). Only a single FileSet resource may be specified in any one Job.

  • Messages - The Messages directive defines what Messages resource should be used for this job, and thus how and where the various messages are to be delivered.

  • Pool - The Pool directive defines the pool of Volumes where your data can be backed up. This directive will be overridden by the Includes/schedules.conf file.

  • Schedule - The Schedule directive defines what schedule is to be used for the Job. The schedule in turn determines when the Job will be automatically started and what Job level (i.e. Full, Incremental, …) is to be run. This directive is optional, and if left out, the Job can only be started manually using the Console program.

  • Storage - The Storage directive defines the name of the storage services where you want to backup the FileSet data.

  • Priority - This directive permits you to control the order in which your jobs will be run by specifying a positive non-zero number. The higher the number, the lower the job priority. Assuming you are not running concurrent jobs, all queued jobs of priority 1 will run before queued jobs of priority 2 and so on, regardless of the original scheduling order.

For more details see the Jobs Resource [19.3] in the Bacula documentation.

Schedules Resource

The Schedule resource provides a means of automatically scheduling a Job as well as the ability to override the default Level, Pool, Storage and Messages resources. If a Schedule resource is not referenced in a Job, the Job can only be run manually. In general, you specify an action to be taken and when.

We have defined two schedules, one to back up our host jobs and a second to start 5 minutes later to backup the catalog, if the WeeklyCycle has completed, otherwise it will start when the WeeklyCycle has completed, as the BackupCatalog has a lower priority.

Includes/schedules.conf

# When to do the backups, full backup on first sunday of the month,
#  differential (i.e. incremental since full) every other sunday,
#  and incremental backups other days
Schedule {
  Name =  "WeeklyCycle"
  Run =   Full Pool=MONTHLY 1st sun at 21:00
  Run =   Differential Pool=WEEKLY 2nd-5th sun at 21:00
  Run =   Incremental Pool=DAILY mon-sat at 21:00
}

# This schedule does the catalog. It starts after the WeeklyCycle
Schedule {
  Name =  "WeeklyCycleAfterBackup"
  Run =   Full Pool=MONTHLY 1st sun at 21:05
  Run =   Full Pool=WEEKLY 2nd-5th sun at 21:05
  Run =   Full Pool=DAILY mon-sat at 21:05
}

Of note I will outline the following directives:

  • Name - The name of the schedule being defined.

  • Run - The Run directive defines when a Job is to be run, and what overrides (in our case, Pool=…), if any to apply. You may specify multiple run directives within a Schedule resource. If you do, they will all be applied (i.e. multiple schedules).

For more details see the Clients Resource [19.5] in the Bacula documentation.

Wrapping Up

That wraps up the configuration of the Bacula daemon. There is a lot of information you will have learned and this will be of great use to you in your day to day usage of Bacula. You can now go ahead and start up the necessary daemons:

service bacula-dir start
service bacula-sd start
service bacula-fd start

It is a good time now to explore Bacula with the bconsole program. You will not be able to run any jobs as yet, as Bacula does not have any media to write to. I will cover preparing media in the next post so you can then get on with running some jobs. As always, you can jump to it here.