dbcheck

CommunityEnterprise

dbcheck is a simple program that will search for logical inconsistencies in the Bacula tables in your database, and optionally fix them. It is a database maintenance routine, in the sense that it can detect and remove unused rows, but it is not a database repair routine. To repair a database, see the tools furnished by the database vendor. Normally dbcheck should never need to be run, but if Bacula has crashed or you have a lot of Clients, Pools, or Jobs that you have removed, it could be useful.

The dbcheck program can be found in the /opt/bacula/bin directory.

It is called:

Usage: dbcheck [-c config ] [-B] [-C catalog name] [-d debug_level]
  <working-directory> <bacula-database> <user> <password> [<dbhost>] [<dbport>]
       -b              batch mode
       -C              catalog name in the director conf file
       -c              Director conf filename
       -B              print catalog configuration and exit
       -d <nn>         set debug level to <nn>
       -dt             print timestamp in debug output
       -f              fix inconsistencies
       -v              verbose
       -?              print this message

If the -B option is specified, dbcheck will print out Catalog information in a simple text based format. This is useful to backup it in a secure way.

$ dbcheck -B
catalog=MyCatalog
db_type=SQLite
db_name=regress
db_driver=
db_user=regress
db_password=
db_address=
db_port=0
db_socket=

If the -c option is given with the Director’s conf file, there is no need to enter any of the command line arguments, in particular the working directory as dbcheck will read them from the file.

If the -f option is specified, dbcheck will repair (fix) the inconsistencies it finds. Otherwise, it will report only.

If the -b option is specified, dbcheck will run in batch mode, and it will proceed to examine and fix (if -f is set) all programmed inconsistency checks.

When dbcheck is run in report-only mode with -v -c /opt/bacula/etc/bacula-dir.conf, the interactive menu looks as follows:

# sudo -u bacula /opt/bacula/bin/dbcheck -v -c /opt/bacula/etc/bacula-dir.conf
Hello, this is the database check/correct program.
Modify database is off. Verbose is on.
Please select the function you want to perform.

     1) Toggle modify database flag
     2) Toggle verbose flag
     3) Check for bad Path records
     4) Check for duplicate Path records
     5) Check for orphaned Jobmedia records
     6) Check for orphaned File records
     7) Check for orphaned Path records
     8) Check for orphaned FileSet records
     9) Check for orphaned Client records
    10) Check all orphaned Meta/FileEvents data records
    11) Check for orphaned Job records
    12) Check for all Admin records
    13) Check for all Restore records
    14) Check all Verify records
    15) All (3-14)
    16) Quit
Select function number:

When dbcheck is run in modify mode with -v -f -c /opt/bacula/etc/bacula-dir.conf, the interactive menu looks as follows:

# sudo -u bacula /opt/bacula/bin/dbcheck -vf -c /opt/bacula/etc/bacula-dir.conf
Hello, this is the database check/correct program.
Modify database is on. Verbose is on.
Please select the function you want to perform.

     1) Toggle modify database flag
     2) Toggle verbose flag
     3) Repair bad Path records
     4) Eliminate duplicate Path records
     5) Eliminate orphaned Jobmedia records
     6) Eliminate orphaned File records
     7) Eliminate orphaned Path records
     8) Eliminate orphaned FileSet records
     9) Eliminate orphaned Client records
    10) Eliminate orphaned Meta/FileEvents data records
    11) Eliminate orphaned Job records
    12) Eliminate all Admin records
    13) Eliminate all Restore records
    14) Eliminate all Verify records
    15) All (3-14)
    16) Quit
Select function number:

The available functions are:

1) Toggle modify database flag: Toggles the modify database flag (-f option). It can be helpful to turn this flag off first, run one or more consistency checks to see what will be done, then turn it on and run the checks again to apply the changes.
2) Toggle verbose flag: Toggles the verbose flag (-v option) to display more detailed output while running checks.
3) Check for bad Path records / Repair bad Path records: Checks path names to ensure they have a trailing slash. When modify mode is enabled, incorrect Path records are corrected.
4) Check for duplicate Path records / Eliminate duplicate Path records: Duplicate Path records can occur if accidentally run two copies of Bacula at the same time and both are adding records simultaneously. This is rare, but it can create an inconsistent database. If duplicate record errors are not being reported during Jobs, there is usually no reason to run this check.
5) Check for orphaned Jobmedia records / Eliminate orphaned Jobmedia records: This happens when a Job record is deleted, perhaps by a user-issued SQL statement, but the corresponding Jobmedia records were not deleted. Normally this should not happen, and even if it does, these records generally do not take much space in your database. Running this function can identify and remove such orphaned records.
6) Check for orphaned File records / Eliminate orphaned File records: This happens when a Job record is deleted, perhaps by a user-issued SQL statement, but the corresponding File records (one for each Volume used in the Job) were not deleted. Searching for these records can be very time-consuming for a large database and may take hours. Normally this should not happen because Bacula takes care to prevent it. This function can identify and remove orphaned File records. It is recommended that you run this once a year, because orphaned File records can take a large amount of space in your database. You might want to ensure that you have indexes of JobId, FilenameId, and PathId for the File table in your Catalog before running this command.
7) Check for orphaned Path records / Eliminate orphaned Path records: This condition happens when a directory is deleted from your system and all associated Job records have been purged. During standard purging or pruning of Job records, Bacula does not check for orphaned Path records, so unused Path records can accumulate over time and use space in your database. This function can identify and remove them. It is recommended that you run this check at least once a year.
8) Check for orphaned FileSet records / Eliminate orphaned FileSet records: When a Fileset is updated, a new Catalog record is created. When a Fileset record is no longer referenced by any Job, it becomes orphaned. This function can identify and remove those records.
9) Check for orphaned Client records / Eliminate orphaned Client records: These records can remain in the database long after you have removed a Client. This function allows you to identify and remove them.
10) Check all orphaned Meta/FileEvents data records / Eliminate orphaned Meta/FileEvents data records: This checks for Meta and FileEvents data records that are no longer referenced by any related Catalog records and have therefore become orphaned. Such records can remain after Jobs or associated records have been removed. This function can identify and, when modify mode is enabled, remove these orphaned records.
11) Check for orphaned Job records / Eliminate orphaned Job records: If no Client is defined for a Job, or you do not run a Job for a long time, you can accumulate old Job records. This function can identify and remove such useless Job records.
12) Check for all Admin records / Eliminate all Admin records: Identifies all Admin records in the Catalog. When modify mode is enabled, all Admin records are removed regardless of age.
13) Check for all Restore records / Eliminate all Restore records: Identifies all Restore records in the Catalog. When modify mode is enabled, all Restore records are removed regardless of age.
14) Check all Verify records / Eliminate all Verify records: Identifies all Verify records in the Catalog. When modify mode is enabled, all Verify records are removed regardless of age.
15) All (3-14): Runs all checks, or all cleanup actions when modify mode is enabled, for the functions listed in items 3 through 14.
15) Quit: Exits the program.

If you are using MySQL, dbcheck will ask you if you want to create temporary indexes to speed up orphaned Path and Filename elimination.

Mostly for PostgreSQL users, we provide a pure SQL script dbcheck replacement in examples/database/dbcheck.sql that works with global queries instead of many small queries like dbcheck. Execution instructions are at the top of the script and you will need to type COMMIT at the end to validate modifications.

If you are using bweb or brestore, don’t eliminate orphaned Path, else you will have to rebuild brestore_pathvisibility and brestore_pathhierarchy indexes.

Under normal circumstances, dbcheck should rarely be necessary. It is mainly intended for cases where the Catalog has become inconsistent. The recommendations above are general guidance and should not be interpreted as a need to run dbcheck routinely without signs of Catalog problems.

Go back to: PostgreSQL Catalog Administration.