DBCHECK(8)

DBCHECK(8) 💅✨

okay bestie, welcome to the manual page for dbcheck — that's the Bacula Catalog Database Check/Clean program, from the Network backup, recovery and verification corner of the universe. this is the 8th section of the manual, so she's a sysadmin-y girlie. buckle up 🎀

NAME 🦋

dbcheck — Bacula's Catalog Database Check/Clean program. she checks. she cleans. she does NOT repair. more on that in a sec 🫶

SYNOPSIS ✨

dbcheck [options] working-directory bacula-database user password
[dbhost] [dbport]

DESCRIPTION 💖

okay so this manual page documents the dbcheck command, briefly. that's the whole vibe. ✨

🚨 NOT ME BEING THE BEARER OF BAD NEWS: dbcheck will not repair your database if it is broken. please see your vendor's instructions for fixing broken database. she is not that girl and she never claimed to be. 💀

dbcheck is a simple program that will search for logical inconsistencies in the Bacula tables in your database, and optionally fix them. it's 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. (the database vendor. not us. we don't do that here.)

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. situational queen behavior 👑

OPTIONS 🎀

a summary of options is included below. slay. 💅

• -? — show version and usage of program.
• -b — if specified, dbcheck will run in batch mode, and it will proceed to examine and fix (if -f is set) all programmed inconsistency checks. by default, dbcheck will enter interactive mode (see below).
• -C catalog — catalog name in the director conf file.
• -c config — 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. it's giving self-sufficient ✨
• -B — print catalog configuration and exit.
• -d nn — set debug level to nn.
• -dt — print timestamp in debug output.
• -f — if specified, dbcheck will repair (fix) the inconsistencies it finds. otherwise, it will report only. reporting only is the safe mode, bestie, don't come for me
• -v — set verbose mode.

INTERACTIVE MODE 🌈

in interactive mode dbcheck will prompt with the following:

Hello, this is the database check/correct program.  Please select the function you want to perform.
     1) Toggle modify database flag
     2) Toggle verbose flag
     3) Repair bad Filename records
     4) Repair bad Path records
     5) Eliminate duplicate Filename records
     6) Eliminate duplicate Path records
     7) Eliminate orphaned Jobmedia records
     8) Eliminate orphaned File records
     9) Eliminate orphaned Path records
    10) Eliminate orphaned Filename records
    11) Eliminate orphaned FileSet records
    12) Eliminate orphaned Client records
    13) Eliminate orphaned Job records
    14) Eliminate all Admin records
    15) Eliminate all Restore records
    16) All (3-15)
    17) Quit
Select function number:

by entering 1 or 2, you can toggle the modify database flag (-f option) and the verbose flag (-v). it can be helpful and reassuring to turn off the modify database flag, then select one or more of the consistency checks (items 3 through 9) to see what will be done, then toggle the modify flag on and re-run the check. this is the "look before you leap" pipeline and honestly? iconic. 🫶

the inconsistencies examined are the following:

• Duplicate filename records. this can happen if you accidentally run two copies of Bacula at the same time, and they are both adding filenames simultaneously. it is a rare occurrence, but will create an inconsistent database. if this is the case, you will receive error messages during Jobs warning of duplicate database records. if you are not getting these error messages, there is no reason to run this check. no messages, no problem, no check. periodt.
• Repair bad Filename records. this checks and corrects filenames that have a trailing slash. they should not. the slash was NOT invited 🚫
• Repair bad Path records. this checks and corrects path names that do not have a trailing slash. they should. opposite girlie, opposite rules 💅
• Duplicate path records. this can happen if you accidentally run two copies of Bacula at the same time, and they are both adding filenames simultaneously. it is a rare occurrence, but will create an inconsistent database. see the item above for why this occurs and how you know it is happening.
• Orphaned JobMedia records. this happens when a Job record is deleted (perhaps by a user issued SQL statement), but the corresponding JobMedia record (one for each Volume used in the Job) was not deleted. normally, this should not happen, and even if it does, these records generally do not take much space in your database. however, by running this check, you can eliminate any such orphans.
• Orphaned File records. this happens when a Job record is deleted (perhaps by a user issued SQL statement), but the corresponding File record (one for each Volume used in the Job) was not deleted. note, searching for these records can be very time consuming (i.e. it may take hours) for a large database. normally this should not happen as Bacula takes care to prevent it. just the same, this check can remove any orphaned File records. it is recommended that you run this once a year since orphaned File records can take a large amount of space in your database. you might want to ensure that you have indexes on JobId, FilenameId, and PathId for the File table in your catalog before running this command. index first, ask questions later ✨
• Orphaned Path records. this condition happens any time 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. as a consequence, over a period of time, old unused Path records will tend to accumulate and use space in your database. this check will eliminate them. it is recommended that you run this check at least once a year.
• Orphaned Filename records. this condition happens any time a file is deleted from your system and all associated Job records have been purged. this can happen quite frequently as there are quite a large number of files that are created and then deleted. in addition, if you do a system update or delete an entire directory, there can be a very large number of Filename records that remain in the catalog but are no longer used.

during standard purging (or pruning) of Job records, Bacula does not check for orphaned Filename records. as a consequence, over a period of time, old unused Filename records will accumulate and use space in your database. this check will eliminate them. it is strongly recommended that you run this check at least once a year, and for large database (more than 200 Megabytes), it is probably better to run this once every 6 months. 200 Megabytes. six months. write it down bestie 🎀

• Orphaned Client records. these records can remain in the database long after you have removed a client. ghost client. haunting the catalog. 💀
• 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 option allow you to remove jobs that are not attached to any client (and thus useless).
• All Admin records. this command will remove all Admin records, regardless of their age. ALL of them. age is not a factor. read it again if you need to. 🚨
• All Restore records. this command will remove all Restore records, regardless of their age. same energy. no mercy. 😭

by the way, I personally run dbcheck only where I have messed up my database due to a bug in developing Bacula code, so normally you should never need to run dbcheck inspite of the recommendations given above, which are given so that users don't waste their time running dbcheck too often. she's keeping it real with us 🫶

SEE ALSO 🦋

bls(1), bextract(1).

AUTHOR 👑

this manual page was written by Jose Luis Tallon <jltallon@adv-solutions.net>.

COPYRIGHT 💜

this man page document is released under the BSD 2-Clause license.

and that's the whole thing, bestie!! this page came to you from Kern Sibbald, 26 September 2009, and yeah it lives in section 8 as DBCHECK(8). go forth and check those inconsistencies responsibly 💅✨🎀🦋🌸🫶