4 \chapter{Volume Utility Tools}
5 \label{TheUtilityChapter}
6 \index[general]{Volume Utility Tools}
7 \index[general]{Tools!Volume Utility}
9 This document describes the utility programs written to aid Bacula users and
10 developers in dealing with Volumes external to Bacula.
12 \section{Specifying the Configuration File}
13 \index[general]{Specifying the Configuration File}
15 Starting with version 1.27, each of the following programs requires a valid
16 Storage daemon configuration file (actually, the only part of the
17 configuration file that these programs need is the {\bf Device} resource
18 definitions). This permits the programs to find the configuration parameters
19 for your archive device (generally a tape drive). By default, they read {\bf
20 bacula-sd.conf} in the current directory, but you may specify a different
21 configuration file using the {\bf -c} option.
24 \section{Specifying a Device Name For a Tape}
25 \index[general]{Tape!Specifying a Device Name For a}
26 \index[general]{Specifying a Device Name For a Tape}
28 Each of these programs require a {\bf device-name} where the Volume can be
29 found. In the case of a tape, this is the physical device name such as {\bf
30 /dev/nst0} or {\bf /dev/rmt/0ubn} depending on your system. For the program to
31 work, it must find the identical name in the Device resource of the
32 configuration file. See below for specifying Volume names.
34 Please note that if you have Bacula running and you ant to use
35 one of these programs, you will either need to stop the Storage daemon, or
36 {\bf unmount} any tape drive you want to use, otherwise the drive
37 will {\bf busy} because Bacula is using it.
40 \section{Specifying a Device Name For a File}
41 \index[general]{File!Specifying a Device Name For a}
42 \index[general]{Specifying a Device Name For a File}
44 If you are attempting to read or write an archive file rather than a tape, the
45 {\bf device-name} should be the full path to the archive location including
46 the filename. The filename (last part of the specification) will be stripped
47 and used as the Volume name, and the path (first part before the filename)
48 must have the same entry in the configuration file. So, the path is equivalent
49 to the archive device name, and the filename is equivalent to the volume name.
52 \section{Specifying Volumes}
53 \index[general]{Volumes!Specifying}
54 \index[general]{Specifying Volumes}
56 In general, you must specify the Volume name to each of the programs below
57 (with the exception of {\bf btape}). The best method to do so is to specify a
58 {\bf bootstrap} file on the command line with the {\bf -b} option. As part of
59 the bootstrap file, you will then specify the Volume name or Volume names if
60 more than one volume is needed. For example, suppose you want to read tapes
61 {\bf tape1} and {\bf tape2}. First construct a {\bf bootstrap} file named say,
62 {\bf list.bsr} which contains:
70 where each Volume is separated by a vertical bar. Then simply use:
74 ./bls -b list.bsr /dev/nst0
78 In the case of Bacula Volumes that are on files, you may simply append volumes
83 ./bls /tmp/test1\|test2
87 where the backslash (\textbackslash{}) was necessary as a shell escape to
88 permit entering the vertical bar (|).
90 And finally, if you feel that specifying a Volume name is a bit complicated
91 with a bootstrap file, you can use the {\bf -V} option (on all programs except
92 {\bf bcopy}) to specify one or more Volume names separated by the vertical bar
97 ./bls -V Vol001 /dev/nst0
101 You may also specify an asterisk (*) to indicate that the program should
102 accept any volume. For example:
113 \index[general]{program!bls}
115 {\bf bls} can be used to do an {\bf ls} type listing of a {\bf Bacula} tape or
120 Usage: bls [options] <device-name>
121 -b <file> specify a bootstrap file
122 -c <file> specify a config file
123 -d <level> specify debug level
124 -e <file> exclude list
125 -i <file> include list
128 (no j or k option) list saved files
130 -p proceed inspite of errors
132 -V specify Volume names (separated by |)
133 -? print this message
137 For example, to list the contents of a tape:
141 ./bls -V Volume-name /dev/nst0
145 Or to list the contents of a file:
149 ./bls /tmp/Volume-name
151 ./bls -V Volume-name /tmp
155 Note that, in the case of a file, the Volume name becomes the filename, so in
156 the above example, you will replace the {\bf Volume-name} with the name of the volume
159 Normally if no options are specified, {\bf bls} will produce the equivalent
160 output to the {\bf ls -l} command for each file on the tape. Using other
161 options listed above, it is possible to display only the Job records, only the
162 tape blocks, etc. For example:
168 bls: butil.c:148 Using device: /tmp
169 drwxrwxr-x 3 k k 4096 02-10-19 21:08 /home/kern/bacula/k/src/dird/
170 drwxrwxr-x 2 k k 4096 02-10-10 18:59 /home/kern/bacula/k/src/dird/CVS/
171 -rw-rw-r-- 1 k k 54 02-07-06 18:02 /home/kern/bacula/k/src/dird/CVS/Root
172 -rw-rw-r-- 1 k k 16 02-07-06 18:02 /home/kern/bacula/k/src/dird/CVS/Repository
173 -rw-rw-r-- 1 k k 1783 02-10-10 18:59 /home/kern/bacula/k/src/dird/CVS/Entries
174 -rw-rw-r-- 1 k k 97506 02-10-18 21:07 /home/kern/bacula/k/src/dird/Makefile
175 -rw-r--r-- 1 k k 3513 02-10-18 21:02 /home/kern/bacula/k/src/dird/Makefile.in
176 -rw-rw-r-- 1 k k 4669 02-07-06 18:02 /home/kern/bacula/k/src/dird/README-config
177 -rw-r--r-- 1 k k 4391 02-09-14 16:51 /home/kern/bacula/k/src/dird/authenticate.c
178 -rw-r--r-- 1 k k 3609 02-07-07 16:41 /home/kern/bacula/k/src/dird/autoprune.c
179 -rw-rw-r-- 1 k k 4418 02-10-18 21:03 /home/kern/bacula/k/src/dird/bacula-dir.conf
181 -rw-rw-r-- 1 k k 83 02-08-31 19:19 /home/kern/bacula/k/src/dird/.cvsignore
182 bls: Got EOF on device /tmp
187 \subsection{Listing Jobs}
188 \index[general]{Listing Jobs with bls}
189 \index[general]{bls!Listing Jobs}
191 If you are listing a Volume to determine what Jobs to restore, normally the
192 {\bf -j} option provides you with most of what you will need as long as you
193 don't have multiple clients. For example,
197 ./bls -j -V Test1 -c stored.conf DDS-4
198 bls: butil.c:258 Using device: "DDS-4" for reading.
199 11-Jul 11:54 bls: Ready to read from volume "Test1" on device "DDS-4" (/dev/nst0).
200 Volume Record: File:blk=0:1 SessId=4 SessTime=1121074625 JobId=0 DataLen=165
201 Begin Job Session Record: File:blk=0:2 SessId=4 SessTime=1121074625 JobId=1 Level=F Type=B
202 Begin Job Session Record: File:blk=0:3 SessId=5 SessTime=1121074625 JobId=5 Level=F Type=B
203 Begin Job Session Record: File:blk=0:6 SessId=3 SessTime=1121074625 JobId=2 Level=F Type=B
204 Begin Job Session Record: File:blk=0:13 SessId=2 SessTime=1121074625 JobId=4 Level=F Type=B
205 End Job Session Record: File:blk=0:99 SessId=3 SessTime=1121074625 JobId=2 Level=F Type=B
206 Files=168 Bytes=1,732,978 Errors=0 Status=T
207 End Job Session Record: File:blk=0:101 SessId=2 SessTime=1121074625 JobId=4 Level=F Type=B
208 Files=168 Bytes=1,732,978 Errors=0 Status=T
209 End Job Session Record: File:blk=0:108 SessId=5 SessTime=1121074625 JobId=5 Level=F Type=B
210 Files=168 Bytes=1,732,978 Errors=0 Status=T
211 End Job Session Record: File:blk=0:109 SessId=4 SessTime=1121074625 JobId=1 Level=F Type=B
212 Files=168 Bytes=1,732,978 Errors=0 Status=T
213 11-Jul 11:54 bls: End of Volume at file 1 on device "DDS-4" (/dev/nst0), Volume "Test1"
214 11-Jul 11:54 bls: End of all volumes.
218 shows a full save followed by two incremental saves.
220 Adding the {\bf -v} option will display virtually all information that is
221 available for each record:
223 \subsection{Listing Blocks}
224 \index[general]{Listing Blocks with bls}
225 \index[general]{bls!Listing Blocks}
227 Normally, except for debugging purposes, you will not need to list Bacula
228 blocks (the "primitive" unit of Bacula data on the Volume). However, you can
233 ./bls -k /tmp/File002
234 bls: butil.c:148 Using device: /tmp
240 bls: Got EOF on device /tmp
241 End of File on device
245 By adding the {\bf -v} option, you can get more information, which can be
246 useful in knowing what sessions were written to the volume:
250 ./bls -k -v /tmp/File002
252 Id : Bacula 0.9 mortal
257 LabelType : VOL_LABEL
263 Date label written: 2002-10-19 at 21:16
264 Block: 1 blen=64512 First rec FI=VOL_LABEL SessId=1 SessTim=1035062102 Strm=0 rlen=147
265 Block: 2 blen=64512 First rec FI=6 SessId=1 SessTim=1035062102 Strm=DATA rlen=4087
266 Block: 3 blen=64512 First rec FI=12 SessId=1 SessTim=1035062102 Strm=DATA rlen=5902
267 Block: 4 blen=64512 First rec FI=19 SessId=1 SessTim=1035062102 Strm=DATA rlen=28382
269 Block: 65 blen=64512 First rec FI=83 SessId=1 SessTim=1035062102 Strm=DATA rlen=1873
270 Block: 66 blen=19195 First rec FI=83 SessId=1 SessTim=1035062102 Strm=DATA rlen=2973
271 bls: Got EOF on device /tmp
272 End of File on device
276 Armed with the SessionId and the SessionTime, you can extract just about
279 If you want to know even more, add a second {\bf -v} to the command line to
280 get a dump of every record in every block.
284 ./bls -k -v -v /tmp/File002
285 bls: block.c:79 Dump block 80f8ad0: size=64512 BlkNum=1
286 Hdrcksum=b1bdfd6d cksum=b1bdfd6d
287 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=VOL_LABEL Strm=0 len=147 p=80f8b40
288 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=SOS_LABEL Strm=-7 len=122 p=80f8be7
289 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=1 Strm=UATTR len=86 p=80f8c75
290 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=2 Strm=UATTR len=90 p=80f8cdf
291 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=3 Strm=UATTR len=92 p=80f8d4d
292 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=3 Strm=DATA len=54 p=80f8dbd
293 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=3 Strm=MD5 len=16 p=80f8e07
294 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=4 Strm=UATTR len=98 p=80f8e2b
295 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=4 Strm=DATA len=16 p=80f8ea1
296 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=4 Strm=MD5 len=16 p=80f8ec5
297 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=5 Strm=UATTR len=96 p=80f8ee9
298 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=5 Strm=DATA len=1783 p=80f8f5d
299 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=5 Strm=MD5 len=16 p=80f9668
300 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=UATTR len=95 p=80f968c
301 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=DATA len=32768 p=80f96ff
302 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=DATA len=32768 p=8101713
303 bls: block.c:79 Dump block 80f8ad0: size=64512 BlkNum=2
304 Hdrcksum=9acc1e7f cksum=9acc1e7f
305 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=contDATA len=4087 p=80f8b40
306 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=DATA len=31970 p=80f9b4b
307 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=MD5 len=16 p=8101841
314 \index[general]{Bextract}
315 \index[general]{program!bextract}
317 If you find yourself using {\bf bextract}, you probably have done
318 something wrong. For example, if you are trying to recover a file
319 but are having problems, please see the \borgxrlink{Restoring When Things Go Wrong}{database_restore}{main}{section} of the \mainman{}.
321 Normally, you will restore files by running a {\bf Restore} Job from the {\bf
322 Console} program. However, {\bf bextract} can be used to extract a single file
323 or a list of files from a Bacula tape or file. In fact, {\bf bextract} can be
324 a useful tool to restore files to an empty system assuming you are able to
325 boot, you have statically linked {\bf bextract} and you have an appropriate
326 {\bf bootstrap} file.
328 Please note that some of the current limitations of bextract are:
331 \item It cannot restore access control lists (ACL) that have been
332 backed up along with the file data.
333 \item It cannot restore encrypted files.
334 \item The command line length is relatively limited,
335 which means that you cannot enter a huge number of volumes. If you need to
336 enter more volumes than the command line supports, please use a bootstrap
346 Usage: bextract [-d debug_level] <device-name> <directory-to-store-files>
347 -b <file> specify a bootstrap file
348 -dnn set debug level to nn
349 -e <file> exclude list
350 -i <file> include list
351 -p proceed inspite of I/O errors
352 -V specify Volume names (separated by |)
353 -? print this message
357 where {\bf device-name} is the Archive Device (raw device name or full
358 filename) of the device to be read, and {\bf directory-to-store-files} is a
359 path prefix to prepend to all the files restored.
361 NOTE: On Windows systems, if you specify a prefix of say d:/tmp, any file that
362 would have been restored to {\bf c:/My Documents} will be restored to {\bf
363 d:/tmp/My Documents}. That is, the original drive specification will be
364 stripped. If no prefix is specified, the file will be restored to the original
367 \subsection{Extracting with Include or Exclude Lists}
368 \index[general]{Lists!Extracting with Include or Exclude}
369 \index[general]{Extracting with Include or Exclude Lists}
371 Using the {\bf -e} option, you can specify a file containing a list of files
372 to be excluded. Wildcards can be used in the exclusion list. This option will
373 normally be used in conjunction with the {\bf -i} option (see below). Both the
374 {\bf -e} and the {\bf -i} options may be specified at the same time as the
375 {\bf -b} option. The bootstrap filters will be applied first, then the include
376 list, then the exclude list.
378 Likewise, and probably more importantly, with the {\bf -i} option, you can
379 specify a file that contains a list (one file per line) of files and
380 directories to include to be restored. The list must contain the full filename
381 with the path. If you specify a path name only, all files and subdirectories
382 of that path will be restored. If you specify a line containing only the
383 filename (e.g. {\bf my-file.txt}) it probably will not be extracted because
384 you have not specified the full path.
386 For example, if the file {\bf include-list} contains:
399 ./bextract -i include-list -V Volume /dev/nst0 /tmp
403 will restore from the Bacula archive {\bf /dev/nst0} all files and directories
404 in the backup from {\bf /home/kern/bacula} and from {\bf /usr/local/bin}. The
405 restored files will be placed in a file of the original name under the
406 directory {\bf /tmp} (i.e. /tmp/home/kern/bacula/... and
407 /tmp/usr/local/bin/...).
409 \subsection{Extracting With a Bootstrap File}
410 \index[general]{File!Extracting With a Bootstrap}
411 \index[general]{Extracting With a Bootstrap File}
413 The {\bf -b} option is used to specify a {\bf bootstrap} file containing the
414 information needed to restore precisely the files you want. Specifying a {\bf
415 bootstrap} file is optional but recommended because it gives you the most
416 control over which files will be restored. For more details on the {\bf
417 bootstrap} file, please see
418 \borgxrlink{Restoring Files with the Bootstrap File}{BootstrapChapter}{main}{chapter} of the \mainman{}.
419 Note, you may also use a bootstrap file produced by the {\bf restore} command. For example:
423 ./bextract -b bootstrap-file /dev/nst0 /tmp
427 The bootstrap file allows detailed specification of what files you want
428 restored (extracted). You may specify a bootstrap file and include and/or
429 exclude files at the same time. The bootstrap conditions will first be
430 applied, and then each file record seen will be compared to the include and
433 \subsection{Extracting From Multiple Volumes}
434 \index[general]{Volumes!Extracting From Multiple}
435 \index[general]{Extracting From Multiple Volumes}
437 If you wish to extract files that span several Volumes, you can specify the
438 Volume names in the bootstrap file or you may specify the Volume names on the
439 command line by separating them with a vertical bar. See the section above
440 under the {\bf bls} program entitled {\bf Listing Multiple Volumes} for more
441 information. The same techniques apply equally well to the {\bf bextract}
442 program or read the \borgxrlink{Restoring Files with the Bootstrap File}{BootstrapChapter}{main}{chapter} of the \mainman{}.
447 \index[general]{bscan}
448 \index[general]{program!bscan}
450 If you find yourself using this program, you have probably done something
451 wrong. For example, the best way to recover a lost or damaged Bacula
452 database is to reload the database by using the bootstrap file that
453 was written when you saved it (default bacula-dir.conf file).
455 The {\bf bscan} program can be used to re-create a database (catalog)
456 records from the backup information written to one or more Volumes. This
457 is normally needed only if one or more Volumes have been pruned or purged
458 from your catalog so that the records on the Volume are no longer in the
459 catalog, or for Volumes that you have archived. Note, if you scan in
460 Volumes that were previously purged, you will be able to do restores from
461 those Volumes. However, unless you modify the Job and File retention times
462 for the Jobs that were added by scanning, the next time you run any backup Job
463 with the same name, the records will be pruned again. Since it takes a
464 long time to scan Volumes this can be very frustrating.
466 With some care, {\bf bscan} can also be used to synchronize your existing
467 catalog with a Volume. Although we have never seen a case of bscan
468 damaging a catalog, since bscan modifies your catalog, we recommend that
469 you do a simple ASCII backup of your database before running {\bf bscan}
470 just to be sure. See \borgxrlink{Compacting Your Database}{CompactingMySQL}{main}{section} of the \mainman{} for the details of making a copy of your database.
472 {\bf bscan} can also be useful in a disaster recovery situation, after the
473 loss of a hard disk, if you do not have a valid {\bf bootstrap} file for
474 reloading your system, or if a Volume has been recycled but not overwritten,
475 you can use {\bf bscan} to re-create your database, which can then be used to
476 {\bf restore} your system or a file to its previous state.
483 Usage: bscan [options] <bacula-archive>
484 -b bootstrap specify a bootstrap file
485 -c <file> specify configuration file
486 -d <nn> set debug level to nn
487 -m update media info in database
488 -n <name> specify the database name (default bacula)
489 -u <user> specify database user name (default bacula)
490 -P <password> specify database password (default none)
491 -h <host> specify database host (default NULL)
492 -p proceed inspite of I/O errors
494 -s synchronize or store in database
496 -V <Volumes> specify Volume names (separated by |)
497 -w <dir> specify working directory (default from conf file)
498 -? print this message
502 If you are using MySQL or PostgreSQL, there is no need to supply a working
503 directory since in that case, bscan knows where the databases are. However, if
504 you have provided security on your database, you may need to supply either the
505 database name ({\bf -b} option), the user name ({\bf -u} option), and/or the
506 password ({\bf -p}) options.
508 NOTE: before {\bf bscan} can work, it needs at least a bare bones valid
509 database. If your database exists but some records are missing because
510 they were pruned, then you are all set. If your database was lost or
511 destroyed, then you must first ensure that you have the SQL program running
512 (MySQL or PostgreSQL), then you must create the Bacula database (normally
513 named bacula), and you must create the Bacula tables using the scripts in
514 the {\bf cats} directory. This is explained in the
515 \borgxrlink{Installation}{CreateDatabase}{main}{chapter} of the \mainman{}. Finally, before
516 scanning into an empty database, you must start and stop the Director with
517 the appropriate bacula-dir.conf file so that it can create the Client and
518 Storage records which are not stored on the Volumes. Without these
519 records, scanning is unable to connect the Job records to the proper
522 Forgetting for the moment the extra complications of a full rebuild of
523 your catalog, let's suppose that you did a backup to Volumes "Vol001"
524 and "Vol002", then sometime later all records of one or both those
525 Volumes were pruned or purged from the
526 database. By using {\bf bscan} you can recreate the catalog entries for
527 those Volumes and then use the {\bf restore} command in the Console to restore
528 whatever you want. A command something like:
532 bscan -c bacula-sd.conf -v -V Vol001\|Vol002 /dev/nst0
536 will give you an idea of what is going to happen without changing
537 your catalog. Of course, you may need to change the path to the Storage
538 daemon's conf file, the Volume name, and your tape (or disk) device name. This
539 command must read the entire tape, so if it has a lot of data, it may take a
540 long time, and thus you might want to immediately use the command listed
541 below. Note, if you are writing to a disk file, replace the device name with
542 the path to the directory that contains the Volumes. This must correspond to
543 the Archive Device in the conf file.
545 Then to actually write or store the records in the catalog, add the {\bf -s}
550 bscan -s -m -c bacula-sd.conf -v -V Vol001\|Vol002 /dev/nst0
554 When writing to the database, if bscan finds existing records, it will
555 generally either update them if something is wrong or leave them alone. Thus
556 if the Volumes you are scanning are all or partially in the catalog already, no
557 harm will be done to that existing data. Any missing data will simply be
560 If you have multiple tapes, you should scan them with:
564 bscan -s -m -c bacula-sd.conf -v -V Vol001\|Vol002\|Vol003 /dev/nst0
568 Since there is a limit on the command line length (511 bytes) accepted
569 by {\bf bscan}, if you have too many Volumes, you will need to manually
570 create a bootstrap file. See the \borgxrlink{Restoring Files with the Bootstrap File}{BootstrapChapter}{main}{chapter} of the \mainman{}, in particular the section
571 entitled \borgxrlinkdocument{Bootstrap for bscan}{bscanBootstrap}{main}{section}. Basically, the .bsr file for the above example might look like:
581 Note: {\bf bscan} does not support supplying Volume names on the
582 command line and at the same time in a bootstrap file. Please
583 use only one or the other.
585 You should, always try to specify the tapes in the order they are written.
586 If you do not, any Jobs that span a volume may not be fully or properly
587 restored. However, bscan can handle scanning tapes that are not sequential. Any
588 incomplete records at the end of the tape will simply be ignored in that
589 case. If you are simply repairing an existing catalog, this may be OK, but
590 if you are creating a new catalog from scratch, it will leave your database
591 in an incorrect state. If you do not specify all necessary Volumes on a
592 single bscan command, bscan will not be able to correctly restore the
593 records that span two volumes. In other words, it is much better to
594 specify two or three volumes on a single bscan command (or in a .bsr file)
595 rather than run bscan two or three times, each with a single volume.
597 Note, the restoration process using bscan is not identical to the original
598 creation of the catalog data. This is because certain data such as Client
599 records and other non-essential data such
600 as volume reads, volume mounts, etc is not stored on the Volume, and thus is
601 not restored by bscan. The results of bscanning are, however, perfectly valid,
602 and will permit restoration of any or all the files in the catalog using the
603 normal Bacula console commands. If you are starting with an empty catalog
604 and expecting bscan to reconstruct it, you may be a bit disappointed, but
605 at a minimum, you must ensure that your bacula-dir.conf file is the same
606 as what it previously was -- that is, it must contain all the appropriate
607 Client resources so that they will be recreated in your new database {\bf
608 before} running bscan. Normally when the Director starts, it will recreate
609 any missing Client records in the catalog. Another problem you will have
610 is that even if the Volumes (Media records) are recreated in the database,
611 they will not have their autochanger status and slots properly set. As a
612 result, you will need to repair that by using the {\bf update slots}
613 command. There may be other considerations as well. Rather than
614 bscanning, you should always attempt to recover you previous catalog
618 \subsection{Using bscan to Compare a Volume to an existing Catalog}
619 \index[general]{Catalog!Using bscan to Compare a Volume to an existing}
620 \index[general]{Using bscan to Compare a Volume to an existing Catalog}
622 If you wish to compare the contents of a Volume to an existing catalog without
623 changing the catalog, you can safely do so if and only if you do {\bf not}
624 specify either the {\bf -m} or the {\bf -s} options. However, at this time
625 (Bacula version 1.26), the comparison routines are not as good or as thorough
626 as they should be, so we don't particularly recommend this mode other than for
629 \subsection{Using bscan to Recreate a Catalog from a Volume}
630 \index[general]{Volume!Using bscan to Recreate a Catalog from a Volume}
631 \index[general]{Using bscan to Recreate a Catalog from a Volume}
633 This is the mode for which {\bf bscan} is most useful. You can either {\bf
634 bscan} into a freshly created catalog, or directly into your existing catalog
635 (after having made an ASCII copy as described above). Normally, you should
636 start with a freshly created catalog that contains no data.
638 Starting with a single Volume named {\bf TestVolume1}, you run a command such
643 ./bscan -V TestVolume1 -v -s -m -c bacula-sd.conf /dev/nst0
647 If there is more than one volume, simply append it to the first one separating
648 it with a vertical bar. You may need to precede the vertical bar with a
649 forward slash escape the shell -- e.g. {\bf
650 TestVolume1\textbackslash{}|TestVolume2}. The {\bf -v} option was added for
651 verbose output (this can be omitted if desired). The {\bf -s} option that
652 tells {\bf bscan} to store information in the database. The physical device
653 name {\bf /dev/nst0} is specified after all the options.
655 {\bf} For example, after having done a full backup of a directory, then two
656 incrementals, I reinitialized the SQLite database as described above, and
657 using the bootstrap.bsr file noted above, I entered the following command:
661 ./bscan -b bootstrap.bsr -v -s -c bacula-sd.conf /dev/nst0
665 which produced the following output:
669 bscan: bscan.c:182 Using Database: bacula, User: bacula
670 bscan: bscan.c:673 Created Pool record for Pool: Default
671 bscan: bscan.c:271 Pool type "Backup" is OK.
672 bscan: bscan.c:632 Created Media record for Volume: TestVolume1
673 bscan: bscan.c:298 Media type "DDS-4" is OK.
674 bscan: bscan.c:307 VOL_LABEL: OK for Volume: TestVolume1
675 bscan: bscan.c:693 Created Client record for Client: Rufus
676 bscan: bscan.c:769 Created new JobId=1 record for original JobId=2
677 bscan: bscan.c:717 Created FileSet record "Kerns Files"
678 bscan: bscan.c:819 Updated Job termination record for new JobId=1
679 bscan: bscan.c:905 Created JobMedia record JobId 1, MediaId 1
680 bscan: Got EOF on device /dev/nst0
681 bscan: bscan.c:693 Created Client record for Client: Rufus
682 bscan: bscan.c:769 Created new JobId=2 record for original JobId=3
683 bscan: bscan.c:708 Fileset "Kerns Files" already exists.
684 bscan: bscan.c:819 Updated Job termination record for new JobId=2
685 bscan: bscan.c:905 Created JobMedia record JobId 2, MediaId 1
686 bscan: Got EOF on device /dev/nst0
687 bscan: bscan.c:693 Created Client record for Client: Rufus
688 bscan: bscan.c:769 Created new JobId=3 record for original JobId=4
689 bscan: bscan.c:708 Fileset "Kerns Files" already exists.
690 bscan: bscan.c:819 Updated Job termination record for new JobId=3
691 bscan: bscan.c:905 Created JobMedia record JobId 3, MediaId 1
692 bscan: Got EOF on device /dev/nst0
693 bscan: bscan.c:652 Updated Media record at end of Volume: TestVolume1
694 bscan: bscan.c:428 End of Volume. VolFiles=3 VolBlocks=57 VolBytes=10,027,437
698 The key points to note are that {\bf bscan} prints a line when each major
699 record is created. Due to the volume of output, it does not print a line for
700 each file record unless you supply the {\bf -v} option twice or more on the
703 In the case of a Job record, the new JobId will not normally be the same as
704 the original Jobid. For example, for the first JobId above, the new JobId is
705 1, but the original JobId is 2. This is nothing to be concerned about as it is
706 the normal nature of databases. {\bf bscan} will keep everything straight.
708 Although {\bf bscan} claims that it created a Client record for Client: Rufus
709 three times, it was actually only created the first time. This is normal.
711 You will also notice that it read an end of file after each Job (Got EOF on
712 device ...). Finally the last line gives the total statistics for the bscan.
714 If you had added a second {\bf -v} option to the command line, Bacula would
715 have been even more verbose, dumping virtually all the details of each Job
716 record it encountered.
718 Now if you start Bacula and enter a {\bf list jobs} command to the console
719 program, you will get:
723 +-------+----------+------------------+------+-----+----------+----------+---------+
724 | JobId | Name | StartTime | Type | Lvl | JobFiles | JobBytes | JobStat |
725 +-------+----------+------------------+------+-----+----------+----------+---------+
726 | 1 | kernsave | 2002-10-07 14:59 | B | F | 84 | 4180207 | T |
727 | 2 | kernsave | 2002-10-07 15:00 | B | I | 15 | 2170314 | T |
728 | 3 | kernsave | 2002-10-07 15:01 | B | I | 33 | 3662184 | T |
729 +-------+----------+------------------+------+-----+----------+----------+---------+
733 which corresponds virtually identically with what the database contained
734 before it was re-initialized and restored with bscan. All the Jobs and Files
735 found on the tape are restored including most of the Media record. The Volume
736 (Media) records restored will be marked as {\bf Full} so that they cannot be
737 rewritten without operator intervention.
739 It should be noted that {\bf bscan} cannot restore a database to the exact
740 condition it was in previously because a lot of the less important information
741 contained in the database is not saved to the tape. Nevertheless, the
742 reconstruction is sufficiently complete, that you can run {\bf restore}
743 against it and get valid results.
745 An interesting aspect of restoring a catalog backup using {\bf bscan} is
746 that the backup was made while Bacula was running and writing to a tape. At
747 the point the backup of the catalog is made, the tape Bacula is writing to
748 will have say 10 files on it, but after the catalog backup is made, there
749 will be 11 files on the tape Bacula is writing. This there is a difference
750 between what is contained in the backed up catalog and what is actually on
751 the tape. If after restoring a catalog, you attempt to write on the same
752 tape that was used to backup the catalog, Bacula will detect the difference
753 in the number of files registered in the catalog compared to what is on the
754 tape, and will mark the tape in error.
756 There are two solutions to this problem. The first is possibly the simplest
757 and is to mark the volume as Used before doing any backups. The second is
758 to manually correct the number of files listed in the Media record of the
759 catalog. This procedure is documented elsewhere in the manual and involves
760 using the {\bf update volume} command in {\bf bconsole}.
762 \subsection{Using bscan to Correct the Volume File Count}
763 \index[general]{Using bscan to Correct the Volume File Count}
764 \index[general]{Count!Using bscan to Correct the Volume File Count}
766 If the Storage daemon crashes during a backup Job, the catalog will not be
767 properly updated for the Volume being used at the time of the crash. This
768 means that the Storage daemon will have written say 20 files on the tape, but
769 the catalog record for the Volume indicates only 19 files.
771 Bacula refuses to write on a tape that contains a different number of files
772 from what is in the catalog. To correct this situation, you may run a {\bf
773 bscan} with the {\bf -m} option (but {\bf without} the {\bf -s} option) to
774 update only the final Media record for the Volumes read.
776 \subsection{After bscan}
777 \index[general]{After bscan}
778 \index[general]{Bscan!After}
780 If you use {\bf bscan} to enter the contents of the Volume into an existing
781 catalog, you should be aware that the records you entered may be immediately
782 pruned during the next job, particularly if the Volume is very old or had been
783 previously purged. To avoid this, after running {\bf bscan}, you can manually
784 set the volume status (VolStatus) to {\bf Read-Only} by using the {\bf update}
785 command in the catalog. This will allow you to restore from the volume without
786 having it immediately purged. When you have restored and backed up the data,
787 you can reset the VolStatus to {\bf Used} and the Volume will be purged from
792 \index[general]{Bcopy}
793 \index[general]{program!bcopy}
795 The {\bf bcopy} program can be used to copy one {\bf Bacula} archive file to
796 another. For example, you may copy a tape to a file, a file to a tape, a file
797 to a file, or a tape to a tape. For tape to tape, you will need two tape
798 drives. (a later version is planned that will buffer it to disk). In the
799 process of making the copy, no record of the information written to the new
800 Volume is stored in the catalog. This means that the new Volume, though it
801 contains valid backup data, cannot be accessed directly from existing catalog
802 entries. If you wish to be able to use the Volume with the Console restore
803 command, for example, you must first bscan the new Volume into the catalog.
805 \subsection{bcopy Command Options}
806 \index[general]{Options!bcopy Command}
807 \index[general]{Bcopy Command Options}
811 Usage: bcopy [-d debug_level] <input-archive> <output-archive>
812 -b bootstrap specify a bootstrap file
813 -c <file> specify configuration file
814 -dnn set debug level to nn
815 -i specify input Volume names (separated by |)
816 -o specify output Volume names (separated by |)
817 -p proceed inspite of I/O errors
819 -w dir specify working directory (default /tmp)
820 -? print this message
824 By using a {\bf bootstrap} file, you can copy parts of a Bacula archive file
827 One of the objectives of this program is to be able to recover as much data as
828 possible from a damaged tape. However, the current version does not yet have
831 As this is a new program, any feedback on its use would be appreciated. In
832 addition, I only have a single tape drive, so I have never been able to test
833 this program with two tape drives.
837 \index[general]{Btape}
838 \index[general]{program!btape}
840 This program permits a number of elementary tape operations via a tty command
841 interface. It works only with tapes and not with other kinds of Bacula
842 storage media (DVD, File, ...). The {\bf test} command, described below,
843 can be very useful for testing older tape drive compatibility problems.
844 Aside from initial testing of tape drive compatibility with {\bf Bacula},
845 {\bf btape} will be mostly used by developers writing new tape drivers.
847 {\bf btape} can be dangerous to use with existing {\bf Bacula} tapes because
848 it will relabel a tape or write on the tape if so requested regardless that
849 the tape may contain valuable data, so please be careful and use it only on
852 To work properly, {\bf btape} needs to read the Storage daemon's configuration
853 file. As a default, it will look for {\bf bacula-sd.conf} in the current
854 directory. If your configuration file is elsewhere, please use the {\bf -c}
855 option to specify where.
857 The physical device name must be specified on the command line, and this
858 same device name must be present in the Storage daemon's configuration file
863 Usage: btape <options> <device_name>
864 -b <file> specify bootstrap file
865 -c <file> set configuration file to file
866 -d <nn> set debug level to nn
867 -p proceed inspite of I/O errors
870 -? print this message.
874 \subsection{Using btape to Verify your Tape Drive}
875 \index[general]{Using btape to Verify your Tape Drive}
876 \index[general]{Drive!Using btape to Verify your Tape}
878 An important reason for this program is to ensure that a Storage daemon
879 configuration file is defined so that Bacula will correctly read and write
882 It is highly recommended that you run the {\bf test} command before running
883 your first Bacula job to ensure that the parameters you have defined for your
884 storage device (tape drive) will permit {\bf Bacula} to function properly. You
885 only need to mount a blank tape, enter the command, and the output should be
886 reasonably self explanatory. Please see the
887 \borgxrlink{Tape Testing}{TapeTestingChapter}{problems}{chapter} of the \problemsman{} for
890 \subsection{btape Commands}
891 \index[general]{Btape Commands}
892 \index[general]{Commands!btape}
894 The full list of commands are:
900 autochanger test autochanger
903 cap list device capabilities
904 clear clear tape errors
905 eod go to end of Bacula data for append
906 eom go to the physical end of medium
907 fill fill tape, write onto second volume
908 unfill read filled tape
909 fsf forward space a file
910 fsr forward space a record
911 help print this command
912 label write a Bacula label to the tape
915 rawfill use write() to fill tape
916 readlabel read and print the Bacula tape label
917 rectest test record handling functions
918 rewind rewind the tape
919 scan read() tape block by block to EOT and report
920 scanblocks Bacula read block by block to EOT and report
921 speed report drive speed
922 status print tape status
923 test General test Bacula tape functions
924 weof write an EOF on the tape
925 wr write a single Bacula block
926 rr read a single record
927 qfill quick fill command
931 The most useful commands are:
934 \item test -- test writing records and EOF marks and reading them back.
935 \item fill -- completely fill a volume with records, then write a few records
936 on a second volume, and finally, both volumes will be read back.
937 This command writes blocks containing random data, so your drive will
938 not be able to compress the data, and thus it is a good test of
939 the real physical capacity of your tapes.
940 \item readlabel -- read and dump the label on a Bacula tape.
941 \item cap -- list the device capabilities as defined in the configuration
942 file and as perceived by the Storage daemon.
945 The {\bf readlabel} command can be used to display the details of a Bacula
946 tape label. This can be useful if the physical tape label was lost or damaged.
949 In the event that you want to relabel a {\bf Bacula}, you can simply use the
950 {\bf label} command which will write over any existing label. However, please
951 note for labeling tapes, we recommend that you use the {\bf label} command in
952 the {\bf Console} program since it will never overwrite a valid Bacula tape.
954 \subsubsection*{Testing your Tape Drive}
955 \label{sec:btapespeed}
957 To determine the best configuration of your tape drive, you can run the new
958 \texttt{speed} command available in the \texttt{btape} program.
960 This command can have the following arguments:
962 \item[\texttt{file\_size=n}] Specify the Maximum File Size for this test
963 (between 1 and 5GB). This counter is in GB.
964 \item[\texttt{nb\_file=n}] Specify the number of file to be written. The amount
965 of data should be greater than your memory ($file\_size*nb\_file$).
966 \item[\texttt{skip\_zero}] This flag permits to skip tests with constant
968 \item[\texttt{skip\_random}] This flag permits to skip tests with random
970 \item[\texttt{skip\_raw}] This flag permits to skip tests with raw access.
971 \item[\texttt{skip\_block}] This flag permits to skip tests with Bacula block
976 *speed file_size=3 skip_raw
977 btape.c:1078 Test with zero data and bacula block structure.
978 btape.c:956 Begin writing 3 files of 3.221 GB with blocks of 129024 bytes.
979 ++++++++++++++++++++++++++++++++++++++++++
980 btape.c:604 Wrote 1 EOF to "Drive-0" (/dev/nst0)
981 btape.c:406 Volume bytes=3.221 GB. Write rate = 44.128 MB/s
983 btape.c:383 Total Volume bytes=9.664 GB. Total Write rate = 43.531 MB/s
985 btape.c:1090 Test with random data, should give the minimum throughput.
986 btape.c:956 Begin writing 3 files of 3.221 GB with blocks of 129024 bytes.
987 +++++++++++++++++++++++++++++++++++++++++++
988 btape.c:604 Wrote 1 EOF to "Drive-0" (/dev/nst0)
989 btape.c:406 Volume bytes=3.221 GB. Write rate = 7.271 MB/s
990 +++++++++++++++++++++++++++++++++++++++++++
992 btape.c:383 Total Volume bytes=9.664 GB. Total Write rate = 7.365 MB/s
996 When using compression, the random test will give your the minimum throughput
997 of your drive . The test using constant string will give you the maximum speed
998 of your hardware chain. (cpu, memory, scsi card, cable, drive, tape).
1000 You can change the block size in the Storage Daemon configuration file.
1002 \section{Other Programs}
1003 \index[general]{Programs!Other}
1004 \index[general]{Other Programs}
1006 The following programs are general utility programs and in general do not need
1007 a configuration file nor a device name.
1011 \index[general]{Bsmtp}
1012 \index[general]{program!bsmtp}
1014 {\bf bsmtp} is a simple mail transport program that permits more flexibility
1015 than the standard mail programs typically found on Unix systems. It can even
1016 be used on Windows machines.
1022 Usage: bsmtp [-f from] [-h mailhost] [-s subject] [-c copy] [recipient ...]
1023 -c set the Cc: field
1024 -dnn set debug level to nn
1025 -f set the From: field
1026 -h use mailhost:port as the bsmtp server
1027 -l limit the lines accepted to nn
1028 -s set the Subject: field
1029 -? print this message.
1033 If the {\bf -f} option is not specified, {\bf bsmtp} will use your userid. If
1034 the option {\bf -h} is not specified {\bf bsmtp} will use the value in the environment
1035 variable {\bf bsmtpSERVER} or if there is none {\bf localhost}. By default
1038 If a line count limit is set with the {\bf -l} option, {\bf bsmtp} will
1039 not send an email with a body text exceeding that number of lines. This
1040 is especially useful for large restore job reports where the list of
1041 files restored might produce very long mails your mail-server would
1042 refuse or crash. However, be aware that you will probably suppress the
1043 job report and any error messages unless you check the log file written
1044 by the Director (see the messages resource in this manual for details).
1047 {\bf recipients} is a space separated list of email recipients.
1049 The body of the email message is read from standard input.
1051 An example of the use of {\bf bsmtp} would be to put the following statement
1052 in the {\bf Messages} resource of your {\bf bacula-dir.conf} file. Note, these
1053 commands should appear on a single line each.
1057 mailcommand = "/home/bacula/bin/bsmtp -h mail.domain.com -f \"\(Bacula\) %r\"
1058 -s \"Bacula: %t %e of %c %l\" %r"
1059 operatorcommand = "/home/bacula/bin/bsmtp -h mail.domain.com -f \"\(Bacula\) %r\"
1060 -s \"Bacula: Intervention needed for %j\" %r"
1064 Where you replace {\bf /home/bacula/bin} with the path to your {\bf Bacula}
1065 binary directory, and you replace {\bf mail.domain.com} with the fully
1066 qualified name of your bsmtp (email) server, which normally listens on port
1067 25. For more details on the substitution characters (e.g. \%r) used in the
1068 above line, please see the documentation of the \borgxrlink{Mail Command in
1069 the Messages Resource}{mailcommand}{main}{chapter} of the \mainman{}.
1071 It is HIGHLY recommended that you test one or two cases by hand to make sure
1072 that the {\bf mailhost} that you specified is correct and that it will accept
1073 your email requests. Since {\bf bsmtp} always uses a TCP connection rather
1074 than writing in the spool file, you may find that your {\bf from} address is
1075 being rejected because it does not contain a valid domain, or because your
1076 message is caught in your spam filtering rules. Generally, you should specify
1077 a fully qualified domain name in the {\bf from} field, and depending on
1078 whether your bsmtp gateway is Exim or Sendmail, you may need to modify the
1079 syntax of the from part of the message. Please test.
1081 When running {\bf bsmtp} by hand, you will need to terminate the message by
1082 entering a ctl-d in column 1 of the last line.
1083 % TODO: is "column" the correct terminology for this?
1085 If you are getting incorrect dates (e.g. 1970) and you are
1086 running with a non-English language setting, you might try adding
1087 a LANG=''en\_US'' immediately before the bsmtp call.
1089 In general, {\bf bsmtp} attempts to cleanup email addresses that you
1090 specify in the from, copy, mailhost, and recipient fields, by adding
1091 the necessary \lt{} and \gt{} characters around the address part. However,
1092 if you include a {\bf display-name} (see RFC 5332), some SMTP servers
1093 such as Exchange may not accept the message if the {\bf display-name} is
1094 also included in \lt{} and \gt{}. As mentioned above, you must test, and
1095 if you run into this situation, you may manually add the \lt{} and \gt{}
1096 to the Bacula {\bf mailcommand} or {\bf operatorcommand} and when
1097 {\bf bsmtp} is formatting an address if it already contains a \lt{} or
1098 \gt{} character, it will leave the address unchanged.
1102 \index[general]{Dbcheck}
1103 \index[general]{program!dbcheck}
1104 {\bf dbcheck} is a simple program that will search for logical
1105 inconsistencies in the Bacula tables in your database, and optionally fix them.
1106 It is a database maintenance routine, in the sense that it can
1107 detect and remove unused rows, but it is not a database repair
1108 routine. To repair a database, see the tools furnished by the
1109 database vendor. Normally dbcheck should never need to be run,
1110 but if Bacula has crashed or you have a lot of Clients, Pools, or
1111 Jobs that you have removed, it could be useful.
1113 The {\bf dbcheck} program can be found in
1114 the {\bf \lt{}bacula-source\gt{}/src/tools} directory of the source
1115 distribution. Though it is built with the make process, it is not normally
1122 Usage: dbcheck [-c config ] [-B] [-C catalog name] [-d debug_level]
1123 <working-directory> <bacula-database> <user> <password> [<dbhost>] [<dbport>]
1125 -C catalog name in the director conf file
1126 -c Director conf filename
1127 -B print catalog configuration and exit
1128 -d <nn> set debug level to <nn>
1129 -dt print timestamp in debug output
1130 -f fix inconsistencies
1132 -? print this message
1136 If the \textbf{-B} option is specified, dbcheck will print out catalog
1137 information in a simple text based format. This is useful to backup it in a
1153 If the {\bf -c} option is given with the Director's conf file, there is no
1154 need to enter any of the command line arguments, in particular the working
1155 directory as dbcheck will read them from the file.
1157 If the {\bf -f} option is specified, {\bf dbcheck} will repair ({\bf fix}) the
1158 inconsistencies it finds. Otherwise, it will report only.
1160 If the {\bf -b} option is specified, {\bf dbcheck} will run in batch mode, and
1161 it will proceed to examine and fix (if -f is set) all programmed inconsistency
1162 checks. If the {\bf -b} option is not specified, {\bf dbcheck} will enter
1163 interactive mode and prompt with the following:
1167 Hello, this is the database check/correct program.
1168 Please select the function you want to perform.
1169 1) Toggle modify database flag
1170 2) Toggle verbose flag
1171 3) Repair bad Filename records
1172 4) Repair bad Path records
1173 5) Eliminate duplicate Filename records
1174 6) Eliminate duplicate Path records
1175 7) Eliminate orphaned Jobmedia records
1176 8) Eliminate orphaned File records
1177 9) Eliminate orphaned Path records
1178 10) Eliminate orphaned Filename records
1179 11) Eliminate orphaned FileSet records
1180 12) Eliminate orphaned Client records
1181 13) Eliminate orphaned Job records
1182 14) Eliminate all Admin records
1183 15) Eliminate all Restore records
1186 Select function number:
1190 By entering 1 or 2, you can toggle the modify database flag (-f option) and
1191 the verbose flag (-v). It can be helpful and reassuring to turn off the modify
1192 database flag, then select one or more of the consistency checks (items 3
1193 through 9) to see what will be done, then toggle the modify flag on and re-run
1196 The inconsistencies examined are the following:
1199 \item Duplicate filename records. This can happen if you accidentally run two
1200 copies of Bacula at the same time, and they are both adding filenames
1201 simultaneously. It is a rare occurrence, but will create an inconsistent
1202 database. If this is the case, you will receive error messages during Jobs
1203 warning of duplicate database records. If you are not getting these error
1204 messages, there is no reason to run this check.
1205 \item Repair bad Filename records. This checks and corrects filenames that
1206 have a trailing slash. They should not.
1207 \item Repair bad Path records. This checks and corrects path names that do
1208 not have a trailing slash. They should.
1209 \item Duplicate path records. This can happen if you accidentally run two
1210 copies of Bacula at the same time, and they are both adding filenames
1211 simultaneously. It is a rare occurrence, but will create an inconsistent
1212 database. See the item above for why this occurs and how you know it is
1214 \item Orphaned JobMedia records. This happens when a Job record is deleted
1215 (perhaps by a user issued SQL statement), but the corresponding JobMedia
1216 record (one for each Volume used in the Job) was not deleted. Normally, this
1217 should not happen, and even if it does, these records generally do not take
1218 much space in your database. However, by running this check, you can
1219 eliminate any such orphans.
1220 \item Orphaned File records. This happens when a Job record is deleted
1221 (perhaps by a user issued SQL statement), but the corresponding File record
1222 (one for each Volume used in the Job) was not deleted. Note, searching for
1223 these records can be {\bf very} time consuming (i.e. it may take hours) for a
1224 large database. Normally this should not happen as Bacula takes care to
1225 prevent it. Just the same, this check can remove any orphaned File records.
1226 It is recommended that you run this once a year since orphaned File records
1227 can take a large amount of space in your database. You might
1228 want to ensure that you have indexes on JobId, FilenameId, and
1229 PathId for the File table in your catalog before running this
1231 \item Orphaned Path records. This condition happens any time a directory is
1232 deleted from your system and all associated Job records have been purged.
1233 During standard purging (or pruning) of Job records, Bacula does not check
1234 for orphaned Path records. As a consequence, over a period of time, old
1235 unused Path records will tend to accumulate and use space in your database.
1236 This check will eliminate them. It is recommended that you run this
1237 check at least once a year.
1238 \item Orphaned Filename records. This condition happens any time a file is
1239 deleted from your system and all associated Job records have been purged.
1240 This can happen quite frequently as there are quite a large number of files
1241 that are created and then deleted. In addition, if you do a system update or
1242 delete an entire directory, there can be a very large number of Filename
1243 records that remain in the catalog but are no longer used.
1245 During standard purging (or pruning) of Job records, Bacula does not check
1246 for orphaned Filename records. As a consequence, over a period of time, old
1247 unused Filename records will accumulate and use space in your database. This
1248 check will eliminate them. It is strongly recommended that you run this check
1249 at least once a year, and for large database (more than 200 Megabytes), it is
1250 probably better to run this once every 6 months.
1251 \item Orphaned Client records. These records can remain in the database long
1252 after you have removed a client.
1253 \item Orphaned Job records. If no client is defined for a job or you do not
1254 run a job for a long time, you can accumulate old job records. This option
1255 allow you to remove jobs that are not attached to any client (and thus
1257 \item All Admin records. This command will remove all Admin records,
1258 regardless of their age.
1259 \item All Restore records. This command will remove all Restore records,
1260 regardless of their age.
1264 If you are using Mysql, dbcheck will ask you if you want to create temporary
1265 indexes to speed up orphaned Path and Filename elimination.
1267 Mostly for PostgreSQL users, we provide a pure SQL script dbcheck replacement
1268 in \url{examples/database/dbcheck.sql} that works with global queries instead
1269 of many small queries like dbcheck. Execution instructions are at the top of
1270 the script and you will need to type \texttt{COMMIT} at the end to validate
1273 If you are using bweb or brestore, don't eliminate orphaned Path, else you will
1274 have to rebuild \texttt{brestore\_pathvisibility} and
1275 \texttt{brestore\_pathhierarchy} indexes.
1277 By the way, I personally run dbcheck only where I have messed up
1278 my database due to a bug in developing Bacula code, so normally
1279 you should never need to run dbcheck in spite of the
1280 recommendations given above, which are given so that users don't
1281 waste their time running dbcheck too often.
1285 \index[general]{bregex}
1286 \index[general]{program!bregex}
1288 {\bf bregex} is a simple program that will allow you to test
1289 regular expressions against a file of data. This can be useful
1290 because the regex libraries on most systems differ, and in
1291 addition, regex expressions can be complicated.
1293 {\bf bregex} is found in the src/tools directory and it is
1294 normally installed with your system binaries. To run it, use:
1297 Usage: bregex [-d debug_level] -f <data-file>
1298 -f specify file of data to be matched
1299 -l suppress line numbers
1300 -n print lines that do not match
1301 -? print this message.
1304 The \lt{}data-file\gt{} is a filename that contains lines
1305 of data to be matched (or not) against one or more patterns.
1306 When the program is run, it will prompt you for a regular
1307 expression pattern, then apply it one line at a time against
1308 the data in the file. Each line that matches will be printed
1309 preceded by its line number. You will then be prompted again
1310 for another pattern.
1312 Enter an empty line for a pattern to terminate the program. You
1313 can print only lines that do not match by using the -n option,
1314 and you can suppress printing of line numbers with the -l option.
1316 This program can be useful for testing regex expressions to be
1317 applied against a list of filenames.
1321 \index[general]{bwild}
1322 \index[general]{program!bwild}
1324 {\bf bwild} is a simple program that will allow you to test
1325 wild-card expressions against a file of data.
1327 {\bf bwild} is found in the src/tools directory and it is
1328 normally installed with your system binaries. To run it, use:
1331 Usage: bwild [-d debug_level] -f <data-file>
1332 -f specify file of data to be matched
1333 -l suppress line numbers
1334 -n print lines that do not match
1335 -? print this message.
1338 The \lt{}data-file\gt{} is a filename that contains lines
1339 of data to be matched (or not) against one or more patterns.
1340 When the program is run, it will prompt you for a wild-card
1341 pattern, then apply it one line at a time against
1342 the data in the file. Each line that matches will be printed
1343 preceded by its line number. You will then be prompted again
1344 for another pattern.
1346 Enter an empty line for a pattern to terminate the program. You
1347 can print only lines that do not match by using the -n option,
1348 and you can suppress printing of line numbers with the -l option.
1350 This program can be useful for testing wild expressions to be
1351 applied against a list of filenames.
1355 \index[general]{Testfind}
1356 \index[general]{program!testfind}
1358 {\bf testfind} permits listing of files using the same search engine that is
1359 used for the {\bf Include} resource in Job resources. Note, much of the
1360 functionality of this program (listing of files to be included) is present in
1362 \borgxrlink{estimate}{estimate}{console}{command} in the \consoleman{}.
1364 The original use of testfind was to ensure that Bacula's file search engine
1365 was correct and to print some statistics on file name and path length.
1366 However, you may find it useful to see what bacula would do with a given {\bf
1367 Include} resource. The {\bf testfind} program can be found in the {\bf
1368 \lt{}bacula-source\gt{}/src/tools} directory of the source distribution.
1369 Though it is built with the make process, it is not normally "installed".
1375 Usage: testfind [-d debug_level] [-] [pattern1 ...]
1376 -a print extended attributes (Win32 debug)
1377 -dnn set debug level to nn
1378 - read pattern(s) from stdin
1379 -? print this message.
1380 Patterns are used for file inclusion -- normally directories.
1381 Debug level>= 1 prints each file found.
1382 Debug level>= 10 prints path/file for catalog.
1383 Errors are always printed.
1384 Files/paths truncated is a number with len> 255.
1385 Truncation is only in the catalog.
1389 Where a pattern is any filename specification that is valid within an {\bf
1390 Include} resource definition. If none is specified, {\bf /} (the root
1391 directory) is assumed. For example:
1399 Would print the following:
1405 Lnk: /bin/bash2 -> bash
1406 Lnk: /bin/sh -> bash
1414 Reg: /bin/aumix-minimal
1416 Lnka: /bin/gawk-3.1.0 -> /bin/gawk
1426 Even though {\bf testfind} uses the same search engine as {\bf Bacula}, each
1427 directory to be listed, must be entered as a separate command line entry or
1428 entered one line at a time to standard input if the {\bf -} option was
1431 Specifying a debug level of one (i.e. {\bf -d1}) on the command line will
1432 cause {\bf testfind} to print the raw filenames without showing the Bacula
1433 internal file type, or the link (if any). Debug levels of 10 or greater cause
1434 the filename and the path to be separated using the same algorithm that is
1435 used when putting filenames into the Catalog database.