NAME
dbcheck - Bacula’s Catalog Database Check/Clean program
SYNOPSIS
bcopy [options] working-directory bacula-database user password
[dbhost] [dbport]
DESCRIPTION
This manual page documents briefly the dbcheck command.
dbcheck will not repair your database if it is broken. Please see your
vendor’s instructions for fixing broken database.
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.
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
-B print catalog configuration and exit
-dnn set debug level to nn
-dt print timestamp in debug output
-f fix inconsistencies
-v verbose
-? print this message
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. If the -b option is not specified, dbcheck will
enter interactive 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) 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.
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.
Repair bad Filename records. This checks and corrects filenames that
have
a trailing slash. They should not.
Repair bad Path records. This checks and corrects path names that do
not
have a trailing slash. They should.
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.
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.
Orphaned Client records. These records can remain in the database
long
after you have removed a client.
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 Restore records. This command will remove all Restore records,
regardless of their age.
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.
SEE ALSO
bls(1), bextract(1).
AUTHOR
This manual page was written by Jose Luis Tallon
<jltallon@adv-solutions.net>.