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 May 2006" "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 -dnn set debug level to nn
44 -f fix inconsistencies
48 If the -c option is given with the Director's conf file, there is no
49 need to enter any of the command line arguments, in particular the working
50 directory as dbcheck will read them from the file.
52 If the -f option is specified, dbcheck will repair (fix) the
53 inconsistencies it finds. Otherwise, it will report only.
55 If the -b option is specified, dbcheck will run in batch mode, and
56 it will proceed to examine and fix (if -f is set) all programmed inconsistency
57 checks. If the -b option is not specified, dbcheck will enter
58 interactive mode and prompt with the following:
60 Hello, this is the database check/correct program.
61 Please select the 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
79 Select function number:
81 By entering 1 or 2, you can toggle the modify database flag (-f option) and
82 the verbose flag (-v). It can be helpful and reassuring to turn off the modify
83 database flag, then select one or more of the consistency checks (items 3
84 through 9) to see what will be done, then toggle the modify flag on and re-run
87 The inconsistencies examined are the following:
90 Duplicate filename records. This can happen if you accidentally run two
91 copies of Bacula at the same time, and they are both adding filenames
92 simultaneously. It is a rare occurrence, but will create an inconsistent
93 database. If this is the case, you will receive error messages during Jobs
94 warning of duplicate database records. If you are not getting these error
95 messages, there is no reason to run this check.
98 Repair bad Filename records. This checks and corrects filenames that
99 have a trailing slash. They should not.
102 Repair bad Path records. This checks and corrects path names that do
103 not have a trailing slash. They should.
106 Duplicate path records. This can happen if you accidentally run two
107 copies of Bacula at the same time, and they are both adding filenames
108 simultaneously. It is a rare occurrence, but will create an inconsistent
109 database. See the item above for why this occurs and how you know it is
113 Orphaned JobMedia records. This happens when a Job record is deleted
114 (perhaps by a user issued SQL statement), but the corresponding JobMedia
115 record (one for each Volume used in the Job) was not deleted. Normally, this
116 should not happen, and even if it does, these records generally do not take
117 much space in your database. However, by running this check, you can
118 eliminate any such orphans.
121 Orphaned File records. This happens when a Job record is deleted
122 (perhaps by a user issued SQL statement), but the corresponding File record
123 (one for each Volume used in the Job) was not deleted. Note, searching for
124 these records can be {\bf very} time consuming (i.e. it may take hours) for a
125 large database. Normally this should not happen as Bacula takes care to
126 prevent it. Just the same, this check can remove any orphaned File records.
127 It is recommended that you run this once a year since orphaned File records
128 can take a large amount of space in your database. You might
129 want to ensure that you have indexes on JobId, FilenameId, and
130 PathId for the File table in your catalog before running this
134 Orphaned Path records. This condition happens any time a directory is
135 deleted from your system and all associated Job records have been purged.
136 During standard purging (or pruning) of Job records, Bacula does not check
137 for orphaned Path records. As a consequence, over a period of time, old
138 unused Path records will tend to accumulate and use space in your database.
139 This check will eliminate them. It is recommended that you run this
140 check at least once a year.
143 Orphaned Filename records. This condition happens any time a file is
144 deleted from your system and all associated Job records have been purged.
145 This can happen quite frequently as there are quite a large number of files
146 that are created and then deleted. In addition, if you do a system update or
147 delete an entire directory, there can be a very large number of Filename
148 records that remain in the catalog but are no longer used.
150 During standard purging (or pruning) of Job records, Bacula does not check
151 for orphaned Filename records. As a consequence, over a period of time, old
152 unused Filename records will accumulate and use space in your database. This
153 check will eliminate them. It is strongly recommended that you run this check
154 at least once a year, and for large database (more than 200 Megabytes), it is
155 probably better to run this once every 6 months.
158 Orphaned Client records. These records can remain in the database long
159 after you have removed a client.
162 Orphaned Job records. If no client is defined for a job or you do not
163 run a job for a long time, you can accumulate old job records. This option
164 allow you to remove jobs that are not attached to any client (and thus
168 All Admin records. This command will remove all Admin records,
169 regardless of their age.
172 All Restore records. This command will remove all Restore records,
173 regardless of their age.
175 By the way, I personally run dbcheck only where I have messed up
176 my database due to a bug in developing Bacula code, so normally
177 you should never need to run dbcheck inspite of the
178 recommendations given above, which are given so that users don't
179 waste their time running dbcheck too often.
186 This manual page was written by Jose Luis Tallon
188 <jltallon@adv\-solutions.net>.