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
12 This manual page documents briefly the dbcheck command.
13 dbcheck will not repair your database if it is broken. Please see your
15 vendor's instructions for fixing broken database.
16 dbcheck is a simple program that will search for logical inconsisten‐
18 cies in the Bacula tables in your database, and optionally fix them.
19 It is a database maintenance routine, in the sense that it can detect
20 and remove unused rows, but it is not a database repair routine. To
21 repair a database, see the tools furnished by the database vendor.
22 Normally dbcheck should never need to be run, but if Bacula has crashed
23 or you have a lot of Clients, Pools, or Jobs that you have removed, it
24 could be useful.
25 It is called:
27 Usage: dbcheck [-c config] [-C catalog name] [-d debug_level] []
29 -b batch mode
30 -C catalog name in the director conf file
31 -c director conf filename
32 -dnn set debug level to nn
33 -f fix inconsistencies
34 -v verbose
35 -? print this message
36 If the -c option is given with the Director's conf file, there is no
38 need to enter any of the command line arguments, in particular the
39 working directory as dbcheck will read them from the file.
40 If the -f option is specified, dbcheck will repair (fix) the inconsis‐
42 tencies it finds. Otherwise, it will report only.
43 If the -b option is specified, dbcheck will run in batch mode, and it
45 will proceed to examine and fix (if -f is set) all programmed inconsis‐
46 tency checks. If the -b option is not specified, dbcheck will enter
47 interactive mode and prompt with the following:
48 Hello, this is the database check/correct program. Please select the
50 function you want to perform.
51 1) Toggle modify database flag
52 2) Toggle verbose flag
53 3) Repair bad Filename records
54 4) Repair bad Path records
55 5) Eliminate duplicate Filename records
56 6) Eliminate duplicate Path records
57 7) Eliminate orphaned Jobmedia records
58 8) Eliminate orphaned File records
59 9) Eliminate orphaned Path records
60 10) Eliminate orphaned Filename records
61 11) Eliminate orphaned FileSet records
62 12) Eliminate orphaned Client records
63 13) Eliminate orphaned Job records
64 14) Eliminate all Admin records
65 15) Eliminate all Restore records
66 16) All (3-15)
67 17) Quit Select function number:
68 By entering 1 or 2, you can toggle the modify database flag (-f option)
70 and the verbose flag (-v). It can be helpful and reassuring to turn off
71 the modify database flag, then select one or more of the consistency
72 checks (items 3 through 9) to see what will be done, then toggle the
73 modify flag on and re-run the check.
74 The inconsistencies examined are the following:
76 Duplicate filename records. This can happen if you accidentally run
79 two
80 copies of Bacula at the same time, and they are both adding file‐
81 names
82 simultaneously. It is a rare occurrence, but will create an incon‐
83 sistent
84 database. If this is the case, you will receive error messages dur‐
85 ing Jobs
86 warning of duplicate database records. If you are not getting these
87 error
88 messages, there is no reason to run this check.
89 Repair bad Filename records. This checks and corrects filenames that
91 have a trailing slash. They should not.
92 Repair bad Path records. This checks and corrects path names that do
94 not have a trailing slash. They should.
95 Duplicate path records. This can happen if you accidentally run two
97 copies of Bacula at the same time, and they are both adding file‐
98 names
99 simultaneously. It is a rare occurrence, but will create an incon‐
100 sistent
101 database. See the item above for why this occurs and how you know
102 it is v
103 happening. e
104 r
105 Orphaned JobMedia recordsy. This happens when a Job record is deleted
106 (perhaps by a user issu}ed SQL statement), but the corresponding
107 JobMedia t
108 record (one for each Violume used in the Job) was not deleted. Nor‐
109 mally, this m
110 should not happen, andeeven if it does, these records generally do
111 not take c
112 much space in your doatabase. However, by running this check, you
113 can n
114 eliminate any such orphsans.
115 u
116 Orphaned File records. Thmis happens when a Job record is deleted
117 (perhaps by a user issuied SQL statement), but the corresponding
118 File record n
119 (one for each Volumeg used in the Job) was not deleted. Note,
120 searching for (
121 these records can be {ior a
122 large database. Normal.ly this should not happen as Bacula takes
123 care to e
124 prevent it. Just the .same, this check can remove any orphaned File
125 records. i
126 It is recommended thatt you run this once a year since orphaned File
127 records m
128 can take a large amouant of space in your database. You might
129 want to ensure that yoyu have indexes on JobId, FilenameId, and
130 PathId for the File tatble in your catalog before running this
131 command. a
132 k
133 e
134 h
135 o
136 u
137 r
138 s
139 )
140 Orphaned Path records. This condition happens any time a directory is
141 deleted from your system and all associated Job records have been
142 purged.
143 During standard purging (or pruning) of Job records, Bacula does
144 not check
145 for orphaned Path records. As a consequence, over a period of time,
146 old
147 unused Path records will tend to accumulate and use space in your
148 database.
149 This check will eliminate them. It is recommended that you run this
150 check at least once a year.
151 Orphaned Filename records. This condition happens any time a file is
153 deleted from your system and all associated Job records have been
154 purged.
155 This can happen quite frequently as there are quite a large number
156 of files
157 that are created and then deleted. In addition, if you do a system
158 update or
159 delete an entire directory, there can be a very large number of
160 Filename
161 records that remain in the catalog but are no longer used.
162 During standard purging (or pruning) of Job records, Bacula does
164 not check
165 for orphaned Filename records. As a consequence, over a period of
166 time, old
167 unused Filename records will accumulate and use space in your data‐
168 base. This
169 check will eliminate them. It is strongly recommended that you run
170 this check
171 at least once a year, and for large database (more than 200
172 Megabytes), it is
173 probably better to run this once every 6 months.
174 Orphaned Client records. These records can remain in the database
176 long
177 after you have removed a client.
178 Orphaned Job records. If no client is defined for a job or you do not
180 run a job for a long time, you can accumulate old job records. This
181 option
182 allow you to remove jobs that are not attached to any client (and
183 thus
184 useless).
185 All Admin records. This command will remove all Admin records,
187 regardless of their age.
188 All Restore records. This command will remove all Restore records,
190 regardless of their age.
191 By the way, I personally run dbcheck only where I have messed up my
193 database due to a bug in developing Bacula code, so normally you should
194 never need to run dbcheck inspite of the recommendations given above,
195 which are given so that users don't waste their time running dbcheck
196 too often.
197
200 bls(1), bextract(1).
201
203 This manual page was written by Jose Luis Tallon
204 <jltallon@adv-solutions.net>.
205Kern Sibbald 26 May 2006 DBCHECK(8)