4 \section*{Testing Your Tape Drive With Bacula}
5 \label{_ChapterStart27}
6 \index[general]{Testing Your Tape Drive With Bacula}
7 \addcontentsline{toc}{section}{Testing Your Tape Drive With Bacula}
9 This chapter is concerned with testing and configuring your tape drive to make
10 sure that it will work properly with Bacula using the {\bf btape} program.
13 \subsection*{Summary of Steps to Take to Get Your Tape Drive Working}
14 \index[general]{Working!Summary of Steps to Take to Get Your Tape Drive}
15 \index[general]{Summary of Steps to Take to Get Your Tape Drive Working}
16 \addcontentsline{toc}{subsection}{Summary of Steps to Take to Get Your Tape
19 In general, you should follow the following steps to get your tape drive to
20 work with Bacula. Start with a tape mounted in your drive. If you have an
21 autochanger, load a tape into the drive. We use {\bf /dev/nst0} as the tape
22 drive name, you will need to adapt it according to your system.
24 Do not proceed to the next item until you have succeeded with the previous
28 \item Use tar to write to, then read from your drive:
32 mt -f /dev/nst0 rewind
34 mt -f /dev/nst0 rewind
40 \item Make sure you have a valid and correct Device resource corresponding to
41 your drive. For Linux users, generally, the default one works. For FreeBSD
42 users, there are two possible Device configurations (see below).
43 \item Run the btape {\bf test} command:
47 ./btape -c bacula-sd.conf /dev/nst0
53 It isn't necessary to run the autochanger part of the test at this time, but
54 do not go past this point until the basic test succeeds. If you do have
55 an autochanger, please be sure to read the
56 \ilink{Autochanger chapter}{_ChapterStart18} of this manual.
58 \item Run the btape {\bf fill} command, preferably with two volumes. This
59 can take a long time. If you have an autochanger and it is configured, Bacula
60 will automatically use it. If you do not have it configured, you can manually
61 issue the appopriate {\bf mtx} command, or press the autochanger buttons to
62 change the tape when requested to do so.
63 \item FreeBSD users, run the {\bf tapetest} program, and make sure your
64 system is patched if necessary. See below for more details.
65 \item Run Bacula, and backup a reasonably small directory, say 60 Megabytes.
66 Do three successive backups of this directory.
67 \item Stop Bacula, then restart it. Do another full backup of the same
68 directory. Then stop and restart Bacula.
69 \item Do a restore of the directory backed up, by entering the following
70 restore command, being careful to restore it to an alternate location:
74 restore select all done
80 Do a {\bf diff} on the restored directory to ensure it is identical to the
82 \item If you have an autochanger, you should now go back to the btape program
83 and run the autochanger test:
87 ./btape -c bacula-sd.conf /dev/nst0
93 Adjust your autochanger as necessary to ensure that it works correctly. See
94 the Autochanger chapter of this manual for a complete discussion of testing
98 If you have reached this point, you stand a good chance of having everything
99 work. If you get into trouble at any point, {\bf carefully} read the
100 documentation given below. If you cannot get past some point, ask the {\bf
101 bacula-users} email list, but specify which of the steps you have successfully
102 completed. In particular, you may want to look at the
103 \ilink{ Tips for Resolving Problems}{problems1} section below.
105 \label{NoTapeInDrive}
106 \subsubsection*{Problems When no Tape in Drive}
107 \index[general]{Problems When no Tape in Drive}
108 \addcontentsline{toc}{subsubsection}{Problems When no Tape in Drive}
109 When Bacula was first written the Linux 2.4 kernel permitted opening the
110 drive whether or not there was a tape in the drive. Thus the Bacula code is
111 based on the concept that if the drive cannot be opened, there is a serious
112 problem, and the job is failed.
114 With version 2.6 of the Linux kernel, if there is no tape in the drive, the
115 OS will wait 2 minutes (default) then return a failure, and consequently,
116 Bacula version 1.36 and below will fail the job. This is important to keep
117 in mind, because if you use and option such as {\bf Offline on Unmount =
118 yes}, there will be a point when there is no tape in the drive, and if
119 another job starts or if Bacula asks the operator to mount a tape, when
120 Bacula attempts to open the drive (about a 20 minute delay), it will fail
121 and Bacula will fail the job.
123 In version 1.38.x, the Bacula code partially gets around this problem -- at
124 least in the initial open of the drive. However, functions like Polling
125 the drive do not work correctly if there is no tape in the drive.
126 Providing you do not use {\bf Offline on Unmount = yes}, you should not
127 experience job failures as mentioned above. If you do experience such
128 failures, you can also increase the {\bf Maximum Open Wait} time interval,
129 which will give you more time to mount the next tape before the job is
134 \subsubsection*{Specifying the Configuration File}
135 \index[general]{File!Specifying the Configuration}
136 \index[general]{Specifying the Configuration File}
137 \addcontentsline{toc}{subsubsection}{Specifying the Configuration File}
139 Starting with version 1.27, each of the tape utility programs including the
140 {\bf btape} program requires a valid Storage daemon configuration file
141 (actually, the only part of the configuration file that {\bf btape} needs is
142 the {\bf Device} resource definitions). This permits {\bf btape} to find the
143 configuration parameters for your archive device (generally a tape drive).
144 Without those parameters, the testing and utility programs do not know how to
145 properly read and write your drive. By default, they use {\bf bacula-sd.conf}
146 in the current directory, but you may specify a different configuration file
147 using the {\bf -c} option.
149 \subsubsection*{Specifying a Device Name For a Tape}
150 \index[general]{Tape!Specifying a Device Name For a}
151 \index[general]{Specifying a Device Name For a Tape}
152 \addcontentsline{toc}{subsubsection}{Specifying a Device Name For a Tape}
154 {\bf btape} {\bf device-name} where the Volume can be found. In the case of a
155 tape, this is the physical device name such as {\bf /dev/nst0} or {\bf
156 /dev/rmt/0ubn} depending on your system that you specify on the Archive Device
157 directive. For the program to work, it must find the identical name in the
158 Device resource of the configuration file. If the name is not found in the
159 list of phsical names, the utility program will compare the name you entered
160 to the Device names (rather than the Archive device names). See below for
161 specifying Volume names.
163 \subsubsection*{Specifying a Device Name For a File}
164 \index[general]{File!Specifying a Device Name For a}
165 \index[general]{Specifying a Device Name For a File}
166 \addcontentsline{toc}{subsubsection}{Specifying a Device Name For a File}
168 If you are attempting to read or write an archive file rather than a tape, the
169 {\bf device-name} should be the full path to the archive location including
170 the filename. The filename (last part of the specification) will be stripped
171 and used as the Volume name, and the path (first part before the filename)
172 must have the same entry in the configuration file. So, the path is equivalent
173 to the archive device name, and the filename is equivalent to the volume name.
178 \index[general]{Btape}
179 \addcontentsline{toc}{subsection}{btape}
181 This program permits a number of elementary tape operations via a tty command
182 interface. The {\bf test} command, described below, can be very useful for
183 testing tape drive compatibility problems. Aside from initial testing of tape
184 drive compatibility with {\bf Bacula}, {\bf btape} will be mostly used by
185 developers writing new tape drivers.
187 {\bf btape} can be dangerous to use with existing {\bf Bacula} tapes because
188 it will relabel a tape or write on the tape if so requested regardless of
189 whether or not the tape contains valuable data, so please be careful and use
190 it only on blank tapes.
192 To work properly, {\bf btape} needs to read the Storage daemon's configuration
193 file. As a default, it will look for {\bf bacula-sd.conf} in the current
194 directory. If your configuration file is elsewhere, please use the {\bf -c}
195 option to specify where.
197 The physical device name or the Device resource name must be specified on the
198 command line, and this same device name must be present in the Storage
199 daemon's configuration file read by {\bf btape}
203 Usage: btape [options] device_name
204 -b <file> specify bootstrap file
205 -c <file> set configuration file to file
206 -d <nn> set debug level to nn
207 -p proceed inspite of I/O errors
210 -? print this message.
214 \subsubsection*{Using btape to Verify your Tape Drive}
215 \index[general]{Using btape to Verify your Tape Drive}
216 \index[general]{Drive!Using btape to Verify your Tape}
217 \addcontentsline{toc}{subsubsection}{Using btape to Verify your Tape Drive}
219 An important reason for this program is to ensure that a Storage daemon
220 configuration file is defined so that Bacula will correctly read and write
223 It is highly recommended that you run the {\bf test} command before running
224 your first Bacula job to ensure that the parameters you have defined for your
225 storage device (tape drive) will permit {\bf Bacula} to function properly. You
226 only need to mount a blank tape, enter the command, and the output should be
227 reasonably self explanatory. For example:
231 (ensure that Bacula is not running)
232 ./btape -c /usr/bin/bacula/bacula-sd.conf /dev/nst0
240 Tape block granularity is 1024 bytes.
241 btape: btape.c:376 Using device: /dev/nst0
246 Enter the test command:
254 The output produced should be something similar to the following: I've cut the
255 listing short because it is frequently updated to have new tests.
259 === Append files test ===
260 This test is essential to Bacula.
261 I'm going to write one record in file 0,
262 two records in file 1,
263 and three records in file 2
264 btape: btape.c:387 Rewound /dev/nst0
265 btape: btape.c:855 Wrote one record of 64412 bytes.
266 btape: btape.c:857 Wrote block to device.
267 btape: btape.c:410 Wrote EOF to /dev/nst0
268 btape: btape.c:855 Wrote one record of 64412 bytes.
269 btape: btape.c:857 Wrote block to device.
270 btape: btape.c:855 Wrote one record of 64412 bytes.
271 btape: btape.c:857 Wrote block to device.
272 btape: btape.c:410 Wrote EOF to /dev/nst0
273 btape: btape.c:855 Wrote one record of 64412 bytes.
274 btape: btape.c:857 Wrote block to device.
275 btape: btape.c:855 Wrote one record of 64412 bytes.
276 btape: btape.c:857 Wrote block to device.
277 btape: btape.c:855 Wrote one record of 64412 bytes.
278 btape: btape.c:857 Wrote block to device.
279 btape: btape.c:410 Wrote EOF to /dev/nst0
280 btape: btape.c:387 Rewound /dev/nst0
281 btape: btape.c:693 Now moving to end of media.
282 btape: btape.c:427 Moved to end of media
283 We should be in file 3. I am at file 3. This is correct!
284 Now the important part, I am going to attempt to append to the tape.
286 === End Append files test ===
290 If you do not successfully complete the above test, please resolve the
291 problem(s) before attempting to use {\bf Bacula}. Depending on your tape
292 drive, the test may recommend that you add certain records to your
293 configuration. We strongly recommend that you do so and then re-run the above
294 test to insure it works the first time.
296 Some of the suggestions it provides for resolving the problems may or may not
297 be useful. If at all possible avoid using fixed blocking. If the test suddenly
298 starts to print a long series of:
308 then almost certainly, you are running your drive in fixed block mode rather
309 than variable block mode. Please see below for help on resolving that.
311 For FreeBSD users, please see the notes below for doing further testing of
314 \subsubsection*{Linux SCSI Tricks}
315 \index[general]{Tricks!Linux SCSI}
316 \index[general]{Linux SCSI Tricks}
317 \addcontentsline{toc}{subsubsection}{Linux SCSI Tricks}
319 You can find out what SCSI devices you have by doing:
327 For example, I get the following:
332 Host: scsi2 Channel: 00 Id: 01 Lun: 00
333 Vendor: HP Model: C5713A Rev: H107
334 Type: Sequential-Access ANSI SCSI revision: 02
335 Host: scsi2 Channel: 00 Id: 04 Lun: 00
336 Vendor: SONY Model: SDT-10000 Rev: 0110
337 Type: Sequential-Access ANSI SCSI revision: 02
341 The above represents first an autochanger and second a simple
342 tape drive. The HP changer (the first entry) uses the same SCSI channel
343 for data and for control, so in Bacula, you would use:
346 Archive Device = /dev/nst0
347 Changer Device = /dev/sg0
351 If you want to remove the SDT-10000 device, you can do so as root with:
355 echo "scsi remove-single-device 2 0 4 0">/proc/scsi/scsi
359 and you can put add it back with:
363 echo "scsi add-single-device 2 0 4 0">/proc/scsi/scsi
367 where the 2 0 4 0 are the Host, Channel, Id, and Lun as seen on the output
368 from {\bf cat /proc/scsi/scsi}. Note, the Channel must be specified as
371 Below is a slightly more complicated output, which is a single autochanger
372 with two drives, and which operates the changer on a different channel
373 from from the drives:
378 Host: scsi0 Channel: 00 Id: 00 Lun: 00
379 Vendor: ATA Model: WDC WD1600JD-75H Rev: 08.0
380 Type: Direct-Access ANSI SCSI revision: 05
381 Host: scsi2 Channel: 00 Id: 04 Lun: 00
382 Vendor: HP Model: Ultrium 2-SCSI Rev: F6CH
383 Type: Sequential-Access ANSI SCSI revision: 03
384 Host: scsi2 Channel: 00 Id: 05 Lun: 00
385 Vendor: HP Model: Ultrium 2-SCSI Rev: F6CH
386 Type: Sequential-Access ANSI SCSI revision: 03
387 Host: scsi2 Channel: 00 Id: 06 Lun: 00
388 Vendor: OVERLAND Model: LXB Rev: 0106
389 Type: Medium Changer ANSI SCSI revision: 02
393 The above tape drives are accessed on /dev/nst0 and /dev/nst1, while
394 the control channel for those two drives is /dev/sg3.
399 \subsection*{Tips for Resolving Problems}
400 \index[general]{Problems!Tips for Resolving}
401 \index[general]{Tips for Resolving Problems}
402 \addcontentsline{toc}{subsection}{Tips for Resolving Problems}
404 \label{CannotRestore}
405 \subsubsection*{Bacula Saves But Cannot Restore Files}
406 \index[general]{Files!Bacula Saves But Cannot Restore}
407 \index[general]{Bacula Saves But Cannot Restore Files}
408 \addcontentsline{toc}{subsubsection}{Bacula Saves But Cannot Restore Files}
410 If you are getting error messages such as:
414 Volume data error at 0:1! Wanted block-id: "BB02", got "". Buffer discarded
418 It is very likely that Bacula has tried to do block positioning and ended up
419 at an invalid block. This can happen if your tape drive is in fixed block mode
420 while Bacula's default is variable blocks. Note that in such cases, Bacula is
421 perfectly able to write to your Volumes (tapes), but cannot position to read
424 There are two possible solutions.
427 \item The first and best is to always ensure that your drive is in variable
428 block mode. Note, it can switch back to fixed block mode on a reboot or if
429 another program uses the drive. So on such systems you need to modify the
430 Bacula startup files to explicitly set:
434 mt -f /dev/nst0 defblksize 0
438 or whatever is appropriate on your system.
439 \item The second possibility, especially, if Bacula wrote while the drive was
440 in fixed block mode, is to turn off block positioning in Bacula. This is done
445 Block Positioning = no
449 to the Device resource. This is not the recommended procedure because it can
450 enormously slow down recovery of files, but it may help where all else
451 fails. This directive is available in version 1.35.5 or later (and not yet
455 If you are getting error messages such as:
458 Volume data error at 0:0!
459 Block checksum mismatch in block=0 len=32625 calc=345678 blk=123456
463 You are getting tape read errors, and this is most likely due to
464 one of the following things:
466 \item An old or bad tape.
467 \item A dirty drive that needs cleaning (particularly for DDS drives).
468 \item A loose SCSI cable.
469 \item Old firmware in your drive. Make sure you have the latest firmware
471 \item Computer memory errors.
472 \item Over-clocking your CPU.
473 \item A bad SCSI card.
478 \subsubsection*{Bacula Cannot Open the Device}
479 \index[general]{Device!Bacula Cannot Open the}
480 \index[general]{Bacula Cannot Open the Device}
481 \addcontentsline{toc}{subsubsection}{Bacula Cannot Open the Device}
483 If you get an error message such as:
487 dev open failed: dev.c:265 stored: unable to open
488 device /dev/nst0:> ERR=No such device or address
492 the first time you run a job, it is most likely due to the fact that you
493 specified the incorrect device name on your {\bf Archive Device}.
495 If Bacula works fine with your drive, then all off a sudden you get error
496 messages similar to the one shown above, it is quite possible that your driver
497 module is being removed because the kernel deems it idle. This is done via
498 {\bf crontab} with the use of {\bf rmmod -a}. To fix the problem, you can
499 remove this entry from {\bf crontab}, or you can manually {\bf modprob} your
500 driver module (or add it to the local startup script). Thanks to Alan Brown
502 \label{IncorrectFiles}
504 \subsubsection*{Incorrect File Number}
505 \index[general]{Number!Incorrect File}
506 \index[general]{Incorrect File Number}
507 \addcontentsline{toc}{subsubsection}{Incorrect File Number}
509 When Bacula moves to the end of the medium, it normally uses the {\bf
510 ioctl(MTEOM)} function. Then Bacula uses the {\bf ioctl(MTIOCGET)} function to
511 retrieve the current file position from the {\bf mt\_fileno} field. Some SCSI
512 tape drivers will use a fast means of seeking to the end of the medium and in
513 doing so, they will not know the current file position and hence return a {\bf
514 -1}. As a consequence, if you get {\bf "This is NOT correct!"} in the
515 positioning tests, this may be the cause. You must correct this condition in
516 order for Bacula to work.
518 There are two possible solutions to the above problem of incorrect file
522 \item Figure out how to configure your SCSI driver to keep track of the file
523 position during the MTEOM request. This is the preferred solution.
524 \item Modify the {\bf Device} resource of your {\bf bacula-sd.conf} file to
529 Hardware End of File = no
533 This will cause Bacula to use the MTFSF request to seek to the end of the
534 medium, and Bacula will keep track of the file number itself.
537 \label{IncorrectBlocks}
539 \subsubsection*{Incorrect Number of Blocks or Positioning Errors during btape
541 \index[general]{Testing!Incorrect Number of Blocks or Positioning Errors
543 \index[general]{Incorrect Number of Blocks or Positioning Errors during btape
545 \addcontentsline{toc}{subsubsection}{Incorrect Number of Blocks or Positioning
546 Errors during btape Testing}
548 {\bf Bacula's} preferred method of working with tape drives (sequential
549 devices) is to run in variable block mode, and this is what is set by default.
550 You should first ensure that your tape drive is set for variable block mode
553 If your tape drive is in fixed block mode and you have told Bacula to use
554 different fixed block sizes or variable block sizes (default), you will get
555 errors when Bacula attempts to forward space to the correct block (the kernel
556 driver's idea of tape blocks will not correspond to Bacula's).
558 All modern tape drives support variable tape blocks, but some older drives (in
559 particular the QIC drives) as well as the ATAPI ide-scsi driver run only in
560 fixed block mode. The Travan tape drives also apparently must run in fixed
561 block mode (to be confirmed).
563 Even in variable block mode, with the exception of the first record on the
564 second or subsequent volume of a multi-volume backup, Bacula will write blocks
565 of a fixed size. However, in reading a tape, Bacula will assume that for each
566 read request, exactly one block from the tape will be transferred. This the
567 most common way that tape drives work and is well supported by {\bf Bacula}.
569 Drives that run in fixed block mode can cause serious problems for Bacula if
570 the drive's block size does not correspond exactly to {\bf Bacula's} block
571 size. In fixed block size mode, drivers may transmit a partial block or
572 multiple blocks for a single read request. From {\bf Bacula's} point of view,
573 this destroys the concept of tape blocks. It is much better to run in variable
574 block mode, and almost all modern drives (the OnStream is an exception) run in
575 variable block mode. In order for Bacula to run in fixed block mode, you must
576 include the following records in the Storage daemon's Device resource
581 Minimum Block Size = nnn
582 Maximum Block Size = nnn
586 where {\bf nnn} must be the same for both records and must be identical to the
587 driver's fixed block size.
589 We recommend that you avoid this configuration if at all possible by using
590 variable block sizes.
592 If you must run with fixed size blocks, make sure they are not 512 bytes. This
593 is too small and the overhead that Bacula has with each record will become
594 excessive. If at all possible set any fixed block size to something like
595 64,512 bytes or possibly 32,768 if 64,512 is too large for your drive. See
596 below for the details on checking and setting the default drive block size.
598 To recover files from tapes written in fixed block mode, see below.
601 \subsubsection*{Ensuring that the Tape Modes Are Properly Set -- {\bf Linux
603 \index[general]{Ensuring that the Tape Modes Are Properly Set -- Linux Only}
604 \index[general]{Only!Ensuring that the Tape Modes Are Properly Set -- Linux}
605 \addcontentsline{toc}{subsubsection}{Ensuring that the Tape Modes Are Properly
608 If you have a modern SCSI tape drive and you are having problems with the {\bf
609 test} command as noted above, it may be that some program has set one or more
610 of your SCSI driver's options to non-default values. For example, if your
611 driver is set to work in SysV manner, Bacula will not work correctly because
612 it expects BSD behavior. To reset your tape drive to the default values, you
613 can try the following, but {\bf ONLY} if you have a SCSI tape drive on a {\bf
619 mt -f /dev/nst0 rewind
620 mt -f /dev/nst0 stoptions buffer-writes async-writes read-ahead
624 The above commands will clear all options and then set those specified. None
625 of the specified options are required by Bacula, but a number of other options
626 such as SysV behavior must not be set. Bacula does not support SysV tape
627 behavior. On systems other than Linux, you will need to consult your {\bf mt}
628 man pages or documentation to figure out how to do the same thing. This should
629 not really be necessary though -- for example, on both Linux and Solaris
630 systems, the default tape driver options are compatible with Bacula.
632 You may also want to ensure that no prior program has set the default block
633 size, as happened to one user, by explicitly turning it off with:
637 mt -f /dev/nst0 defblksize 0
641 If you would like to know what options you have set before making any of the
642 changes noted above, you can now view them on Linux systems, thanks to a tip
643 provided by Willem Riede. Do the following:
648 mt -f /dev/nst0 stsetoptions 0
649 grep st0 /var/log/messages
653 and you will get output that looks something like the following:
657 kernel: st0: Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
658 kernel: st0: can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0,
659 kernel: st0: defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 0
660 kernel: st0: sysv: 0 nowait: 0
664 Note, I have chopped off the beginning of the line with the date and machine
665 name for presentation purposes.
667 Some people find that the above settings only last until the next reboot, so
668 please check this otherwise you may have unexpected problems.
670 Beginning with Bacula version 1.35.8, if Bacula detects that you are running
671 in variable block mode, it will attempt to set your drive appropriately. All
672 OSes permit setting variable block mode, but some OSes do not permit setting
673 the other modes that Bacula needs to function properly.
676 \subsubsection*{Checking and Setting Tape Hardware Compression and Blocking
678 \index[general]{Checking and Setting Tape Hardware Compression and Blocking
680 \index[general]{Size!Checking and Setting Tape Hardware Compression and
682 \addcontentsline{toc}{subsubsection}{Checking and Setting Tape Hardware
683 Compression and Blocking Size}
685 As far as I can tell, there is no way with the {\bf mt} program to check if
686 your tape hardware compression is turned on or off. You can, however, turn it
687 on by using (on Linux):
692 mt -f /dev/nst0 defcompression 1
696 and of course, if you use a zero instead of the one at the end, you will turn
699 If you have built the {\bf mtx} program in the {\bf depkgs} package, you can
700 use tapeinfo to get quite a bit of information about your tape drive even if
701 it is not an autochanger. This program is called using the SCSI control
702 device. On Linux for tape drive /dev/nst0, this is usually /dev/sg0, while on
703 FreeBSD for /dev/nsa0, the control device is often /dev/pass2. For example on
704 my DDS-4 drive (/dev/nst0), I get the following:
709 Product Type: Tape Drive
711 Product ID: 'C5713A '
720 Medium Type: Not Loaded
726 where the {\bf DataCompEnabled: yes} means that tape hardware compression is
727 turned on. You can turn it on and off (yes|no) by using the {\bf mt}
728 commands given above. Also, this output will tell you if the {\bf BlockSize}
729 is non-zero and hence set for a particular block size. Bacula is not likely to
730 work in such a situation because it will normally attempt to write blocks of
731 64,512 bytes, except the last block of the job which will generally be
732 shorter. The first thing to try is setting the default block size to zero
733 using the {\bf mt \ -f \ /dev/nst0 \ defblksize \ 0} command as shown above.
734 On FreeBSD, this would be something like: {\bf mt \ -f \ /dev/nsa0 \ blocksize
737 On some operating systems with some tape drives, the amount of data that
738 can be written to the tape and whether or not compression is enabled is
739 determined by the density usually the {\bf mt \ -f \ /dev/nst0 setdensity xxx} command.
740 Often {\bf mt \ -f \ /dev/nst0 \ status} will print out the current
741 density code that is used with the drive. Most systems, but unfortunately
742 not all, set the density to the maximum by default. On some systems, you
743 can also get a list of all available density codes with:
744 {\bf mt \ -f \ /dev/nst0 \ densities} or a similar {\bf mt} command.
745 Note, for DLT and SDLT devices, no-compression versus compression is very
746 often controlled by the density code. On FreeBSD systems, the compression
747 mode is set using {\bf mt \ -f \ /dev/nsa0 \ comp xxx} where xxx is the
748 mode you want. In general, see {\bf man mt} for the options available on
752 If your tape drive requires fixed block sizes (very unusual), you can use the
757 Minimum Block Size = nnn
758 Maximum Block Size = nnn
762 in your Storage daemon's Device resource to force Bacula to write fixed size
763 blocks (where you sent nnn to be the same for both of the above records). This
764 should be done only if your drive does not support variable block sizes, or
765 you have some other strong reasons for using fixed block sizes. As mentioned
766 above, a small fixed block size of 512 or 1024 bytes will be very inefficient.
767 Try to set any fixed block size to something like 64,512 bytes or larger if
768 your drive will support it.
770 Also, note that the {\bf Medium Type} field of the output of {\bf tapeinfo}
771 reports {\bf Not Loaded}, which is not correct. As a consequence, you should
772 ignore that field as well as the {\bf Attached Changer} field.
774 To recover files from tapes written in fixed block mode, see below.
777 \subsubsection*{Tape Modes on FreeBSD}
778 \index[general]{FreeBSD!Tape Modes on}
779 \index[general]{Tape Modes on FreeBSD}
780 \addcontentsline{toc}{subsubsection}{Tape Modes on FreeBSD}
782 On most FreeBSD systems such as 4.9 and most tape drives, Bacula should run
787 mt \ -f \ /dev/nsa0 \ seteotmodel \ 2
788 mt \ -f \ /dev/nsa0 \ blocksize \ 0
789 mt \ -f \ /dev/nsa0 \ comp \ enable
793 You might want to put those commands in a startup script to make sure your
794 tape driver is properly initialized before running Bacula.
796 Then according to what the {\bf btape test} command returns, you will probably
797 need to set the following (see below for an alternative):
801 Hardware End of Medium = no
803 Backward Space Record = no
804 Backward Space File = no
805 Fast Forward Space File = no
810 Then be sure to run some append tests with Bacula where you start and stop
811 Bacula between appending to the tape, or use {\bf btape} version 1.35.1 or
812 greater, which includes simulation of stopping/restarting Bacula.
814 Please see the file {\bf platforms/freebsd/pthreads-fix.txt} in the main
815 Bacula directory concerning {\bf important} information concerning
816 compatibility of Bacula and your system. A much more optimal Device
817 configuration is shown below, but does not work with all tape drives. Please
818 test carefully before putting either into production.
820 Note, for FreeBSD 4.10-RELEASE, using a Sony TSL11000 L100 DDS4 with an
821 autochanger set to variable block size and DCLZ compression, Brian McDonald
822 reports that to get Bacula to append correctly between Bacula executions,
823 the correct values to use are:
827 mt \ -f \ /dev/nsa0 \ seteotmodel \ 1
828 mt \ -f \ /dev/nsa0 \ blocksize \ 0
829 mt \ -f \ /dev/nsa0 \ comp \ enable
837 Hardware End of Medium = no
839 Backward Space Record = no
840 Backward Space File = no
841 Fast Forward Space File = yes
846 This has been confirmed by several other people using different hardware. This
847 configuration is the preferred one because it uses one EOF and no backspacing
848 at the end of the tape, which works much more efficiently and reliably with
851 Finally, here is a Device configuration that Danny Butroyd reports to work
852 correctly with the Overland Powerloader tape library using LT0-2 and
857 # Overland Powerloader LT02 - 17 slots single drive
861 Archive Device = /dev/nsa0
862 AutomaticMount = yes;
864 RemovableMedia = yes;
866 Changer Command = "/usr/local/sbin/mtx-changer %c %o %S %a %d"
867 Changer Device = /dev/pass2
869 Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
871 # FreeBSD Specific Settings
872 Offline On Unmount = no
873 Hardware End of Medium = no
875 Backward Space Record = no
876 Fast Forward Space File = no
883 \subsubsection*{Determining What Tape Drives and Autochangers You Have on
885 \index[general]{FreeBSD!Determining What Tape Drives and Autochangers You Have
887 \index[general]{Determining What Tape Drives and Autochangers You Have on
889 \addcontentsline{toc}{subsubsection}{Determining What Tape Drives and
890 Autochangers You Have on FreeBSD}
892 On FreeBSD, you can do a {\bf camcontrol devlist} as root to determine what
893 drives and autochangers you have. For example,
897 undef# camcontrol devlist
898 at scbus0 target 2 lun 0 (pass0,sa0)
899 at scbus0 target 4 lun 0 (pass1,sa1)
900 at scbus0 target 4 lun 1 (pass2)
904 from the above, you can determine that there is a tape drive on {\bf /dev/sa0}
905 and another on {\bf /dev/sa1} in addition since there is a second line for the
906 drive on {\bf /dev/sa1}, you know can assume that it is the control device for
907 the autochanger (i.e. {\bf /dev/pass2}). It is also the control device name to
908 use when invoking the tapeinfo program. E.g.
912 tapeinfo -f /dev/pass2
918 \subsubsection*{Using the OnStream driver on Linux Systems}
919 \index[general]{Using the OnStream driver on Linux Systems}
920 \index[general]{Systems!Using the OnStream driver on Linux}
921 \addcontentsline{toc}{subsubsection}{Using the OnStream driver on Linux
924 Bacula version 1.33 (not 1.32x) is now working and ready for testing with the
925 OnStream kernel osst driver version 0.9.14 or above. Osst is available from:
926 \elink{http://sourceforge.net/projects/osst/}
927 {http://sourceforge.net/projects/osst/}.
929 To make Bacula work you must first load the new driver then, as root, do:
933 mt -f /dev/nosst0 defblksize 32768
937 Also you must add the following to your Device resource in your Storage
942 Minimum Block Size = 32768
943 Maximum Block Size = 32768
947 Here is a Device specification provided by Michel Meyers that is known to
953 Name = "Onstream DI-30"
954 Media Type = "ADR-30"
955 Archive Device = /dev/nosst0
956 Minimum Block Size = 32768
957 Maximum Block Size = 32768
958 Hardware End of Medium = yes
960 Backward Space File = yes
961 Fast Forward Space File = yes
965 Removable Media = yes
970 \subsection*{Hardware Compresson on EXB-8900}
971 \index[general]{Hardware Compression on EXB-8900}
972 \index[general]{EXB-8900!Hardware Compression}
973 \addcontentsline{to}{subsection}{Hardware Compression on EXB-8900}
974 To active, check, or disable the hardware compression feature
975 on an EXB-8900, use the exabyte MammothTool. You can get it here:
976 \elink{http://www.exabyte.com/support/online/downloads/index.cfm}
977 {http://www.exabyte.com/support/online/downloads/index.cfm}.
978 There is a solaris version of this tool. With option -C 0 or 1 you
979 can disable or activate compression. Start this tool without any
980 options for a small reference.
983 \subsubsection*{Using btape to Simulate Filling a Tape}
984 \index[general]{Using btape to Simulate Filling a Tape}
985 \index[general]{Tape!Using btape to Simulate Filling a}
986 \addcontentsline{toc}{subsubsection}{Using btape to Simulate Filling a
989 Because there are often problems with certain tape drives or systems when end
990 of tape conditions occur, {\bf btape} has a special command {\bf fill} that
991 causes it to write random data to a tape until the tape fills. It then writes
992 at least one more Bacula block to a second tape. Finally, it reads back both
993 tapes to ensure that the data has been written in a way that Bacula can
994 recover it. Note, there is also a single tape option as noted below, which you
995 should use rather than the two tape test. See below for more details.
997 This can be an extremely time consuming process (here it is about 6 hours) to
998 fill a full tape. Note, that btape writes random data to the tape when it is
999 filling it. This has two consequences: 1. it takes a bit longer to generate
1000 the data, especially on slow CPUs. 2. the total amount of data is
1001 approximately the real physical capacity of your tape, regardless of whether
1002 or not the tape drive compression is on or off. This is because random data
1003 does not compress very much.
1005 To begin this test, you enter the {\bf fill} command and follow the
1006 instructions. There are two options: the simple single tape option and the
1007 multiple tape option. Please use only the simple single tape option because
1008 the multiple tape option still doesn't work totally correctly. If the single
1009 tape option does not succeed, you should correct the problem before using
1011 \label{RecoveringFiles}
1013 \subsection*{Recovering Files Written to Tape With Fixed Block Sizes}
1014 \index[general]{Recovering Files Written to Tape With Fixed Block Sizes}
1015 \index[general]{Sizes!Recovering Files Written to Tape With Fixed Block}
1016 \addcontentsline{toc}{subsection}{Recovering Files Written to Tape With Fixed
1019 If you have been previously running your tape drive in fixed block mode
1020 (default 512) and Bacula with variable blocks (default), then in version
1021 1.32f-x and 1.34 and above, Bacula will fail to recover files because it does
1022 block spacing, and because the block sizes don't agree between your tape drive
1023 and Bacula it will not work.
1025 The long term solution is to run your drive in variable block mode as
1026 described above. However, if you have written tapes using fixed block sizes,
1027 this can be a bit of a pain. The solution to the problem is: while you are
1028 doing a restore command using a tape written in fixed block size, ensure that
1029 your drive is set to the fixed block size used while the tape was written.
1030 Then when doing the {\bf restore} command in the Console program, do not
1031 answer the prompt {\bf yes/mod/no}. Instead, edit the bootstrap file (the
1032 location is listed in the prompt) using any ASCII editor. Remove all {\bf
1033 VolBlock} lines in the file. When the file is re-written, answer the question,
1034 and Bacula will run without using block positioning, and it should recover
1038 \subsection*{Tape Blocking Modes}
1039 \index[general]{Modes!Tape Blocking}
1040 \index[general]{Tape Blocking Modes}
1041 \addcontentsline{toc}{subsection}{Tape Blocking Modes}
1043 SCSI tapes may either be written in {\bf variable} or {\bf fixed} block sizes.
1044 Newer drives support both modes, but some drives such as the QIC devices
1045 always use fixed block sizes. Bacula attempts to fill and write complete
1046 blocks (default 65K), so that in normal mode (variable block size), Bacula
1047 will always write blocks of the same size except the last block of a Job. If
1048 Bacula is configured to write fixed block sizes, it will pad the last block of
1049 the Job to the correct size. Bacula expects variable tape block size drives to
1050 behave as follows: Each write to the drive results in a single record being
1051 written to the tape. Each read returns a single record. If you request less
1052 bytes than are in the record, only those number of bytes will be returned, but
1053 the entire logical record will have been read (the next read will retrieve the
1054 next record). Thus data from a single write is always returned in a single
1055 read, and sequentially written records are returned by sequential reads.
1057 Bacula expects fixed block size tape drives to behave as follows: If a write
1058 length is greater than the physical block size of the drive, the write will be
1059 written as two blocks each of the fixed physical size. This single write may
1060 become multiple physical records on the tape. (This is not a good situation).
1061 According to the documentation, one may never write an amount of data that is
1062 not the exact multiple of the blocksize (it is not specified if an error
1063 occurs or if the the last record is padded). When reading, it is my
1064 understanding that each read request reads one physical record from the tape.
1065 Due to the complications of fixed block size tape drives, you should avoid
1066 them if possible with Bacula, or you must be ABSOLUTELY certain that you use
1067 fixed block sizes within Bacula that correspond to the physical block size of
1068 the tape drive. This will ensure that Bacula has a one to one correspondence
1069 between what it writes and the physical record on the tape.
1071 Please note that Bacula will not function correctly if it writes a block and
1072 that block is split into two or more physical records on the tape. Bacula
1073 assumes that each write causes a single record to be written, and that it can
1074 sequentially recover each of the blocks it has written by using the same
1075 number of sequential reads as it had written.
1077 \subsection*{Details of Tape Modes}
1078 \index[general]{Modes!Details}
1079 \index[general]{Details of Tape Modes}
1080 \addcontentsline{toc}{subsection}{Details of Tape Modes}
1081 Rudolf Cejka has provided the following information concerning
1082 certain tape modes and MTEOM.
1086 It is always possible to position filemarks or blocks, whereas
1087 positioning to the end-of-data is only optional feature, however it is
1088 implemented very often. SCSI specification also talks about optional
1089 sequential filemarks, setmarks and sequential setmarks, but these are not
1090 implemented so often. Modern tape drives keep track of file positions in
1091 built-in chip (AIT, LTO) or at the beginning of the tape (SDLT), so there
1092 is not any speed difference, if end-of-data or filemarks is used (I have
1093 heard, that LTO-1 from all 3 manufacturers do not use its chip for file
1094 locations, but a tape as in SDLT case, and I'm not sure about LTO-2 and
1095 LTO-3 case). However there is a big difference, that end-of-data ignores
1096 file position, whereas filemarks returns the real number of skipped
1097 files, so OS can track current file number just in filemarks case.
1100 Solaris does use just SCSI SPACE Filemarks, it does not support SCSI
1101 SPACE End-of-data. When MTEOM is called, Solaris does use SCSI SPACE
1102 Filemarks with count = 1048576 for fast mode, and combination of SCSI
1103 SPACE Filemarks with count = 1 with SCSI SPACE Blocks with count = 1 for
1104 slow mode, so EOD mark on the tape on some older tape drives is not
1105 skipped. File number is always tracked for MTEOM.
1107 Linux does support both SCSI SPACE Filemarks and End-of-data: When MTEOM
1108 is called in MT_ST_FAST_MTEOM mode, SCSI SPACE Filemarks with count =
1109 8388607 is used. In the other case, SCSI SPACE End-of-data is used.
1110 There is no real slow mode like in Solaris - I just expect, that for
1111 older tape drives Filemarks may be slower than End-of-data, but not so
1112 much as in Solaris slow mode. File number is tracked for MTEOM just
1113 without MT_ST_FAST_MTEOM - when MT_ST_FAST_MTEOM is used, it is not.
1115 FreeBSD does support both SCSI SPACE Filemarks and End-of-data, but when
1116 MTEOD (MTEOM) is called, SCSI SPACE End-of-data is always used. FreeBSD
1117 never use SCSI SPACE Filemarks for MTEOD. File number is never tracked
1121 When {\bf Hardware End of Medium = Yes} is used, MTEOM is called, but it
1122 does not mean, that hardware End-of-data must be used. When Hardware End
1123 of Medium = No, if Fast Forward Space File = Yes, MTFSF with count =
1124 32767 is used, else Block Read with count = 1 with Forward Space File
1125 with count = 1 is used, which is really very slow.
1127 \item [Hardware End of Medium = Yes|No]
1128 The name of this option is misleading and is the source of confusion,
1129 because it is not the hardware EOM, what is really switched here.
1131 If I use Yes, OS must not use SCSI SPACE End-of-data, because Bacula
1132 expects, that there is tracked file number, which is not supported by
1133 SCSI specification. Instead, the OS have to use SCSI SPACE Filemarks.
1135 If I use No, an action depends on Fast Forward Space File.
1137 Considering {\bf Hardware End of Medium = no}
1138 and {\bf Fast Forward Space File = no}
1139 When I set the two to no, file positioning was very slow
1142 HEOM = no, FFSF = no: ~ 10 - 100 minutes
1145 while even with {\bf Hardware End of Medium = no} but
1146 {\bf Fast Forward Space File = yes}, the time is 10 to
1149 HEOM = no, FFSF = yes: ~ 1 minute
1154 \subsection*{Autochanger Errors}
1155 \index[general]{Errors!Autochanger}
1156 \index[general]{Autochanger Errors}
1157 \addcontentsline{toc}{subsection}{Autochanger Errors}
1159 If you are getting errors such as:
1163 3992 Bad autochanger "load slot 1, drive 1": ERR=Child exited with code 1.
1167 and you are running your Storage daemon as non-root, then most likely
1168 you are having permissions problems with the control channel. Running
1169 as root, set permissions on /dev/sgX so that the userid and group of
1170 your Storage daemon can access the device. You need to ensure that you
1171 all access to the proper control device, and if you don't have any
1172 SCSI disk drives (including SATA drives), you might want to change
1173 the permissions on /dev/sg*.