1 .\" Hey, EMACS: -*- nroff -*-
2 .\" First parameter, NAME, should be all caps
3 .\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
4 .\" other parameters are allowed: see man(7), man(1)
5 .TH DBCHECK 8 "26 September 2009" "Kern Sibbald" "Network backup, recovery and verification"
6 .\" Please adjust this date whenever revising the manpage.
9 dbcheck \- Bacula's Catalog Database Check/Clean program
21 This manual page documents briefly the
25 dbcheck will not repair your database if it is broken. Please see your
26 vendor's instructions for fixing broken database.
28 dbcheck is a simple program that will search for logical
29 inconsistencies in the Bacula tables in your database, and optionally fix them.
30 It is a database maintenance routine, in the sense that it can
31 detect and remove unused rows, but it is not a database repair
32 routine. To repair a database, see the tools furnished by the
33 database vendor. Normally dbcheck should never need to be run,
34 but if Bacula has crashed or you have a lot of Clients, Pools, or
35 Jobs that you have removed, it could be useful.
39 Usage: dbcheck [-c config] [-C catalog name] [-d debug_level] []
41 -C catalog name in the director conf file
42 -c director conf filename
43 -B print catalog configuration and exit
44 -dnn set debug level to nn
45 -dt print timestamp in debug output
46 -f fix inconsistencies
50 If the -c option is given with the Director's conf file, there is no
51 need to enter any of the command line arguments, in particular the working
52 directory as dbcheck will read them from the file.
54 If the -f option is specified, dbcheck will repair (fix) the
55 inconsistencies it finds. Otherwise, it will report only.
57 If the -b option is specified, dbcheck will run in batch mode, and it will
58 proceed to examine and fix (if -f is set) all programmed inconsistency
59 checks. If the -b option is not specified, dbcheck will enter interactive
60 mode and prompt with the following:
62 Hello, this is the database check/correct program.
63 Please select the function you want to perform.
64 1) Toggle modify database flag
65 2) Toggle verbose flag
66 3) Repair bad Filename records
67 4) Repair bad Path records
68 5) Eliminate duplicate Filename records
69 6) Eliminate duplicate Path records
70 7) Eliminate orphaned Jobmedia records
71 8) Eliminate orphaned File records
72 9) Eliminate orphaned Path records
73 10) Eliminate orphaned Filename records
74 11) Eliminate orphaned FileSet records
75 12) Eliminate orphaned Client records
76 13) Eliminate orphaned Job records
77 14) Eliminate all Admin records
78 15) Eliminate all Restore records
81 Select function number:
83 By entering 1 or 2, you can toggle the modify database flag (-f option) and
84 the verbose flag (-v). It can be helpful and reassuring to turn off the
85 modify database flag, then select one or more of the consistency checks
86 (items 3 through 9) to see what will be done, then toggle the modify flag
87 on and re-run the check.
89 The inconsistencies examined are the following:
92 Duplicate filename records. This can happen if you accidentally run two
93 copies of Bacula at the same time, and they are both adding filenames
94 simultaneously. It is a rare occurrence, but will create an
95 inconsistent database. If this is the case, you will receive error
96 messages during Jobs warning of duplicate database records. If you are
97 not getting these error messages, there is no reason to run this check.
100 Repair bad Filename records. This checks and corrects filenames that have
101 a trailing slash. They should not.
104 Repair bad Path records. This checks and corrects path names that do not
105 have a trailing slash. They should.
108 Duplicate path records. This can happen if you accidentally run two copies
109 of Bacula at the same time, and they are both adding filenames
110 simultaneously. It is a rare occurrence, but will create an
111 inconsistent database. See the item above for why this occurs and how
112 you know it is happening.
115 Orphaned JobMedia records. This happens when a Job record is deleted
116 (perhaps by a user issued SQL statement), but the corresponding JobMedia
117 record (one for each Volume used in the Job) was not deleted. Normally,
118 this should not happen, and even if it does, these records generally do
119 not take much space in your database. However, by running this check,
120 you can eliminate any such orphans.
123 Orphaned File records. This happens when a Job record is deleted (perhaps
124 by a user issued SQL statement), but the corresponding File record (one
125 for each Volume used in the Job) was not deleted. Note, searching for
126 these records can be very time consuming (i.e. it may take hours) for a
127 large database. Normally this should not happen as Bacula takes care to
128 prevent it. Just the same, this check can remove any orphaned File
129 records. It is recommended that you run this once a year since orphaned
130 File records can take a large amount of space in your database. You
131 might want to ensure that you have indexes on JobId, FilenameId, and
132 PathId for the File table in your catalog before running this command.
135 Orphaned Path records. This condition happens any time a directory is
136 deleted from your system and all associated Job records have been
137 purged. During standard purging (or pruning) of Job records, Bacula
138 does not check for orphaned Path records. As a consequence, over a
139 period of time, old unused Path records will tend to accumulate and use
140 space in your database. This check will eliminate them. It is
141 recommended that you run this check at least once a year.
144 Orphaned Filename records. This condition happens any time a file is
145 deleted from your system and all associated Job records have been
146 purged. This can happen quite frequently as there are quite a large
147 number of files that are created and then deleted. In addition, if you
148 do a system update or delete an entire directory, there can be a very
149 large number of Filename records that remain in the catalog but are no
152 During standard purging (or pruning) of Job records, Bacula does not
153 check for orphaned Filename records. As a consequence, over a period of
154 time, old unused Filename records will accumulate and use space in your
155 database. This check will eliminate them. It is strongly recommended
156 that you run this check at least once a year, and for large database
157 (more than 200 Megabytes), it is probably better to run this once every
161 Orphaned Client records. These records can remain in the database long
162 after you have removed a client.
165 Orphaned Job records. If no client is defined for a job or you do not run
166 a job for a long time, you can accumulate old job records. This option
167 allow you to remove jobs that are not attached to any client (and thus
171 All Admin records. This command will remove all Admin records,
172 regardless of their age.
175 All Restore records. This command will remove all Restore records,
176 regardless of their age.
178 By the way, I personally run dbcheck only where I have messed up
179 my database due to a bug in developing Bacula code, so normally
180 you should never need to run dbcheck inspite of the
181 recommendations given above, which are given so that users don't
182 waste their time running dbcheck too often.
189 This manual page was written by Jose Luis Tallon
191 <jltallon@adv\-solutions.net>.