MAN page from SuSE 10.X bacula-postgresql-2.2.4-2.su101.x86_64.rpm

DBCHECK

Section: Network backup, recovery and verification (8)
Updated: 26 May 2006
Index

NAME

dbcheck - Bacula's Catalog Database Check/Clean program

SYNOPSIS

bcopy [options]working-directorybacula-databaseuserpassword

DESCRIPTION

This manual page documents briefly thedbcheck command.

dbcheck will not repair your database if it is broken. Please see yourvendor's instructions for fixing broken database.

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

Usage: dbcheck [-c config] [-C catalog name] [-d debug_level] []
       -b              batch mode
       -C              catalog name in the director conf file
       -c              director conf filename
       -dnn            set debug level to nn
       -f              fix inconsistencies
       -v              verbose
       -?              print this message

If the -c option is given with the Director's conf file, there is noneed to enter any of the command line arguments, in particular the workingdirectory as dbcheck will read them from the file.

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

If the -b option is specified, dbcheck will run in batch mode, andit will proceed to examine and fix (if -f is set) all programmed inconsistencychecks. If the -b option is not specified, dbcheck will enterinteractive mode and 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) QuitSelect function number:

By entering 1 or 2, you can toggle the modify database flag (-f option) andthe verbose flag (-v). It can be helpful and reassuring to turn off the modifydatabase flag, then select one or more of the consistency checks (items 3through 9) to see what will be done, then toggle the modify flag on and re-runthe check.

The inconsistencies examined are the following:

Duplicatefilenamerecords.Thiscanhappenifyouaccidentallyruntwo
   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.

RepairbadFilenamerecords.Thischecksandcorrectsfilenamesthat
have a trailing slash. They should not.

RepairbadPathrecords.Thischecksandcorrectspathnamesthatdo
not have a trailing slash. They should.

Duplicatepathrecords.Thiscanhappenifyouaccidentallyruntwo
   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.

OrphanedJobMediarecords.ThishappenswhenaJobrecordisdeleted
   (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.

OrphanedFilerecords.ThishappenswhenaJobrecordisdeleted
   (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 {or 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.

OrphanedPathrecords.Thisconditionhappensanytimeadirectoryis
   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.

OrphanedFilenamerecords.Thisconditionhappensanytimeafileis
   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.

OrphanedClientrecords.Theserecordscanremaininthedatabaselong
after you have removed a client.

OrphanedJobrecords.Ifnoclientisdefinedforajoboryoudonot
   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).

AllAdminrecords.ThiscommandwillremoveallAdminrecords,
regardless of their age.

AllRestorerecords.ThiscommandwillremoveallRestorerecords,
regardless of their age.

By the way, I personally run dbcheck only where I have messed upmy database due to a bug in developing Bacula code, so normallyyou should never need to run dbcheck inspite of therecommendations given above, which are given so that users don'twaste their time running dbcheck too often.

AUTHOR

This manual page was written by Jose Luis Tallon<jltallonAATTadv-solutions.net>.