Basics#
Introduction#
Checker plugins are modular Bacularis components used by Rule-based Verification to validate individual properties of restored data.
Each checker operates independently, performs one specific type of verification, and returns its own result.
Multiple checkers can be applied to the same restored path, allowing a single file-system object to be verified against several independent conditions.
How a checker works#
After the data has been restored as part of Restore Verification, Bacularis builds a verification context for each checker.
This context contains the information required to perform the check, including the path to be verified, the expected value, and the operator that should be used for the comparison.
A checker returns a boolean result: true or false, indicating whether the verification condition passed or failed.
Based on this result, Bacularis creates a report entry for each checker execution containing the details of the performed test.
A checker can be thought of as an assertion, Verification Rules as test definitions, restored data as test input, and Restore Verification as the test execution framework.
This analogy reflects the role of checker plugins in the Bacularis data verification architecture.
Verification Rules#
Checker plugins require both data and verification criteria in order to perform a check.
In Restore Verification, these criteria are provided by Verification Rules. They are user-defined sets of conditions that describe what should be checked and how it should be verified.
A Verification Rule is based primarily on a path and an attribute to be checked.
The selected attribute determines which checker plugin is executed.
Examples
If the Size attribute is selected for a path, Bacularis uses
the FileSizeCheck checker.
If the Exists attribute is selected, Bacularis uses the FileExistsCheck
checker.
Extensibility#
Checker plugins are extensible. You can create your own checkers according to your verification requirements and use them together with the built-in checkers.
Bacularis provides a basic set of checker plugins for attributes such as:
Exists,
Size,
UID,
GID,
Permissions,
and others.
However, one of the main strengths of the checker architecture is its simplicity and extensibility.
Custom checkers can perform more than simple file-property checks. They can prepare temporary test environments, run application-level validation, and clean up resources after the test.
Database restore validation example
A custom checker such as MyProdDBCheck could be created to validate restored
database backup data.
During the test, it could:
create a fresh temporary database,
import a database dump from the restored data,
perform a simple check to confirm that the database contents are accessible, for example by running a SQL SELECT query,
clean up the database environment after the test.
This is a conceptual example and not a checker built into Bacularis.
Virtual machine restore validation example
A custom checker such as ProdVMCheck could be created to validate restored
virtual machine backup data.
During the test, it could:
prepare a virtual machine test environment,
import a virtual machine image from the restored data,
start the virtual machine,
verify that the guest system is reachable and that the expected services are running,
clean up the virtual machine environment after the test.
This is a conceptual example and not a checker built into Bacularis.
Checker result#
Each checker returns a pass/fail result for one verification condition.
Bacularis combines these individual results into the Restore Test report. If any required check fails, the Restore Job is marked as failed.