X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=bacula%2Fmanpages%2Fdbcheck.8;h=9e3a6f1befa63c683def873d93871eb2b8bd0659;hb=ba8bb7f86cd247e68559e457ed6f8d3c4266d16a;hp=441b11df20334fb4cbe211d38cf97d513ba4951e;hpb=10778e6d36c49f8283c519da1ec044b4b3fecc5d;p=bacula%2Fbacula diff --git a/bacula/manpages/dbcheck.8 b/bacula/manpages/dbcheck.8 index 441b11df20..9e3a6f1bef 100644 --- a/bacula/manpages/dbcheck.8 +++ b/bacula/manpages/dbcheck.8 @@ -2,7 +2,7 @@ .\" 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 @@ -40,7 +40,9 @@ 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 @@ -52,10 +54,10 @@ 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: +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. @@ -79,90 +81,91 @@ 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,