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.
37 A summary of options is included below.
40 Show version and usage of program.
43 If specified, dbcheck will run in batch mode, and it will proceed to examine
44 and fix (if \-f is set) all programmed inconsistency checks. By default,
45 dbcheck will enter interactive mode (see below).
48 catalog name in the director conf file.
51 If the \-c option is given with the Director's conf file, there is no need to
52 enter any of the command line arguments, in particular the working directory
53 as dbcheck will read them from the file.
56 print catalog configuration and exit.
59 set debug level to \fInn\fP.
62 print timestamp in debug output.
65 If specified, dbcheck will repair (fix) the inconsistencies it finds.
66 Otherwise, it will report only.
71 In interactive mode dbcheck will prompt with the following:
73 Hello, this is the database check/correct program.
74 Please select the function you want to perform.
75 1) Toggle modify database flag
76 2) Toggle verbose flag
77 3) Repair bad Filename records
78 4) Repair bad Path records
79 5) Eliminate duplicate Filename records
80 6) Eliminate duplicate Path records
81 7) Eliminate orphaned Jobmedia records
82 8) Eliminate orphaned File records
83 9) Eliminate orphaned Path records
84 10) Eliminate orphaned Filename records
85 11) Eliminate orphaned FileSet records
86 12) Eliminate orphaned Client records
87 13) Eliminate orphaned Job records
88 14) Eliminate all Admin records
89 15) Eliminate all Restore records
92 Select function number:
94 By entering 1 or 2, you can toggle the modify database flag (\-f option) and
95 the verbose flag (\-v). It can be helpful and reassuring to turn off the
96 modify database flag, then select one or more of the consistency checks
97 (items 3 through 9) to see what will be done, then toggle the modify flag
98 on and re-run the check.
100 The inconsistencies examined are the following:
103 Duplicate filename records. This can happen if you accidentally run two
104 copies of Bacula at the same time, and they are both adding filenames
105 simultaneously. It is a rare occurrence, but will create an
106 inconsistent database. If this is the case, you will receive error
107 messages during Jobs warning of duplicate database records. If you are
108 not getting these error messages, there is no reason to run this check.
111 Repair bad Filename records. This checks and corrects filenames that have
112 a trailing slash. They should not.
115 Repair bad Path records. This checks and corrects path names that do not
116 have a trailing slash. They should.
119 Duplicate path records. This can happen if you accidentally run two copies
120 of Bacula at the same time, and they are both adding filenames
121 simultaneously. It is a rare occurrence, but will create an
122 inconsistent database. See the item above for why this occurs and how
123 you know it is happening.
126 Orphaned JobMedia records. This happens when a Job record is deleted
127 (perhaps by a user issued SQL statement), but the corresponding JobMedia
128 record (one for each Volume used in the Job) was not deleted. Normally,
129 this should not happen, and even if it does, these records generally do
130 not take much space in your database. However, by running this check,
131 you can eliminate any such orphans.
134 Orphaned File records. This happens when a Job record is deleted (perhaps
135 by a user issued SQL statement), but the corresponding File record (one
136 for each Volume used in the Job) was not deleted. Note, searching for
137 these records can be very time consuming (i.e. it may take hours) for a
138 large database. Normally this should not happen as Bacula takes care to
139 prevent it. Just the same, this check can remove any orphaned File
140 records. It is recommended that you run this once a year since orphaned
141 File records can take a large amount of space in your database. You
142 might want to ensure that you have indexes on JobId, FilenameId, and
143 PathId for the File table in your catalog before running this command.
146 Orphaned Path records. This condition happens any time a directory is
147 deleted from your system and all associated Job records have been
148 purged. During standard purging (or pruning) of Job records, Bacula
149 does not check for orphaned Path records. As a consequence, over a
150 period of time, old unused Path records will tend to accumulate and use
151 space in your database. This check will eliminate them. It is
152 recommended that you run this check at least once a year.
155 Orphaned Filename records. This condition happens any time a file is
156 deleted from your system and all associated Job records have been
157 purged. This can happen quite frequently as there are quite a large
158 number of files that are created and then deleted. In addition, if you
159 do a system update or delete an entire directory, there can be a very
160 large number of Filename records that remain in the catalog but are no
163 During standard purging (or pruning) of Job records, Bacula does not
164 check for orphaned Filename records. As a consequence, over a period of
165 time, old unused Filename records will accumulate and use space in your
166 database. This check will eliminate them. It is strongly recommended
167 that you run this check at least once a year, and for large database
168 (more than 200 Megabytes), it is probably better to run this once every
172 Orphaned Client records. These records can remain in the database long
173 after you have removed a client.
176 Orphaned Job records. If no client is defined for a job or you do not run
177 a job for a long time, you can accumulate old job records. This option
178 allow you to remove jobs that are not attached to any client (and thus
182 All Admin records. This command will remove all Admin records,
183 regardless of their age.
186 All Restore records. This command will remove all Restore records,
187 regardless of their age.
189 By the way, I personally run dbcheck only where I have messed up
190 my database due to a bug in developing Bacula code, so normally
191 you should never need to run dbcheck inspite of the
192 recommendations given above, which are given so that users don't
193 waste their time running dbcheck too often.
200 This manual page was written by Jose Luis Tallon
202 <jltallon@adv\-solutions.net>.
projects / bacula / bacula / blob