1DBCHECK(8) Network backup, recovery and verification DBCHECK(8)
2
6 dbcheck - Bacula's Catalog Database Check/Clean program
7
9 dbcheck [options] working-directory bacula-database user password
10 [dbhost] [dbport]
11
13 This manual page documents briefly the dbcheck command.
14 dbcheck will not repair your database if it is broken. Please see your
16 vendor's instructions for fixing broken database.
17 dbcheck is a simple program that will search for logical inconsisten‐
19 cies in the Bacula tables in your database, and optionally fix them.
20 It is a database maintenance routine, in the sense that it can detect
21 and remove unused rows, but it is not a database repair routine. To
22 repair a database, see the tools furnished by the database vendor.
23 Normally dbcheck should never need to be run, but if Bacula has crashed
24 or you have a lot of Clients, Pools, or Jobs that you have removed, it
25 could be useful.
26
28 A summary of options is included below.
29 -? Show version and usage of program.
31 -b If specified, dbcheck will run in batch mode, and it will pro‐
33 ceed to examine and fix (if -f is set) all programmed inconsis‐
34 tency checks. By default, dbcheck will enter interactive mode
35 (see below).
36 -C catalog
38 catalog name in the director conf file.
39 -c config
41 If the -c option is given with the Director's conf file, there
42 is no need to enter any of the command line arguments, in par‐
43 ticular the working directory as dbcheck will read them from the
44 file.
45 -B print catalog configuration and exit.
47 -d nn set debug level to nn.
49 -dt print timestamp in debug output.
51 -f If specified, dbcheck will repair (fix) the inconsistencies it
53 finds. Otherwise, it will report only.
54 -v Set verbose mode.
56
58 In interactive mode dbcheck will prompt with the following:
59 Hello, this is the database check/correct program. Please select the
61 function you want to perform.
62 1) Toggle modify database flag
63 2) Toggle verbose flag
64 3) Repair bad Filename records
65 4) Repair bad Path records
66 5) Eliminate duplicate Filename records
67 6) Eliminate duplicate Path records
68 7) Eliminate orphaned Jobmedia records
69 8) Eliminate orphaned File records
70 9) Eliminate orphaned Path records
71 10) Eliminate orphaned Filename records
72 11) Eliminate orphaned FileSet records
73 12) Eliminate orphaned Client records
74 13) Eliminate orphaned Job records
75 14) Eliminate all Admin records
76 15) Eliminate all Restore records
77 16) All (3-15)
78 17) Quit Select function number:
79 By entering 1 or 2, you can toggle the modify database flag (-f option)
81 and the verbose flag (-v). It can be helpful and reassuring to turn
82 off the modify database flag, then select one or more of the consis‐
83 tency checks (items 3 through 9) to see what will be done, then toggle
84 the modify flag on and re-run the check.
85 The inconsistencies examined are the following:
87 Duplicate filename records. This can happen if you accidentally run
89 two
90 copies of Bacula at the same time, and they are both adding file‐
91 names
92 simultaneously. It is a rare occurrence, but will create an
93 inconsistent database. If this is the case, you will receive error
94 messages during Jobs warning of duplicate database records. If you
95 are
96 not getting these error messages, there is no reason to run this
97 check.
98 Repair bad Filename records. This checks and corrects filenames that
100 have
101 a trailing slash. They should not.
102 Repair bad Path records. This checks and corrects path names that do
104 not
105 have a trailing slash. They should.
106 Duplicate path records. This can happen if you accidentally run two
108 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
112 how
113 you know it is happening.
114 Orphaned JobMedia records. This happens when a Job record is deleted
116 (perhaps by a user issued SQL statement), but the corresponding Job‐
117 Media
118 record (one for each Volume used in the Job) was not deleted. Nor‐
119 mally,
120 this should not happen, and even if it does, these records generally
121 do
122 not take much space in your database. However, by running this
123 check,
124 you can eliminate any such orphans.
125 Orphaned File records. This happens when a Job record is deleted
127 (perhaps
128 by a user issued SQL statement), but the corresponding File record
129 (one
130 for each Volume used in the Job) was not deleted. Note, searching
131 for
132 these records can be very time consuming (i.e. it may take hours)
133 for a
134 large database. Normally this should not happen as Bacula takes
135 care to
136 prevent it. Just the same, this check can remove any orphaned File
137 records. It is recommended that you run this once a year since
138 orphaned
139 File records can take a large amount of space in your database. You
140 might want to ensure that you have indexes on JobId, FilenameId, and
141 PathId for the File table in your catalog before running this com‐
142 mand.
143 Orphaned Path records. This condition happens any time a directory is
145 deleted from your system and all associated Job records have been
146 purged. During standard purging (or pruning) of Job records, Bacula
147 does not check for orphaned Path records. As a consequence, over a
148 period of time, old unused Path records will tend to accumulate and
149 use
150 space in your database. This check will eliminate them. It is
151 recommended that you run this check at least once a year.
152 Orphaned Filename records. This condition happens any time a file is
154 deleted from your system and all associated Job records have been
155 purged. This can happen quite frequently as there are quite a large
156 number of files that are created and then deleted. In addition, if
157 you
158 do a system update or delete an entire directory, there can be a
159 very
160 large number of Filename records that remain in the catalog but are
161 no
162 longer used.
163 During standard purging (or pruning) of Job records, Bacula does not
165 check for orphaned Filename records. As a consequence, over a
166 period of
167 time, old unused Filename records will accumulate and use space in
168 your
169 database. This check will eliminate them. It is strongly recom‐
170 mended
171 that you run this check at least once a year, and for large database
172 (more than 200 Megabytes), it is probably better to run this once
173 every
174 6 months.
175 Orphaned Client records. These records can remain in the database
177 long
178 after you have removed a client.
179 Orphaned Job records. If no client is defined for a job or you do not
181 run
182 a job for a long time, you can accumulate old job records. This
183 option
184 allow you to remove jobs that are not attached to any client (and
185 thus
186 useless).
187 All Admin records. This command will remove all Admin records,
189 regardless of their age.
190 All Restore records. This command will remove all Restore records,
192 regardless of their age.
193 By the way, I personally run dbcheck only where I have messed up my
195 database due to a bug in developing Bacula code, so normally you should
196 never need to run dbcheck inspite of the recommendations given above,
197 which are given so that users don't waste their time running dbcheck
198 too often.
199
202 bls(1), bextract(1).
203
205 This manual page was written by Jose Luis Tallon
206 <jltallon@adv-solutions.net>.
207
209 This man page document is released under the BSD 2-Clause license.
210Kern Sibbald 26 September 2009 DBCHECK(8)