Rechercher une page de manuel
dbcheck
Langue: en
Version: 26 May 2006 (mandriva - 22/10/07)
Section: 8 (Commandes administrateur)
NAME
dbcheck - Bacula's Catalog Database Check/Clean program
SYNOPSIS
bcopy [options] working-directory bacula-database user passwordDESCRIPTION
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
-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:
Duplicatefilenamerecords.Thiscanhappenifyouaccidentallyruntwo
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.
RepairbadFilenamerecords.Thischecksandcorrectsfilenamesthat
have a trailing slash. They should not.
RepairbadPathrecords.Thischecksandcorrectspathnamesthatdo
not have a trailing slash. They should.
Duplicatepathrecords.Thiscanhappenifyouaccidentallyruntwo
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.
OrphanedJobMediarecords.ThishappenswhenaJobrecordisdeleted
(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.
OrphanedFilerecords.ThishappenswhenaJobrecordisdeleted
(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 {or 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.
OrphanedPathrecords.Thisconditionhappensanytimeadirectoryis
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.
OrphanedFilenamerecords.Thisconditionhappensanytimeafileis
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.
OrphanedClientrecords.Theserecordscanremaininthedatabaselong
after you have removed a client.
OrphanedJobrecords.Ifnoclientisdefinedforajoboryoudonot
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).
AllAdminrecords.ThiscommandwillremoveallAdminrecords,
regardless of their age.
AllRestorerecords.ThiscommandwillremoveallRestorerecords,
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>.Contenus ©2006-2024 Benjamin Poulain
Design ©2006-2024 Maxime Vantorre