Volume to Catalog Verification

If, after a backup job finished, you want to ensure that the backed up data was stored correctly and can be used by Bacula, a VolumeToCatalog verification job is the tool needed. In the simplest form, shown below, this sort of Verify Job verifies the last job run on the given client, but it is possible to configure which job to verify.

Job {
  Name = SomeJob
  JobDefs = DefaultJob
  Client = one-fd
  File Set = FullSet
  Schedule = SomeSch
}

Job {
  Name = Verify
  JobDefs = one-fd
  Client = one-fd
  Type = Verify
  Level = VolumeToCatalog
  Schedule = SomeSch
  Priority = 11
}

We assume that the priority of the ``DefaultJob`` is set to 10; the configuration is not complete.

Scheduling / ordering problems — Scheduling/ordering problems

Automatic selection of the job to verify fails if more than one job is run on a client and the jobs and their verifications get re-ordered, for example due to one job running longer than planned. Top: Planned scheduling. Bottom: Backup Job A runs beyond the scheduled time for backup and verify Job B, and eventually B gets verified twice, and A not at all.

As the simple approach requires a verify job directly after each backup job run (to ensure the correct order of jobs, priorities can be used), it is rather inflexible and can have the result that backup windows are exceeded.

The requirement of strict order of Backup and Verify Jobs brings lots of problems when more than one backup job per client is used, as it needs to be enforced by using dedicated schedules for each pair of job and related verification, and fails once the order is disturbed – which may easily happen when a single job runs longer than expected. See figure Scheduling/ordering problems.

To prevent this, Verify Jobs can also be run later, on a dedicated Bacula system typically during the working hours. In the configuration, this is done by defining which job is to be verified. The job with the given name that was run last will be chosen for verification. The above example configuration changes to the example configuration below, accordingly. Using this approach, verification of a large number of jobs on a specific client is more easily possible, and the risk of not verifying the correct jobs vanishes. Using priorities it’s easily possible to ensure all verifications run after the backups. The downside here is that a higher number of jobs needs to be created and maintained. As Bacula Systems recommends to generate configurations for environments with many jobs automatically, adding the generation of the required verify jobs will not add much to the maintenance process in those cases.

Job {
  Name = SomeJob
  JobDefs = DefaultJob
  Client = one-fd
  File Set = FullSet
  Schedule = SomeSch
}

Job {
  Name = SomeVerify
  JobDefs = DefaultJob
  Type = Verify
  VerifyJob = SomeJob
  Level = VolumeToCatalog
  Schedule = SomeSch
  Priority = 11
}

The File Set configured in the verify job resource is, although required by the configuration file parser, not actually used; the comparison uses the file set actually used for the original backup. This simplifies the maintenance of Verify Jobs a lot, although Job Reports may appear misleading.