]> git.sur5r.net Git - bacula/bacula/blobdiff - bacula/manpages/dbcheck.8
regress: add delete-test to regression suite
[bacula/bacula] / bacula / manpages / dbcheck.8
index 9c31937e383df11a006788f0c31dc8633ba0f128..9e3a6f1befa63c683def873d93871eb2b8bd0659 100644 (file)
@@ -2,11 +2,11 @@
 .\" 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
- 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
+       -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: 
+
+.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 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).