Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
DBCHECK(8)	   Network backup, recovery and	verification	    DBCHECK(8)

NAME
	dbcheck	- Bacula's Catalog Database Check/Clean	program

SYNOPSIS
       dbcheck	[options] working-directory bacula-database user password [db-
       host] [dbport]

DESCRIPTION
       This manual page	documents briefly the dbcheck command.

       dbcheck will not	repair your database if	it is broken. Please see  your
       vendor's	instructions for fixing	broken database.

       dbcheck	is  a simple program that will search for logical inconsisten-
       cies in the Bacula tables in your database, and	optionally  fix	 them.
       It  is  a database maintenance routine, in the sense that it can	detect
       and remove unused rows, but it is not a database	repair routine.	To re-
       pair  a database, see the tools furnished by the	database vendor.  Nor-
       mally dbcheck should never need to be run, but if Bacula	has crashed or
       you  have  a  lot  of Clients, Pools, or	Jobs that you have removed, it
       could be	useful.

OPTIONS
       A summary of options is included	below.

       -?     Show version and usage of	program.

       -b     If specified, dbcheck will run in	batch mode, and	it  will  pro-
	      ceed  to examine and fix (if -f is set) all programmed inconsis-
	      tency checks. By default,	dbcheck	will  enter  interactive  mode
	      (see below).

       -C catalog
	      catalog name in the director conf	file.

       -c config
	      If  the  -c option is given with the Director's conf file, there
	      is no need to enter any of the command line arguments,  in  par-
	      ticular the working directory as dbcheck will read them from the
	      file.

       -B     print catalog configuration and exit.

       -d nn  set debug	level to nn.

       -dt    print timestamp in debug output.

       -f     If specified, dbcheck will repair	(fix) the  inconsistencies  it
	      finds.  Otherwise, it will report	only.

       -v     Set verbose mode.

INTERACTIVE MODE
       In interactive mode dbcheck will	prompt with the	following:

       Hello,  this  is	the database check/correct program.  Please select the
       function	you want to perform.
	    1) Toggle modify database flag
	    2) Toggle verbose flag
	    3) Repair bad Filename records
	    4) Repair bad Path records
	    5) Eliminate duplicate Filename records
	    6) Eliminate duplicate Path	records
	    7) Eliminate orphaned Jobmedia records
	    8) Eliminate orphaned File records
	    9) Eliminate orphaned Path records
	   10) Eliminate orphaned Filename records
	   11) Eliminate orphaned FileSet records
	   12) Eliminate orphaned Client records
	   13) Eliminate orphaned Job records
	   14) Eliminate all Admin records
	   15) Eliminate all Restore records
	   16) All (3-15)
	   17) Quit Select function number:

       By entering 1 or	2, you can toggle the modify database flag (-f option)
       and  the	 verbose  flag (-v).  It can be	helpful	and reassuring to turn
       off the modify database flag, then select one or	more  of  the  consis-
       tency  checks (items 3 through 9) to see	what will be done, then	toggle
       the modify flag on and re-run the check.

       The inconsistencies examined are	the following:

	Duplicate filename records.  This can happen if	you  accidentally  run
       two
	  copies  of  Bacula  at the same time,	and they are both adding file-
       names
	  simultaneously.  It is a rare	occurrence, but	will create an
	  inconsistent database.  If this is the case, you will	receive	error
	  messages during Jobs warning of duplicate database records.  If  you
       are
	  not  getting	these  error  messages,	there is no reason to run this
       check.

	Repair bad Filename records.  This checks and corrects filenames  that
       have
	  a trailing slash.  They should not.

	 Repair	bad Path records.  This	checks and corrects path names that do
       not
	  have a trailing slash.  They should.

	Duplicate path records.	 This can happen if you	accidentally  run  two
       copies
	  of Bacula at the same	time, and they are both	adding filenames
	  simultaneously.  It is a rare	occurrence, but	will create an
	  inconsistent	database.   See	the item above for why this occurs and
       how
	  you know it is happening.

	Orphaned JobMedia records.  This happens when a	Job record is deleted
	  (perhaps by a	user issued SQL	statement), but	the corresponding Job-
       Media
	  record  (one for each	Volume used in the Job)	was not	deleted.  Nor-
       mally,
	  this should not happen, and even if it does, these records generally
       do
	  not  take  much  space  in  your database.  However, by running this
       check,
	  you can eliminate any	such orphans.

	Orphaned File records.	This happens when  a  Job  record  is  deleted
       (perhaps
	  by  a	 user issued SQL statement), but the corresponding File	record
       (one
	  for each Volume used in the Job) was not deleted.   Note,  searching
       for
	  these	 records  can be very time consuming (i.e.  it may take	hours)
       for a
	  large	database.  Normally this should	not  happen  as	 Bacula	 takes
       care to
	  prevent it.  Just the	same, this check can remove any	orphaned File
	  records.   It	is recommended that you	run this once a	year since or-
       phaned
	  File records can take	a large	amount of space	in your	database.  You
	  might	want to	ensure that you	have indexes on	JobId, FilenameId, and
	  PathId for the File table in your catalog before running  this  com-
       mand.

	Orphaned Path records.	This condition happens any time	a directory is
	  deleted from your system and all associated Job records have been
	  purged.  During standard purging (or pruning)	of Job records,	Bacula
	  does not check for orphaned Path records.  As	a consequence, over a
	  period  of time, old unused Path records will	tend to	accumulate and
       use
	  space	in your	database.  This	check will eliminate them.  It is
	  recommended that you run this	check at least once a year.

	Orphaned Filename records.  This condition happens any time a file is
	  deleted from your system and all associated Job records have been
	  purged.  This	can happen quite frequently as there are quite a large
	  number of files that are created and then deleted.  In addition,  if
       you
	  do  a	 system	 update	 or delete an entire directory,	there can be a
       very
	  large	number of Filename records that	remain in the catalog but  are
       no
	  longer used.

	  During standard purging (or pruning) of Job records, Bacula does not
	  check	 for  orphaned Filename	records.  As a consequence, over a pe-
       riod of
	  time,	old unused Filename records will accumulate and	use  space  in
       your
	  database.   This  check  will	eliminate them.	 It is strongly	recom-
       mended
	  that you run this check at least once	a year,	and for	large database
	  (more	than 200 Megabytes), it	is probably better to  run  this  once
       every
	  6 months.

	 Orphaned  Client  records.   These records can	remain in the database
       long
	  after	you have removed a client.

	Orphaned Job records.  If no client is defined for a job or you	do not
       run
	  a job	for a long time, you can accumulate old	job records.  This op-
       tion
	  allow	you to remove jobs that	are not	attached to  any  client  (and
       thus
	  useless).

	All Admin records. This	command	will remove all	Admin records,
	  regardless of	their age.

	All Restore records. This command will remove all Restore records,
	  regardless of	their age.

       By  the	way,  I	 personally run	dbcheck	only where I have messed up my
       database	due to a bug in	developing Bacula code,	so normally you	should
       never  need  to run dbcheck inspite of the recommendations given	above,
       which are given so that users don't waste their	time  running  dbcheck
       too often.

SEE ALSO
       bls(1), bextract(1).

AUTHOR
       This    manual	 page	 was	written	   by	 Jose	 Luis	Tallon
       <jltallon@adv-solutions.net>.

COPYRIGHT
       This man	page document is released under	the BSD	2-Clause license.

Kern Sibbald		       26 September 2009		    DBCHECK(8)

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | INTERACTIVE MODE | SEE ALSO | AUTHOR | COPYRIGHT

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=dbcheck&sektion=8&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help