Latest news

Introduction

To realize verification tasks, Bacula provides five verify job levels. Each of them is dedicated to specific purpose. Generally we can split them into two parts:

- verify job levels to verify backup job data and metadata
- verify job to track changes in the filesystem

For verifying data and metadata from backup jobs there can be used levels: DiskToCatalog, VolumeToCatalog and Data. For checking changes in the filesystem useful will be levels: InitCatalog and Catalog. Below you can find quick characteristic all those levels, but before doing that, let's do a quick look what are Bacula component functions during work with verify jobs and for what they are responsible.

Director

It is responsible for comparing sent from the File Daemon file attributes with appropriate file attributes in the Catalog database. In other words, in verify jobs Director is capable to compare attributes. Director is also capable to compare the file checksums, but it does not compute them because it is work that can be done by the File Daemon.

File Daemon

It has capability reading file attributes from the filesystem and also it can read file attributes sent from the Storage Daemon from the Bacula volumes. One more the File Daemon's capability is computing checksums. This computing takes place for the verify job level Data. After reading the file attributes, the File Daemon is able to send them to the Director. It is also capable to compare the file size and checksums sent from Director for the verify job level Data with accurate mode enabled.

Storage Daemon

It can read data and metadata from volumes and send them to the File Daemon for analyzing and verifying. It takes place for the job levels Data and VolumeToCatalog.

Glossary of terms

File attributes

In this article this term means the following file properties: inode number, file privileges, number hardlinks, file owner's user ID, system group assigned to the file, file size, access time (ATIME), modify time (MTIME) or change time (CTIME).

Backup metadata

The metadata is the file attributes and theirs checksums written on the Bacula volume together with backup data.

Backup data

It means backed up files written in the backup (without metadata).

Verify job levels

VolumeToCatalog

Verify consistency of the file attributes written on volumes and file attributes in the Bacula database.

This level checks the file attributes and checksums written on a volume with the file attributes and checksums written in the Catalog database. This level does not verify backup data (only attributes and checksums). It is useful to check if the file metadata on volumes are the same as the file metadata in the Catalog.

Data

Verify data on volumes and optionally verify the file sizes and checksums from volumes with the file sizes and checksums in the Bacula database.

All verify work in this level is done not on the Director side, but on the File Daemon side. The File Daemon receives "raw" data from the Storage Daemon (from volumes) which contains backup data and metadata (file attributes and checksums). From the backup data the File Daemon computes file sizes and checksums and it compares them with the file sizes and checksums that comes from the backup metadata on volumes. The Data level is a good way for checking if the data on volumes has not been corrupted or modified, for example by disk errors or in another way. During this verify job level besides of checking file sizes and checksums, there are not checked any additional backup data properties.

The Data level of the verify job uses the Verify directive in the FileSet resource, for example:

FileSet {
    Name = "My Backup FileSet"
    Include {
        Options {
             Signature = SHA1
             Verify = s1
        }
        File = "/home/gani"
    }
}

There are supported letters s (checking file size), 5 (checking MD5 checksum), 1 (checking SHA1 checksum). If s is not specified, the File Daemon does not compute nor compare file sizes. If any of option 1 or 5 is not specified, the File Daemon does not compute nor compare file checksums from the backup data.

If the verify job is running with the accurate mode, there are compared checksums and file sizes from the backup metadata (from volumes) with sent from the Director checksums and file sizes from the Bacula database. All comparing is done on the File Daemon side.

DiskToCatalog

Check compatibility of the file attributes on the filesystem with file attributes in the Catalog database.

The purpose of this job level is comparing file attributes in the filesystem on the File Daemon side with file attributes written in the Bacula database. This level helps checking if during last backup the file attributes have changed (or not) and how much. Possible criteria for comparing file attributes in the Verify directive in FileSet are following:

- i compare the inodes
- p compare the permission bits
- n compare the number of links
- u compare the user id
- g compare the group id
- s compare the size
- a compare the access time
- m compare the modification time
- c compare the change time
- d report file size decreases
- 5 compare the MD5 signature
- 1 compare the SHA1 signature

Example Bacula configuration for checking file privileges, inodes, number of hardlinks and MD5 checksum:

FileSet {
    Name = "Moj Backup FileSet"
    Include {
        Options {
             Signature = MD5
             Verify = pins5
        }
        File = "/home/gani"
    }
}

InitCatalog

Create a snapshot from file attributes to compare it during running job with the Catalog job level.

Thanks to the InitCatalog level Bacula is able to read state of the file attributes on the filesystem on the File Daemon host and write the state in the Catalog database. It will be used as a base for determining if something has changed on the filesystem or not. InitCatalog and Catalog verify job levels are a separate pair of jobs that does not verify backup data and metadata, but those verify levels are a good tool to create a "snapshot" of the file attributes and to check if something changed since last job with InitCatalog level.

Catalog

Verify file attributes since last job with the InitCatalog level.

This verify job level is something like scanning filesystem for changes. There are available in the FileSet resource the following attributes to use as a checking criteria:

- i compare the inodes
- p compare the permission bits
- n compare the number of links
- u compare the user id
- g compare the group id
- s compare the size
- a compare the access time
- m compare the modification time
- c compare the change time
- d report file size decreases
- 5 compare the MD5 signature
- 1 compare the SHA1 signature

Before running the Catalog job level, there must be done at least one job with the InitCatalog level.

Bacularis verify job wizard

The new wizard supports all Bacula verify job levels both for verifying job data and for improving computer security by monitoring changes on the filesystem. Users are also able to use JobDefs if needed. For verifying job data there is possible to create verify job with assigned selected backup job or create general purpose verify job that can be used with different backup jobs and with different job levels.

Below you can find a video and a couple of screenshots.