.\" Please adjust this date whenever revising the manpage.
.\"
.SH NAME
- bcopy \- Bacula's DB Check
+ dbcheck \- Bacula's Catalog Database Check/Clean program
.SH SYNOPSIS
.B bcopy
.RI [ options ]
.I bacula-database
.I user
.I password
+.RI [ dbhost ]
+.RI [ dbport ]
.br
.SH DESCRIPTION
This manual page documents briefly the
-.B bcopy
+.B dbcheck
command.
.PP
-.\" TeX users may be more comfortable with the \fB<whatever>\fP and
-.\" \fI<whatever>\fP escape sequences to invode bold face and italics,
-.\" respectively.
-.SH OPTIONS
-A summary of options is included below.
-.TP
-.B \-?
-Show version and usage of program.
-.TP
-.BI \-b\ bootstrap
-Specify a bootstrap file.
-.TP
-.BI \-c\ config
-Specify configuration file.
-.TP
-.BI \-d\ nn
-Set debug level to \fInn\fP.
-.TP
-.BI \-i\ input
-Specify input Volume names (separated by '|')
-.TP
-.BI \-o\ output
-Specify output Volume names (separated by '|')
-.TP
-.BI \-w\ directory
-Specify working directory (default \fI/tmp\fP).
-.TP
-.B \-v
-Set verbose mode.
+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
+ -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 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:
+
+.BR
+ 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.
+
+.BR
+Repair bad Filename records. This checks and corrects filenames that
+ have a trailing slash. They should not.
+
+.BR
+Repair bad Path records. This checks and corrects path names that do
+ not have a trailing slash. They should.
+
+.BR
+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.
+
+.BR
+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.
+
+.BR
+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 {\bf 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.
+
+.BR
+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.
+
+.BR
+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.
+
+.BR
+Orphaned Client records. These records can remain in the database long
+ after you have removed a client.
+
+.BR
+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).
+
+.BR
+All Admin records. This command will remove all Admin records,
+ regardless of their age.
+
+.BR
+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.
+
.SH SEE ALSO
.BR bls (1),
.BR bextract (1).
projects / bacula / bacula / blobdiff