4 \section*{Volume Utility Tools}
6 \index[general]{Volume Utility Tools }
7 \index[general]{Tools!Volume Utility }
8 \addcontentsline{toc}{section}{Volume Utility Tools}
10 This document describes the utility programs written to aid Bacula users and
11 developers in dealing with Volumes external to Bacula.
13 \subsection*{Specifying the Configuration File}
14 \index[general]{Specifying the Configuration File }
15 \addcontentsline{toc}{subsection}{Specifying the Configuration File}
17 Starting with version 1.27, each of the following programs requires a valid
18 Storage daemon configuration file (actually, the only part of the
19 configuration file that these programs need is the {\bf Device} resource
20 definitions). This permits the programs to find the configuration parameters
21 for your archive device (generally a tape drive). By default, they read {\bf
22 bacula-sd.conf} in the current directory, but you may specify a different
23 configuration file using the {\bf -c} option.
26 \subsection*{Specifying a Device Name For a Tape}
27 \index[general]{Tape!Specifying a Device Name For a }
28 \index[general]{Specifying a Device Name For a Tape }
29 \addcontentsline{toc}{subsection}{Specifying a Device Name For a Tape}
31 Each of these programs require a {\bf device-name} where the Volume can be
32 found. In the case of a tape, this is the physical device name such as {\bf
33 /dev/nst0} or {\bf /dev/rmt/0ubn} depending on your system. For the program to
34 work, it must find the identical name in the Device resource of the
35 configuration file. See below for specifying Volume names.
37 Please note that if you have Bacula running and you ant to use
38 one of these programs, you will either need to stop the Storage daemon, or
39 {\bf unmount} any tape drive you want to use, otherwise the drive
40 will {\bf busy} because Bacula is using it.
43 \subsection*{Specifying a Device Name For a File}
44 \index[general]{File!Specifying a Device Name For a }
45 \index[general]{Specifying a Device Name For a File }
46 \addcontentsline{toc}{subsection}{Specifying a Device Name For a File}
48 If you are attempting to read or write an archive file rather than a tape, the
49 {\bf device-name} should be the full path to the archive location including
50 the filename. The filename (last part of the specification) will be stripped
51 and used as the Volume name, and the path (first part before the filename)
52 must have the same entry in the configuration file. So, the path is equivalent
53 to the archive device name, and the filename is equivalent to the volume name.
56 \subsection*{Specifying Volumes}
57 \index[general]{Volumes!Specifying }
58 \index[general]{Specifying Volumes }
59 \addcontentsline{toc}{subsection}{Specifying Volumes}
61 In general, you must specify the Volume name to each of the programs below
62 (with the exception of {\bf btape}). The best method to do so is to specify a
63 {\bf bootstrap} file on the command line with the {\bf -b} option. As part of
64 the bootstrap file, you will then specify the Volume name or Volume names if
65 more than one volume is needed. For example, suppose you want to read tapes
66 {\bf tape1} and {\bf tape2}. First construct a {\bf bootstrap} file named say,
67 {\bf list.bsr} which contains:
75 where each Volume is separated by a vertical bar. Then simply use:
79 ./bls -b list.bsr /dev/nst0
83 In the case of Bacula Volumes that are on files, you may simply append volumes
88 ./bls /tmp/test1\|test2
92 where the backslash (\textbackslash{}) was necessary as a shell escape to
93 permit entering the vertical bar (|).
95 And finally, if you feel that specifying a Volume name is a bit complicated
96 with a bootstrap file, you can use the {\bf -V} option (on all programs except
97 {\bf bcopy}) to specify one or more Volume names separated by the vertical bar
102 ./bls -V Vol001 /dev/nst0
106 You may also specify an asterisk (*) to indicate that the program should
107 accept any volume. For example:
117 \index[general]{bls }
118 \addcontentsline{toc}{subsection}{bls}
120 {\bf bls} can be used to do an {\bf ls} type listing of a {\bf Bacula} tape or
125 Usage: bls [options] <device-name>
126 -b <file> specify a bootstrap file
127 -c <file> specify a config file
128 -d <level> specify debug level
129 -e <file> exclude list
130 -i <file> include list
133 (no j or k option) list saved files
135 -p proceed inspite of errors
137 -V specify Volume names (separated by |)
138 -? print this message
142 For example, to list the contents of a tape:
146 ./bls -V Volume-name /dev/nst0
150 Or to list the contents of a file:
154 ./bls /tmp/Volume-name
156 ./bls -V Volume-name /tmp
160 Note that, in the case of a file, the Volume name becomes the filename, so in
161 the above example, you will replace the {\bf xxx} with the name of the volume
164 Normally if no options are specified, {\bf bls} will produce the equivalent
165 output to the {\bf ls -l} command for each file on the tape. Using other
166 options listed above, it is possible to display only the Job records, only the
167 tape blocks, etc. For example:
173 bls: butil.c:148 Using device: /tmp
174 drwxrwxr-x 3 k k 4096 02-10-19 21:08 /home/kern/bacula/k/src/dird/
175 drwxrwxr-x 2 k k 4096 02-10-10 18:59 /home/kern/bacula/k/src/dird/CVS/
176 -rw-rw-r-- 1 k k 54 02-07-06 18:02 /home/kern/bacula/k/src/dird/CVS/Root
177 -rw-rw-r-- 1 k k 16 02-07-06 18:02 /home/kern/bacula/k/src/dird/CVS/Repository
178 -rw-rw-r-- 1 k k 1783 02-10-10 18:59 /home/kern/bacula/k/src/dird/CVS/Entries
179 -rw-rw-r-- 1 k k 97506 02-10-18 21:07 /home/kern/bacula/k/src/dird/Makefile
180 -rw-r--r-- 1 k k 3513 02-10-18 21:02 /home/kern/bacula/k/src/dird/Makefile.in
181 -rw-rw-r-- 1 k k 4669 02-07-06 18:02 /home/kern/bacula/k/src/dird/README-config
182 -rw-r--r-- 1 k k 4391 02-09-14 16:51 /home/kern/bacula/k/src/dird/authenticate.c
183 -rw-r--r-- 1 k k 3609 02-07-07 16:41 /home/kern/bacula/k/src/dird/autoprune.c
184 -rw-rw-r-- 1 k k 4418 02-10-18 21:03 /home/kern/bacula/k/src/dird/bacula-dir.conf
186 -rw-rw-r-- 1 k k 83 02-08-31 19:19 /home/kern/bacula/k/src/dird/.cvsignore
187 bls: Got EOF on device /tmp
192 \subsubsection*{Listing Jobs}
193 \index[general]{Listing Jobs with bls }
194 \index[general]{bls!Listing Jobs }
195 \addcontentsline{toc}{subsubsection}{bls Listing Jobs}
197 If you are listing a Volume to determine what Jobs to restore, normally the
198 {\bf -j} option provides you with most of what you will need as long as you
199 don't have multiple clients. For example,
203 ./bls -j -V Test1 -c stored.conf DDS-4
204 bls: butil.c:258 Using device: "DDS-4" for reading.
205 11-Jul 11:54 bls: Ready to read from volume "Test1" on device "DDS-4" (/dev/nst0).
206 Volume Record: File:blk=0:1 SessId=4 SessTime=1121074625 JobId=0 DataLen=165
207 Begin Job Session Record: File:blk=0:2 SessId=4 SessTime=1121074625 JobId=1 Level=F Type=B
208 Begin Job Session Record: File:blk=0:3 SessId=5 SessTime=1121074625 JobId=5 Level=F Type=B
209 Begin Job Session Record: File:blk=0:6 SessId=3 SessTime=1121074625 JobId=2 Level=F Type=B
210 Begin Job Session Record: File:blk=0:13 SessId=2 SessTime=1121074625 JobId=4 Level=F Type=B
211 End Job Session Record: File:blk=0:99 SessId=3 SessTime=1121074625 JobId=2 Level=F Type=B
212 Files=168 Bytes=1,732,978 Errors=0 Status=T
213 End Job Session Record: File:blk=0:101 SessId=2 SessTime=1121074625 JobId=4 Level=F Type=B
214 Files=168 Bytes=1,732,978 Errors=0 Status=T
215 End Job Session Record: File:blk=0:108 SessId=5 SessTime=1121074625 JobId=5 Level=F Type=B
216 Files=168 Bytes=1,732,978 Errors=0 Status=T
217 End Job Session Record: File:blk=0:109 SessId=4 SessTime=1121074625 JobId=1 Level=F Type=B
218 Files=168 Bytes=1,732,978 Errors=0 Status=T
219 11-Jul 11:54 bls: End of Volume at file 1 on device "DDS-4" (/dev/nst0), Volume "Test1"
220 11-Jul 11:54 bls: End of all volumes.
224 shows a full save followed by two incremental saves.
226 Adding the {\bf -v} option will display virtually all information that is
227 available for each record:
229 \subsubsection*{Listing Blocks}
230 \index[general]{Listing Blocks with bls }
231 \index[general]{bls!Listing Blocks }
232 \addcontentsline{toc}{subsubsection}{bls Listing Blocks}
234 Normally, except for debugging purposes, you will not need to list Bacula
235 blocks (the "primitive" unit of Bacula data on the Volume). However, you can
240 ./bls -k /tmp/File002
241 bls: butil.c:148 Using device: /tmp
247 bls: Got EOF on device /tmp
248 End of File on device
252 By adding the {\bf -v} option, you can get more information, which can be
253 useful in knowing what sessions were written to the volume:
257 ./bls -k -v /tmp/File002
259 Id : Bacula 0.9 mortal
264 LabelType : VOL_LABEL
270 Date label written: 2002-10-19 at 21:16
271 Block: 1 blen=64512 First rec FI=VOL_LABEL SessId=1 SessTim=1035062102 Strm=0 rlen=147
272 Block: 2 blen=64512 First rec FI=6 SessId=1 SessTim=1035062102 Strm=DATA rlen=4087
273 Block: 3 blen=64512 First rec FI=12 SessId=1 SessTim=1035062102 Strm=DATA rlen=5902
274 Block: 4 blen=64512 First rec FI=19 SessId=1 SessTim=1035062102 Strm=DATA rlen=28382
276 Block: 65 blen=64512 First rec FI=83 SessId=1 SessTim=1035062102 Strm=DATA rlen=1873
277 Block: 66 blen=19195 First rec FI=83 SessId=1 SessTim=1035062102 Strm=DATA rlen=2973
278 bls: Got EOF on device /tmp
279 End of File on device
283 Armed with the SessionId and the SessionTime, you can extract just about
286 If you want to know even more, add a second {\bf -v} to the command line to
287 get a dump of every record in every block.
291 ./bls -k -v -v /tmp/File002
292 bls: block.c:79 Dump block 80f8ad0: size=64512 BlkNum=1
293 Hdrcksum=b1bdfd6d cksum=b1bdfd6d
294 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=VOL_LABEL Strm=0 len=147 p=80f8b40
295 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=SOS_LABEL Strm=-7 len=122 p=80f8be7
296 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=1 Strm=UATTR len=86 p=80f8c75
297 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=2 Strm=UATTR len=90 p=80f8cdf
298 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=3 Strm=UATTR len=92 p=80f8d4d
299 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=3 Strm=DATA len=54 p=80f8dbd
300 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=3 Strm=MD5 len=16 p=80f8e07
301 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=4 Strm=UATTR len=98 p=80f8e2b
302 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=4 Strm=DATA len=16 p=80f8ea1
303 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=4 Strm=MD5 len=16 p=80f8ec5
304 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=5 Strm=UATTR len=96 p=80f8ee9
305 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=5 Strm=DATA len=1783 p=80f8f5d
306 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=5 Strm=MD5 len=16 p=80f9668
307 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=UATTR len=95 p=80f968c
308 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=DATA len=32768 p=80f96ff
309 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=DATA len=32768 p=8101713
310 bls: block.c:79 Dump block 80f8ad0: size=64512 BlkNum=2
311 Hdrcksum=9acc1e7f cksum=9acc1e7f
312 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=contDATA len=4087 p=80f8b40
313 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=DATA len=31970 p=80f9b4b
314 bls: block.c:92 Rec: VId=1 VT=1035062102 FI=6 Strm=MD5 len=16 p=8101841
319 \subsection*{bextract}
321 \index[general]{Bextract }
322 \addcontentsline{toc}{subsection}{bextract}
324 Normally, you will restore files by running a {\bf Restore} Job from the {\bf
325 Console} program. However, {\bf bextract} can be used to extract a single file
326 or a list of files from a Bacula tape or file. In fact, {\bf bextract} can be
327 a useful tool to restore files to an empty system assuming you are able to
328 boot, you have statically linked {\bf bextract} and you have an appropriate
329 {\bf bootstrap} file.
336 Usage: bextract [-d debug_level] <device-name> <directory-to-store-files>
337 -b <file> specify a bootstrap file
338 -dnn set debug level to nn
339 -e <file> exclude list
340 -i <file> include list
341 -p proceed inspite of I/O errors
342 -V specify Volume names (separated by |)
343 -? print this message
347 where {\bf device-name} is the Archive Device (raw device name or full
348 filename) of the device to be read, and {\bf directory-to-store-files} is a
349 path prefix to prepend to all the files restored.
351 NOTE: On Windows systems, if you specify a prefix of say d:/tmp, any file that
352 would have been restored to {\bf c:/My Documents} will be restored to {\bf
353 d:/tmp/My Documents}. That is, the original drive specification will be
354 stripped. If no prefix is specified, the file will be restored to the original
357 \subsubsection*{Extracting with Include or Exclude Lists}
358 \index[general]{Lists!Extracting with Include or Exclude }
359 \index[general]{Extracting with Include or Exclude Lists }
360 \addcontentsline{toc}{subsubsection}{Extracting with Include or Exclude Lists}
362 Using the {\bf -e} option, you can specify a file containing a list of files
363 to be excluded. Wildcards can be used in the exclusion list. This option will
364 normally be used in conjunction with the {\bf -i} option (see below). Both the
365 {\bf -e} and the {\bf -i} options may be specified at the same time as the
366 {\bf -b} option. The bootstrap filters will be applied first, then the include
367 list, then the exclude list.
369 Likewise, and probably more importantly, with the {\bf -i} option, you can
370 specify a file that contains a list (one file per line) of files and
371 directories to include to be restored. The list must contain the full filename
372 with the path. If you specify a path name only, all files and subdirectories
373 of that path will be restored. If you specify a line containing only the
374 filename (e.g. {\bf my-file.txt}) it probably will not be extracted because
375 you have not specified the full path.
377 For example, if the file {\bf include-list} contains:
390 ./bextract -i include-list -V Volume /dev/nst0 /tmp
394 will restore from the Bacula archive {\bf /dev/nst0} all files and directories
395 in the backup from {\bf /home/kern/bacula} and from {\bf /usr/local/bin}. The
396 restored files will be placed in a file of the original name under the
397 directory {\bf /tmp} (i.e. /tmp/home/kern/bacula/... and
398 /tmp/usr/local/bin/...).
400 \subsubsection*{Extracting With a Bootstrap File}
401 \index[general]{File!Extracting With a Bootstrap }
402 \index[general]{Extracting With a Bootstrap File }
403 \addcontentsline{toc}{subsubsection}{Extracting With a Bootstrap File}
405 The {\bf -b} option is used to specify a {\bf bootstrap} file containing the
406 information needed to restore precisely the files you want. Specifying a {\bf
407 bootstrap} file is optional but recommended because it gives you the most
408 control over which files will be restored. For more details on the {\bf
409 bootstrap} file, please see
410 \ilink{Restoring Files with the Bootstrap File}{_ChapterStart43}
411 chapter of this document. Note, you may also use a bootstrap file produced by
412 the {\bf restore} command. For example:
416 ./bextract -b bootstrap-file /dev/nst0 /tmp
420 The bootstrap file allows detailed specification of what files you want
421 restored (extracted). You may specify a bootstrap file and include and/or
422 exclude files at the same time. The bootstrap conditions will first be
423 applied, and then each file record seen will be compared to the include and
426 \subsubsection*{Extracting From Multiple Volumes}
427 \index[general]{Volumes!Extracting From Multiple }
428 \index[general]{Extracting From Multiple Volumes }
429 \addcontentsline{toc}{subsubsection}{Extracting From Multiple Volumes}
431 If you wish to extract files that span several Volumes, you can specify the
432 Volume names in the bootstrap file or you may specify the Volume names on the
433 command line by separating them with a vertical bar. See the section above
434 under the {\bf bls} program entitled {\bf Listing Multiple Volumes} for more
435 information. The same techniques apply equally well to the {\bf bextract}
440 \index[general]{bscan }
441 \addcontentsline{toc}{subsection}{bscan}
443 The {\bf bscan} program can be used to re-create a database (catalog) from the
444 backup information written to one or more Volumes. This is normally needed
445 only if one or more Volumes have been pruned or purged from your catalog so
446 that the records on the Volume are no longer in the catalog.
448 With some care, it can also be used to synchronize your existing catalog with
449 a Volume. Although we have never seen a case of bscan damaging a
450 catalog, since bscan modifies your catalog, we recommend that
451 you do a simple ASCII backup of your database before running {\bf bscan} just
453 \ilink{Compacting Your Database}{CompactingMySQL}.
455 {\bf bscan} can also be useful in a disaster recovery situation, after the
456 loss of a hard disk, if you do not have a valid {\bf bootstrap} file for
457 reloading your system, or if a Volume has been recycled but not overwritten,
458 you can use {\bf bscan} to re-create your database, which can then be used to
459 {\bf restore} your system or a file to its previous state.
466 Usage: bscan [options] <bacula-archive>
467 -b bootstrap specify a bootstrap file
468 -c <file> specify configuration file
469 -d <nn> set debug level to nn
470 -m update media info in database
471 -n <name> specify the database name (default bacula)
472 -u <user> specify database user name (default bacula)
473 -P <password> specify database password (default none)
474 -h <host> specify database host (default NULL)
475 -p proceed inspite of I/O errors
477 -s synchronize or store in database
479 -V <Volumes> specify Volume names (separated by |)
480 -w <dir> specify working directory (default from conf file)
481 -? print this message
485 If you are using MySQL or PostgreSQL, there is no need to supply a working
486 directory since in that case, bscan knows where the databases are. However, if
487 you have provided security on your database, you may need to supply either the
488 database name ({\bf -b} option), the user name ({\bf -u} option), and/or the
489 password ({\bf -p}) options.
491 As an example, let's suppose that you did a backup to Volumes "Vol001"
492 and "Vol002", then sometime later all records of one or both those
494 were pruned or purged from the
495 database. By using {\bf bscan} you can recreate the catalog entries for
496 those Volumes and then use the {\bf restore} command in the Console to restore
497 whatever you want. A command something like:
501 bscan -c bacula-sd.conf -v -V Vol001\|Vol002 /dev/nst0
505 will give you an idea of what is going to happen without changing
506 your catalog. Of course, you may need to change the path to the Storage
507 daemon's conf file, the Volume name, and your tape (or disk) device name. This
508 command must read the entire tape, so if it has a lot of data, it may take a
509 long time, and thus you might want to immediately use the command listed
510 below. Note, if you are writing to a disk file, replace the device name with
511 the path to the directory that contains the Volumes. This must correspond to
512 the Archive Device in the conf file.
514 Then to actually write or store the records in the catalog, add the {\bf -s}
519 bscan -s -m -c bacula-sd.conf -v -V Vol001\|Vol002 /dev/nst0
523 When writing to the database, if bscan finds existing records, it will
524 generally either update them if something is wrong or leave them alone. Thus
525 if the Volumes you are scanning are all or partially in the catalog already, no
526 harm will be done to that existing data. Any missing data will simply be
529 If you have multiple tapes, you should scan them with:
533 bscan -s -m -c bacula-sd.conf -v -V Vol001\|Vol002\|Vol003 /dev/nst0
537 You should, always try to specify the tapes in the order they are written.
538 However, bscan can handle scanning tapes that are not sequential. Any
539 incomplete records at the end of the tape will simply be ignored in that
540 case. If you are simply reparing an existing catalog, this may be OK, but
541 if you are creating a new catalog from scratch, it will leave your database
542 in an incorrect state. If you do not specify all necessary Volumes on a
543 single bscan command, bscan will not be able to correctly restore the
544 records that span two volumes. In other words, it is much better to
545 specify two or three volumes on a single bscan command rather than run
546 bscan two or three times, each with a single volume.
549 Note, the restoration process using bscan is not identical to the original
550 creation of the catalog data. This is because certain non-essential data such
551 as volume reads, volume mounts, etc is not stored on the Volume, and thus is
552 not restored by bscan. The results of bscanning are, however, perfectly valid,
553 and will permit restoration of any or all the files in the catalog using the
554 normal Bacula console commands.
556 \subsubsection*{Using bscan to Compare a Volume to an existing Catalog}
557 \index[general]{Catalog!Using bscan to Compare a Volume to an existing }
558 \index[general]{Using bscan to Compare a Volume to an existing Catalog }
559 \addcontentsline{toc}{subsubsection}{Using bscan to Compare a Volume to an
562 If you wish to compare the contents of a Volume to an existing catalog without
563 changing the catalog, you can safely do so if and only if you do {\bf not}
564 specify either the {\bf -m} or the {\bf -s} options. However, at this time
565 (Bacula version 1.26), the comparison routines are not as good or as thorough
566 as they should be, so we don't particularly recommend this mode other than for
569 \subsubsection*{Using bscan to Recreate a Catalog from a Volume}
570 \index[general]{Volume!Using bscan to Recreate a Catalog from a }
571 \index[general]{Using bscan to Recreate a Catalog from a Volume }
572 \addcontentsline{toc}{subsubsection}{Using bscan to Recreate a Catalog from a
575 This is the mode for which {\bf bscan} is most useful. You can either {\bf
576 bscan} into a freshly created catalog, or directly into your existing catalog
577 (after having made an ASCII copy as described above). Normally, you should
578 start with a freshly created catalog that contains no data.
580 Starting with a single Volume named {\bf TestVolume1}, you run a command such
585 ./bscan -V TestVolume1 -v -s -m -c bacula-sd.conf /dev/nst0
589 If there is more than one volume, simply append it to the first one separating
590 it with a vertical bar. You may need to precede the vertical bar with a
591 forward slash escape the shell -- e.g. {\bf
592 TestVolume1\textbackslash{}|TestVolume2 }. The {\bf -v} option was added for
593 verbose output (this can be omitted if desired). The {\bf -s} option that
594 tells {\bf bscan} to store information in the database. The physical device
595 name {\bf /dev/nst0} is specified after all the options.
597 {\bf } For example, after having done a full backup of a directory, then two
598 incrementals, I reinitialized the SQLite database as described above, and
599 using the bootstrap.bsr file noted above, I entered the following command:
603 ./bscan -b bootstrap.bsr -v -s -c bacula-sd.conf /dev/nst0
607 which produced the following output:
611 bscan: bscan.c:182 Using Database: bacula, User: bacula
612 bscan: bscan.c:673 Created Pool record for Pool: Default
613 bscan: bscan.c:271 Pool type "Backup" is OK.
614 bscan: bscan.c:632 Created Media record for Volume: TestVolume1
615 bscan: bscan.c:298 Media type "DDS-4" is OK.
616 bscan: bscan.c:307 VOL_LABEL: OK for Volume: TestVolume1
617 bscan: bscan.c:693 Created Client record for Client: Rufus
618 bscan: bscan.c:769 Created new JobId=1 record for original JobId=2
619 bscan: bscan.c:717 Created FileSet record "Kerns Files"
620 bscan: bscan.c:819 Updated Job termination record for new JobId=1
621 bscan: bscan.c:905 Created JobMedia record JobId 1, MediaId 1
622 bscan: Got EOF on device /dev/nst0
623 bscan: bscan.c:693 Created Client record for Client: Rufus
624 bscan: bscan.c:769 Created new JobId=2 record for original JobId=3
625 bscan: bscan.c:708 Fileset "Kerns Files" already exists.
626 bscan: bscan.c:819 Updated Job termination record for new JobId=2
627 bscan: bscan.c:905 Created JobMedia record JobId 2, MediaId 1
628 bscan: Got EOF on device /dev/nst0
629 bscan: bscan.c:693 Created Client record for Client: Rufus
630 bscan: bscan.c:769 Created new JobId=3 record for original JobId=4
631 bscan: bscan.c:708 Fileset "Kerns Files" already exists.
632 bscan: bscan.c:819 Updated Job termination record for new JobId=3
633 bscan: bscan.c:905 Created JobMedia record JobId 3, MediaId 1
634 bscan: Got EOF on device /dev/nst0
635 bscan: bscan.c:652 Updated Media record at end of Volume: TestVolume1
636 bscan: bscan.c:428 End of Volume. VolFiles=3 VolBlocks=57 VolBytes=10,027,437
640 The key points to note are that {\bf bscan} prints a line when each major
641 record is created. Due to the volume of output, it does not print a line for
642 each file record unless you supply the {\bf -v} option twice or more on the
645 In the case of a Job record, the new JobId will not normally be the same as
646 the original Jobid. For example, for the first JobId above, the new JobId is
647 1, but the original JobId is 2. This is nothing to be concerned about as it is
648 the normal nature of databases. {\bf bscan} will keep everything straight.
650 Although {\bf bscan} claims that it created a Client record for Client: Rufus
651 three times, it was actually only created the first time. This is normal.
653 You will also notice that it read an end of file after each Job (Got EOF on
654 device ...). Finally the last line gives the total statistics for the bscan.
656 If you had added a second {\bf -v} option to the command line, Bacula would
657 have been even more verbose, dumping virtually all the details of each Job
658 record it encountered.
660 Now if you start Bacula and enter a {\bf list jobs} command to the console
661 program, you will get:
665 +-------+----------+------------------+------+-----+----------+----------+---------+
666 | JobId | Name | StartTime | Type | Lvl | JobFiles | JobBytes | JobStat |
667 +-------+----------+------------------+------+-----+----------+----------+---------+
668 | 1 | kernsave | 2002-10-07 14:59 | B | F | 84 | 4180207 | T |
669 | 2 | kernsave | 2002-10-07 15:00 | B | I | 15 | 2170314 | T |
670 | 3 | kernsave | 2002-10-07 15:01 | B | I | 33 | 3662184 | T |
671 +-------+----------+------------------+------+-----+----------+----------+---------+
675 which corresponds virtually identically with what the database contained
676 before it was re-initialized and restored with bscan. All the Jobs and Files
677 found on the tape are restored including most of the Media record. The Volume
678 (Media) records restored will be marked as {\bf Full} so that they cannot be
679 rewritten without operator intervention.
681 It should be noted that {\bf bscan} cannot restore a database to the exact
682 condition it was in previously because a lot of the less important information
683 contained in the database is not saved to the tape. Nevertheless, the
684 reconstruction is sufficiently complete, that you can run {\bf restore}
685 against it and get valid results.
687 \subsubsection*{Using bscan to Correct the Volume File Count}
688 \index[general]{Using bscan to Correct the Volume File Count }
689 \index[general]{Count!Using bscan to Correct the Volume File }
690 \addcontentsline{toc}{subsubsection}{Using bscan to Correct the Volume File
693 If the Storage daemon crashes during a backup Job, the catalog will not be
694 properly updated for the Volume being used at the time of the crash. This
695 means that the Storage daemon will have written say 20 files on the tape, but
696 the catalog record for the Volume indicates only 19 files.
698 Bacula refuses to write on a tape that contains a different number of files
699 from what is in the catalog. To correct this situation, you may run a {\bf
700 bscan} with the {\bf -m} option (but {\bf without} the {\bf -s} option) to
701 update only the final Media record for the Volumes read.
703 \subsubsection*{After bscan}
704 \index[general]{After bscan }
705 \index[general]{Bscan!After }
706 \addcontentsline{toc}{subsubsection}{After bscan}
708 If you use {\bf bscan} to enter the contents of the Volume into an existing
709 catalog, you should be aware that the records you entered may be immediately
710 pruned during the next job, particularly if the Volume is very old or had been
711 previously purged. To avoid this, after running {\bf bscan}, you can manually
712 set the volume status (VolStatus) to {\bf Read-Only} by using the {\bf update}
713 command in the catalog. This will allow you to restore from the volume without
714 having it immediately purged. When you have restored and backed up the data,
715 you can reset the VolStatus to {\bf Used} and the Volume will be purged from
720 \index[general]{Bcopy }
721 \addcontentsline{toc}{subsection}{bcopy}
723 The {\bf bcopy} program can be used to copy one {\bf Bacula} archive file to
724 another. For example, you may copy a tape to a file, a file to a tape, a file
725 to a file, or a tape to a tape. For tape to tape, you will need two tape
726 drives. (a later version is planned that will buffer it to disk). In the
727 process of making the copy, no record of the information written to the new
728 Volume is stored in the catalog. This means that the new Volume, though it
729 contains valid backup data, cannot be accessed directly from existing catalog
730 entries. If you wish to be able to use the Volume with the Console restore
731 command, for example, you must first bscan the new Volume into the catalog.
733 \subsubsection*{bcopy Command Options}
734 \index[general]{Options!bcopy Command }
735 \index[general]{Bcopy Command Options }
736 \addcontentsline{toc}{subsubsection}{bcopy Command Options}
740 Usage: bcopy [-d debug_level] <input-archive> <output-archive>
741 -b bootstrap specify a bootstrap file
742 -c <file> specify configuration file
743 -dnn set debug level to nn
744 -i specify input Volume names (separated by |)
745 -o specify output Volume names (separated by |)
746 -p proceed inspite of I/O errors
748 -w dir specify working directory (default /tmp)
749 -? print this message
753 By using a {\bf bootstrap} file, you can copy parts of a Bacula archive file
756 One of the objectives of this program is to be able to recover as much data as
757 possible from a damaged tape. However, the current version does not yet have
760 As this is a new program, any feedback on its use would be appreciated. In
761 addition, I only have a single tape drive, so I have never been able to test
762 this program with two tape drives.
766 \index[general]{Btape }
767 \addcontentsline{toc}{subsection}{btape}
769 This program permits a number of elementary tape operations via a tty command
770 interface. The {\bf test} command, described below, can be very useful for
771 testing older tape drive compatibility problems. Aside from initial testing of
772 tape drive compatibility with {\bf Bacula}, {\bf btape} will be mostly used by
773 developers writing new tape drivers.
775 {\bf btape} can be dangerous to use with existing {\bf Bacula} tapes because
776 it will relabel a tape or write on the tape if so requested regardless that
777 the tape may contain valuable data, so please be careful and use it only on
780 To work properly, {\bf btape} needs to read the Storage daemon's configuration
781 file. As a default, it will look for {\bf bacula-sd.conf} in the current
782 directory. If your configuration file is elsewhere, please use the {\bf -c}
783 option to specify where.
785 The physical device name must be specified on the command line, and this
786 same device name must be present in the Storage daemon's configuration file
791 Usage: btape [-c config_file] [-d debug_level] [device_name]
792 -c <file> set configuration file to file
793 -dnn set debug level to nn
795 -t open the default tape device
796 -? print this message.
800 \subsubsection*{Using btape to Verify your Tape Drive}
801 \index[general]{Using btape to Verify your Tape Drive }
802 \index[general]{Drive!Using btape to Verify your Tape }
803 \addcontentsline{toc}{subsubsection}{Using btape to Verify your Tape Drive}
805 An important reason for this program is to ensure that a Storage daemon
806 configuration file is defined so that Bacula will correctly read and write
809 It is highly recommended that you run the {\bf test} command before running
810 your first Bacula job to ensure that the parameters you have defined for your
811 storage device (tape drive) will permit {\bf Bacula} to function properly. You
812 only need to mount a blank tape, enter the command, and the output should be
813 reasonably self explanatory. Please see the
814 \ilink{Tape Testing}{_ChapterStart27} Chapter of this manual for
817 \subsubsection*{btape Commands}
818 \index[general]{Btape Commands }
819 \index[general]{Commands!btape }
820 \addcontentsline{toc}{subsubsection}{btape Commands}
822 The full list of commands are:
830 cap list device capabilities
831 clear clear tape errors
832 eod go to end of Bacula data for append
833 test General test Bacula tape functions
834 eom go to the physical end of medium
835 fill fill tape, write onto second volume
836 unfill read filled tape
837 fsf forward space a file
838 fsr forward space a record
839 help print this command
840 label write a Bacula label to the tape
844 readlabel read and print the Bacula tape label
845 rectest test record handling functions
846 rewind rewind the tape
847 scan read tape block by block to EOT and report
848 status print tape status
849 test test a tape for compatibility with Bacula
850 weof write an EOF on the tape
851 wr write a single record of 2048 bytes
855 The most useful commands are:
858 \item test -- test writing records and EOF marks and reading them back.
859 \item fill -- completely fill a volume with records, then write a few records
860 on a second volume, and finally, both volumes will be read back.
861 This command writes blocks containing random data, so your drive will
862 not be able to compress the data, and thus it is a good test of
863 the real physical capacity of your tapes.
864 \item readlabel -- read and dump the label on a Bacula tape.
865 \item cap -- list the device capabilities as defined in the configuration
866 file and as perceived by the Storage daemon.
869 The {\bf readlabel} command can be used to display the details of a Bacula
870 tape label. This can be useful if the physical tape label was lost or damaged.
873 In the event that you want to relabel a {\bf Bacula}, you can simply use the
874 {\bf label} command which will write over any existing label. However, please
875 note for labeling tapes, we recommend that you use the {\bf label} command in
876 the {\bf Console} program since it will never overwrite a valid Bacula tape.
878 \subsection*{Other Programs}
879 \index[general]{Programs!Other }
880 \index[general]{Other Programs }
881 \addcontentsline{toc}{subsection}{Other Programs}
883 The following programs are general utility programs and in general do not need
884 a configuration file nor a device name.
888 \index[general]{Bsmtp }
889 \addcontentsline{toc}{subsection}{bsmtp}
891 {\bf bsmtp} is a simple mail transport program that permits more flexibility
892 than the standard mail programs typically found on Unix systems. It can even
893 be used on Windows machines.
899 Usage: bsmtp [-f from] [-h mailhost] [-s subject] [-c copy] [recipient ...]
901 -dnn set debug level to nn
902 -f set the From: field
903 -h use mailhost:port as the bsmtp server
904 -s set the Subject: field
905 -? print this message.
909 If the {\bf -f} option is not specified, {\bf bsmtp} will use your userid. If
910 the option is not specified {\bf bsmtp} will use the value in the environment
911 variable {\bf bsmtpSERVER} or if there is none {\bf localhost}. By default
914 {\bf recipients} is a space separated list of email recipients.
916 The body of the email message is read from standard input.
918 An example of the use of {\bf bsmtp} would be to put the following statement
919 in the {\bf Messages} resource of your {\bf bacula-dir.conf} file. Note, these
920 commands should appear on a single line each.
924 mailcommand = "/home/bacula/bin/bsmtp -h mail.domain.com -f \"\(Bacula\) %r\"
925 -s \"Bacula: %t %e of %c %l\" %r"
926 operatorcommand = "/home/bacula/bin/bsmtp -h mail.domain.com -f \"\(Bacula\) %r\"
927 -s \"Bacula: Intervention needed for %j\" %r"
931 Where you replace {\bf /home/bacula/bin} with the path to your {\bf Bacula}
932 binary directory, and you replace {\bf mail.domain.com} with the fully
933 qualified name of your bsmtp (email) server, which normally listens on port
934 25. For more details on the substitution characters (e.g. \%r) used in the
935 above line, please see the documentation of the
936 \ilink{ MailCommand in the Messages Resource}{mailcommand}
937 chapter of this manual.
939 It is HIGHLY recommended that you test one or two cases by hand to make sure
940 that the {\bf mailhost} that you specified is correct and that it will accept
941 your email requests. Since {\bf bsmtp} always uses a TCP connection rather
942 than writing in the spool file, you may find that your {\bf from} address is
943 being rejected because it does not contain a valid domain, or because your
944 message is caught in your spam filtering rules. Generally, you should specify
945 a fully qualified domain name in the {\bf from} field, and depending on
946 whether your bsmtp gateway is Exim or Sendmail, you may need to modify the
947 syntax of the from part of the message. Please test.
949 When running {\bf bsmtp} by hand, you will need to terminate the message by
950 entering a ctl-d in column 1 of the last line.
952 \subsection*{dbcheck}
954 \index[general]{Dbcheck }
955 \addcontentsline{toc}{subsection}{dbcheck}
957 {\bf dbcheck} is a simple program that will search for inconsistencies in your
958 database, and optionally fix them. The {\bf dbcheck} program can be found in
959 the {\bf \lt{}bacula-source\gt{}/src/tools} directory of the source
960 distribution. Though it is built with the make process, it is not normally
967 Usage: dbcheck [-c config] [-C catalog name] [-d debug_level] []
969 -C catalog name in the director conf file
970 -c director conf filename
971 -dnn set debug level to nn
972 -f fix inconsistencies
974 -? print this message
978 If the {\bf -c} option is given with the Director's conf file, there is no
979 need to enter any of the command line arguments, in particular the working
980 directory as dbcheck will read them from the file.
982 If the {\bf -f} option is specified, {\bf dbcheck} will repair ({\bf fix}) the
983 inconsistencies it finds. Otherwise, it will report only.
985 If the {\bf -b} option is specified, {\bf dbcheck} will run in batch mode, and
986 it will proceed to examine and fix (if -f is set) all programmed inconsistency
987 checks. If the {\bf -b} option is not specified, {\bf dbcheck} will enter
988 interactive mode and prompt with the following:
992 Hello, this is the database check/correct program.
993 Please select the function you want to perform.
994 1) Toggle modify database flag
995 2) Toggle verbose flag
996 3) Repair bad Filename records
997 4) Repair bad Path records
998 5) Eliminate duplicate Filename records
999 6) Eliminate duplicate Path records
1000 7) Eliminate orphaned Jobmedia records
1001 8) Eliminate orphaned File records
1002 9) Eliminate orphaned Path records
1003 10) Eliminate orphaned Filename records
1004 11) Eliminate orphaned FileSet records
1005 12) Eliminate orphaned Client records
1006 13) Eliminate orphaned Job records
1007 14) Eliminate all Admin records
1008 15) Eliminate all Restore records
1011 Select function number:
1015 By entering 1 or 2, you can toggle the modify database flag (-f option) and
1016 the verbose flag (-v). It can be helpful and reassuring to turn off the modify
1017 database flag, then select one or more of the consistency checks (items 3
1018 through 9) to see what will be done, then toggle the modify flag on and re-run
1021 The inconsistencies examined are the following:
1024 \item Duplicate filename records. This can happen if you accidentally run two
1025 copies of Bacula at the same time, and they are both adding filenames
1026 simultaneously. It is a rare occurrence, but will create an inconsistent
1027 database. If this is the case, you will receive error messages during Jobs
1028 warning of duplicate database records. If you are not getting these error
1029 messages, there is no reason to run this check.
1030 \item Repair bad Filename records. This checks and corrects filenames that
1031 have a trailing slash. They should not.
1032 \item Repair bad Path records. This checks and corrects path names that do
1033 not have a trailing slash. They should.
1034 \item Duplicate path records. This can happen if you accidentally run two
1035 copies of Bacula at the same time, and they are both adding filenames
1036 simultaneously. It is a rare occurrence, but will create an inconsistent
1037 database. See the item above for why this occurs and how you know it is
1039 \item Orphaned JobMedia records. This happens when a Job record is deleted
1040 (perhaps by a user issued SQL statement), but the corresponding JobMedia
1041 record (one for each Volume used in the Job) was not deleted. Normally, this
1042 should not happen, and even if it does, these records generally do not take
1043 much space in your database. However, by running this check, you can
1044 eliminate any such orphans.
1045 \item Orphaned File records. This happens when a Job record is deleted
1046 (perhaps by a user issued SQL statement), but the corresponding File record
1047 (one for each Volume used in the Job) was not deleted. Note, searching for
1048 these records can be {\bf very} time consuming (i.e. it may take hours) for a
1049 large database. Normally this should not happen as Bacula takes care to
1050 prevent it. Just the same, this check can remove any orphaned File records.
1051 It is recommended that you run this once a year since orphaned File records
1052 can take a large amount of space in your database.
1053 \item Orphaned Path records. This condition happens any time a directory is
1054 deleted from your system and all associated Job records have been purged.
1055 During standard purging (or pruning) of Job records, Bacula does not check
1056 for orphaned Path records. As a consequence, over a period of time, old
1057 unused Path records will tend to accumulate and use space in your database.
1058 This check will eliminate them. It is strongly recommended that you run this
1059 check at least once a year.
1060 \item Orphaned Filename records. This condition happens any time a file is
1061 deleted from your system and all associated Job records have been purged.
1062 This can happen quite frequently as there are quite a large number of files
1063 that are created and then deleted. In addition, if you do a system update or
1064 delete an entire directory, there can be a very large number of Filename
1065 records that remain in the catalog but are no longer used.
1067 During standard purging (or pruning) of Job records, Bacula does not check
1068 for orphaned Filename records. As a consequence, over a period of time, old
1069 unused Filename records will accumulate and use space in your database. This
1070 check will eliminate them. It is strongly recommended that you run this check
1071 at least once a year, and for large database (more than 200 Megabytes), it is
1072 probably better to run this once every 6 months.
1073 \item Orphaned Client records. These records can remain in the database long
1074 after you have removed a client.
1075 \item Orphaned Job records. If no client is defined for a job or you do not
1076 run a job for a long time, you can accumulate old job records. This option
1077 allow you to remove jobs that are not attached to any client (and thus
1079 \item All Admin records. This command will remove all Admin records,
1080 regardless of their age.
1081 \item All Restore records. This command will remove all Restore records,
1082 regardless of their age.
1085 \subsection*{testfind}
1087 \index[general]{Testfind }
1088 \addcontentsline{toc}{subsection}{testfind}
1090 {\bf testfind} permits listing of files using the same search engine that is
1091 used for the {\bf Include} resource in Job resources. Note, much of the
1092 functionality of this program (listing of files to be included) is present in
1094 \ilink{estimate command}{estimate} in the Console program.
1096 The original use of testfind was to ensure that Bacula's file search engine
1097 was correct and to print some statistics on file name and path length.
1098 However, you may find it useful to see what bacula would do with a given {\bf
1099 Include} resource. The {\bf testfind} program can be found in the {\bf
1100 \lt{}bacula-source\gt{}/src/tools} directory of the source distribution.
1101 Though it is built with the make process, it is not normally "installed".
1107 Usage: testfind [-d debug_level] [-] [pattern1 ...]
1108 -a print extended attributes (Win32 debug)
1109 -dnn set debug level to nn
1110 - read pattern(s) from stdin
1111 -? print this message.
1112 Patterns are used for file inclusion -- normally directories.
1113 Debug level>= 1 prints each file found.
1114 Debug level>= 10 prints path/file for catalog.
1115 Errors are always printed.
1116 Files/paths truncated is a number with len> 255.
1117 Truncation is only in the catalog.
1121 Where a pattern is any filename specification that is valid within an {\bf
1122 Include} resource definition. If none is specified, {\bf /} (the root
1123 directory) is assumed. For example:
1131 Would print the following:
1137 Lnk: /bin/bash2 -> bash
1138 Lnk: /bin/sh -> bash
1146 Reg: /bin/aumix-minimal
1148 Lnka: /bin/gawk-3.1.0 -> /bin/gawk
1158 Even though {\bf testfind} uses the same search engine as {\bf Bacula}, each
1159 directory to be listed, must be entered as a separate command line entry or
1160 entered one line at a time to standard input if the {\bf -} option was
1163 Specifying a debug level of one (i.e. {\bf -d1}) on the command line will
1164 cause {\bf testfind} to print the raw filenames without showing the Bacula
1165 internal file type, or the link (if any). Debug levels of 10 or greater cause
1166 the filename and the path to be separated using the same algorithm that is
1167 used when putting filenames into the Catalog database.