1DBCHECK(8) Network backup, recovery and verification DBCHECK(8)
2
6 dbcheck - Bacula's Catalog Database Check/Clean program
7
9 bcopy [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 It is called:
28 Usage: dbcheck [-c config] [-C catalog name] [-d debug_level] []
30 -b batch mode
31 -C catalog name in the director conf file
32 -c director conf filename
33 -B print catalog configuration and exit
34 -dnn set debug level to nn
35 -dt print timestamp in debug output
36 -f fix inconsistencies
37 -v verbose
38 -? print this message
39 If the -c option is given with the Director's conf file, there is no
41 need to enter any of the command line arguments, in particular the
42 working directory as dbcheck will read them from the file.
43 If the -f option is specified, dbcheck will repair (fix) the inconsis‐
45 tencies it finds. Otherwise, it will report only.
46 If the -b option is specified, dbcheck will run in batch mode, and it
48 will proceed to examine and fix (if -f is set) all programmed inconsis‐
49 tency checks. If the -b option is not specified, dbcheck will enter
50 interactive mode and prompt with the following:
51 Hello, this is the database check/correct program. Please select the
53 function you want to perform.
54 1) Toggle modify database flag
55 2) Toggle verbose flag
56 3) Repair bad Filename records
57 4) Repair bad Path records
58 5) Eliminate duplicate Filename records
59 6) Eliminate duplicate Path records
60 7) Eliminate orphaned Jobmedia records
61 8) Eliminate orphaned File records
62 9) Eliminate orphaned Path records
63 10) Eliminate orphaned Filename records
64 11) Eliminate orphaned FileSet records
65 12) Eliminate orphaned Client records
66 13) Eliminate orphaned Job records
67 14) Eliminate all Admin records
68 15) Eliminate all Restore records
69 16) All (3-15)
70 17) Quit Select function number:
71 By entering 1 or 2, you can toggle the modify database flag (-f option)
73 and the verbose flag (-v). It can be helpful and reassuring to turn
74 off the modify database flag, then select one or more of the consis‐
75 tency checks (items 3 through 9) to see what will be done, then toggle
76 the modify flag on and re-run the check.
77 The inconsistencies examined are the following:
79 Duplicate filename records. This can happen if you accidentally run
81 two
82 copies of Bacula at the same time, and they are both adding file‐
83 names
84 simultaneously. It is a rare occurrence, but will create an
85 inconsistent database. If this is the case, you will receive error
86 messages during Jobs warning of duplicate database records. If you
87 are
88 not getting these error messages, there is no reason to run this
89 check.
90 Repair bad Filename records. This checks and corrects filenames that
92 have
93 a trailing slash. They should not.
94 Repair bad Path records. This checks and corrects path names that do
96 not
97 have a trailing slash. They should.
98 Duplicate path records. This can happen if you accidentally run two
100 copies
101 of Bacula at the same time, and they are both adding filenames
102 simultaneously. It is a rare occurrence, but will create an
103 inconsistent database. See the item above for why this occurs and
104 how
105 you know it is happening.
106 Orphaned JobMedia records. This happens when a Job record is deleted
108 (perhaps by a user issued SQL statement), but the corresponding Job‐
109 Media
110 record (one for each Volume used in the Job) was not deleted. Nor‐
111 mally,
112 this should not happen, and even if it does, these records generally
113 do
114 not take much space in your database. However, by running this
115 check,
116 you can eliminate any such orphans.
117 Orphaned File records. This happens when a Job record is deleted
119 (perhaps
120 by a user issued SQL statement), but the corresponding File record
121 (one
122 for each Volume used in the Job) was not deleted. Note, searching
123 for
124 these records can be very time consuming (i.e. it may take hours)
125 for a
126 large database. Normally this should not happen as Bacula takes
127 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
130 orphaned
131 File records can take a large amount of space in your database. You
132 might want to ensure that you have indexes on JobId, FilenameId, and
133 PathId for the File table in your catalog before running this com‐
134 mand.
135 Orphaned Path records. This condition happens any time a directory is
137 deleted from your system and all associated Job records have been
138 purged. During standard purging (or pruning) of Job records, Bacula
139 does not check for orphaned Path records. As a consequence, over a
140 period of time, old unused Path records will tend to accumulate and
141 use
142 space in your database. This check will eliminate them. It is
143 recommended that you run this check at least once a year.
144 Orphaned Filename records. This condition happens any time a file is
146 deleted from your system and all associated Job records have been
147 purged. This can happen quite frequently as there are quite a large
148 number of files that are created and then deleted. In addition, if
149 you
150 do a system update or delete an entire directory, there can be a
151 very
152 large number of Filename records that remain in the catalog but are
153 no
154 longer used.
155 During standard purging (or pruning) of Job records, Bacula does not
157 check for orphaned Filename records. As a consequence, over a
158 period of
159 time, old unused Filename records will accumulate and use space in
160 your
161 database. This check will eliminate them. It is strongly recom‐
162 mended
163 that you run this check at least once a year, and for large database
164 (more than 200 Megabytes), it is probably better to run this once
165 every
166 6 months.
167 Orphaned Client records. These records can remain in the database
169 long
170 after you have removed a client.
171 Orphaned Job records. If no client is defined for a job or you do not
173 run
174 a job for a long time, you can accumulate old job records. This
175 option
176 allow you to remove jobs that are not attached to any client (and
177 thus
178 useless).
179 All Admin records. This command will remove all Admin records,
181 regardless of their age.
182 All Restore records. This command will remove all Restore records,
184 regardless of their age.
185 By the way, I personally run dbcheck only where I have messed up my
187 database due to a bug in developing Bacula code, so normally you should
188 never need to run dbcheck inspite of the recommendations given above,
189 which are given so that users don't waste their time running dbcheck
190 too often.
191
194 bls(1), bextract(1).
195
197 This manual page was written by Jose Luis Tallon
198 <jltallon@adv-solutions.net>.
199Kern Sibbald 26 September 2009 DBCHECK(8)