.\" First parameter, NAME, should be all caps
.\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
.\" other parameters are allowed: see man(7), man(1)
-.TH DBCHECK 8 "26 May 2006" "Kern Sibbald" "Network backup, recovery and verification"
+.TH DBCHECK 8 "26 September 2009" "Kern Sibbald" "Network backup, recovery and verification"
.\" Please adjust this date whenever revising the manpage.
.\"
.SH NAME
-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 -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:
+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.
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 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.
+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.
+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.
+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.
+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.
+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.
+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.
.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.
+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.
+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.
+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).
+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,
projects / bacula / bacula / blobdiff