Overview

Overview#

What is a Verification Method?#

A Verification Method defines how restored data is checked after a Restore Test performs the restore. It determines which verification mechanism is used, what can be checked, and what requirements apply to the restore environment.

Restore Verification currently supports two verification methods:

  • Rule-based Verification

  • Native Bacula Verify

Comparison of verification methods#

Although both Verification Methods are used to verify restored data, they differ in how they work and in the requirements they impose.

The table below provides a simple comparison of the currently available verification methods. Detailed information about each method is available in the dedicated sections: [Rule-based Verification] and [Native Bacula Verify].

Rule-based Verification

Native Bacula Verify

Verification engine

Bacularis checker plugins

Bacula Verify Job

Backup handling

Restore point with required backup chain

Single selected backup JobId

Supported backup levels

Full, Differential, Incremental

Full only

Restore scope

Flexible

Selected backup only

Restore path prefix

Supported

Not supported

Verification criteria

Verification Rules

Bacula FileSet Verify directives

Extensibility

Checker plugins

Bacula-native mechanisms

Restore environment

Prefixed restore supported

Isolated environment with original paths

Best suited for

Flexible file, data, and application-level tests

Native Bacula file-level verification

Which verification method should I choose?#

There is no single answer that applies to every environment. The best choice depends on what you want to verify, how you want the verification to be performed, and what restore environment is available.

Native Bacula Verify is generally better suited to users who are already familiar with Bacula Verify Jobs, FileSet Verify directives, and the DiskToCatalog verification model.

Rule-based Verification provides a more Bacularis-oriented workflow and is usually easier to configure when flexible restore scopes, prefixed restore destinations, or custom verification logic are required.

When choosing a method, consider how the method works, what type of data it can verify, which backup levels it supports, what kind of test environment it requires, and what limitations apply to it.

General guideline#

As a general guideline:

  • choose Rule-based Verification when you need flexible restore scopes, safe prefixed restores, checker plugins, or application-specific tests

  • choose Native Bacula Verify when you specifically want to use Bacula’s native DiskToCatalog verification workflow and have an isolated restore environment available.

Contents