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.
55 \item Run the btape {\bf fill} command, preferrably with two volumes. This
56 can take a long time. If you have an autochanger and it is configured, Bacula
57 will automatically use it. If you do not have it configured, you can manual
58 issue the appopriate {\bf mtx} command, or press the autochanger buttons to
59 change the tape when requested to do so.
60 \item FreeBSD users, run the {\bf tapetest} program, and make sure your
61 system is patched if necessary. See below for more details.
62 \item Run Bacula, and backup a reasonably small directory, say 60 Megabytes.
63 Do three successive backups of this directory.
64 \item Stop Bacula, then restart it. Do another full backup of the same
65 directory. Then stop and restart Bacula.
66 \item Do a restore of the directory backed up, by entering the following
67 restore command, being careful to restore it to an alternate location:
71 restore select all done
77 Do a {\bf diff} on the restored directory to ensure it is identical to the
79 \item If you have an autochanger, you should now go back to the btape program
80 and run the autochanger test:
84 ./btape -c bacula-sd.conf /dev/nst0
90 Adjust your autochanger as necessary to ensure that it works correctly. See
91 the Autochanger chapter of this manual for a complete discussion of testing
95 If you have reached this point, you stand a good chance of having everything
96 work. If you get into trouble at any point, {\bf carefully} read the
97 documentation given below. If you cannot get past some point, ask the {\bf
98 bacula-users} email list, but specify which of the steps you have successfully
99 completed. In particular, you may want to look at the
100 \ilink{ Tips for Resolving Problems}{problems1} section below.
102 \subsubsection*{Specifying the Configuration File}
103 \index[general]{File!Specifying the Configuration }
104 \index[general]{Specifying the Configuration File }
105 \addcontentsline{toc}{subsubsection}{Specifying the Configuration File}
107 Starting with version 1.27, each of the tape utility programs including the
108 {\bf btape} program requires a valid Storage daemon configuration file
109 (actually, the only part of the configuration file that {\bf btape} needs is
110 the {\bf Device} resource definitions). This permits {\bf btape} to find the
111 configuration parameters for your archive device (generally a tape drive).
112 Without those parameters, the testing and utility programs do not no how to
113 properly read and write your drive. By default, they use {\bf bacula-sd.conf}
114 in the current directory, but you may specify a different configuration file
115 using the {\bf -c} option.
117 \subsubsection*{Specifying a Device Name For a Tape}
118 \index[general]{Tape!Specifying a Device Name For a }
119 \index[general]{Specifying a Device Name For a Tape }
120 \addcontentsline{toc}{subsubsection}{Specifying a Device Name For a Tape}
122 {\bf btape} {\bf device-name} where the Volume can be found. In the case of a
123 tape, this is the physical device name such as {\bf /dev/nst0} or {\bf
124 /dev/rmt/0ubn} depending on your system that you specify on the Archive Device
125 directive. For the program to work, it must find the identical name in the
126 Device resource of the configuration file. If the name is not found in the
127 list of phsical names, the utility program will compare the name you entered
128 to the Device names (rather than the Archive device names). See below for
129 specifying Volume names.
131 \subsubsection*{Specifying a Device Name For a File}
132 \index[general]{File!Specifying a Device Name For a }
133 \index[general]{Specifying a Device Name For a File }
134 \addcontentsline{toc}{subsubsection}{Specifying a Device Name For a File}
136 If you are attempting to read or write an archive file rather than a tape, the
137 {\bf device-name} should be the full path to the archive location including
138 the filename. The filename (last part of the specification) will be stripped
139 and used as the Volume name, and the path (first part before the filename)
140 must have the same entry in the configuration file. So, the path is equivalent
141 to the archive device name, and the filename is equivalent to the volume name.
146 \index[general]{Btape }
147 \addcontentsline{toc}{subsection}{btape}
149 This program permits a number of elementary tape operations via a tty command
150 interface. The {\bf test} command, described below, can be very useful for
151 testing tape drive compatibility problems. Aside from initial testing of tape
152 drive compatibility with {\bf Bacula}, {\bf btape} will be mostly used by
153 developers writing new tape drivers.
155 {\bf btape} can be dangerous to use with existing {\bf Bacula} tapes because
156 it will relabel a tape or write on the tape if so requested regardless of
157 whether or not the tape contains valuable data, so please be careful and use
158 it only on blank tapes.
160 To work properly, {\bf btape} needs to read the Storage daemon's configuration
161 file. As a default, it will look for {\bf bacula-sd.conf} in the current
162 directory. If your configuration file is elsewhere, please use the {\bf -c}
163 option to specify where.
165 The physical device name or the Device resource name must be specified on the
166 command line, and that this same device name must be present in the Storage
167 daemon's configuration file read by {\bf btape}
171 Usage: btape [options] device_name
172 -b <file> specify bootstrap file
173 -c <file> set configuration file to file
174 -d <nn> set debug level to nn
177 -? print this message.
181 \subsubsection*{Using btape to Verify your Tape Drive}
182 \index[general]{Using btape to Verify your Tape Drive }
183 \index[general]{Drive!Using btape to Verify your Tape }
184 \addcontentsline{toc}{subsubsection}{Using btape to Verify your Tape Drive}
186 An important reason for this program is to ensure that a Storage daemon
187 configuration file is defined so that Bacula will correctly read and write
190 It is highly recommended that you run the {\bf test} command before running
191 your first Bacula job to ensure that the parameters you have defined for your
192 storage device (tape drive) will permit {\bf Bacula} to function properly. You
193 only need to mount a blank tape, enter the command, and the output should be
194 reasonably self explanatory. For example:
198 (ensure that Bacula is not running)
199 ./btape -c /usr/bin/bacula/bacula-sd.conf /dev/nst0
207 Tape block granularity is 1024 bytes.
208 btape: btape.c:376 Using device: /dev/nst0
213 Enter the test command:
221 The output produced should be something similar to the following: I've cut the
222 listing short because it is frequently updated to have new tests.
226 === Append files test ===
227 This test is essential to Bacula.
228 I'm going to write one record in file 0,
229 two records in file 1,
230 and three records in file 2
231 btape: btape.c:387 Rewound /dev/nst0
232 btape: btape.c:855 Wrote one record of 64412 bytes.
233 btape: btape.c:857 Wrote block to device.
234 btape: btape.c:410 Wrote EOF to /dev/nst0
235 btape: btape.c:855 Wrote one record of 64412 bytes.
236 btape: btape.c:857 Wrote block to device.
237 btape: btape.c:855 Wrote one record of 64412 bytes.
238 btape: btape.c:857 Wrote block to device.
239 btape: btape.c:410 Wrote EOF to /dev/nst0
240 btape: btape.c:855 Wrote one record of 64412 bytes.
241 btape: btape.c:857 Wrote block to device.
242 btape: btape.c:855 Wrote one record of 64412 bytes.
243 btape: btape.c:857 Wrote block to device.
244 btape: btape.c:855 Wrote one record of 64412 bytes.
245 btape: btape.c:857 Wrote block to device.
246 btape: btape.c:410 Wrote EOF to /dev/nst0
247 btape: btape.c:387 Rewound /dev/nst0
248 btape: btape.c:693 Now moving to end of media.
249 btape: btape.c:427 Moved to end of media
250 We should be in file 3. I am at file 3. This is correct!
251 Now the important part, I am going to attempt to append to the tape.
253 === End Append files test ===
257 If you do not successfully complete the above test, please resolve the
258 problem(s) before attempting to use {\bf Bacula}. Depending on your tape
259 drive, the test may recommend that you add certain records to your
260 configuration. We strongly recommend that you do so and then re-run the above
261 test to insure it works the first time.
263 Some of the suggestions it provides for resolving the problems may or may not
264 be useful. If at all possible avoid using fixed blocking. If the test suddenly
265 starts to print a long series of:
275 then almost certainly, you are running your drive in fixed block mode rather
276 than variable block mode. Please see below for help on resolving that.
278 For FreeBSD users, please see the notes below for doing further testing of
281 \subsubsection*{Linux SCSI Tricks}
282 \index[general]{Tricks!Linux SCSI }
283 \index[general]{Linux SCSI Tricks }
284 \addcontentsline{toc}{subsubsection}{Linux SCSI Tricks}
286 You can find out what SCSI devices you have by doing:
294 For example, I get the following:
299 Host: scsi2 Channel: 00 Id: 01 Lun: 00
300 Vendor: HP Model: C5713A Rev: H107
301 Type: Sequential-Access ANSI SCSI revision: 02
302 Host: scsi2 Channel: 00 Id: 04 Lun: 00
303 Vendor: SONY Model: SDT-10000 Rev: 0110
304 Type: Sequential-Access ANSI SCSI revision: 02
308 If you want to remove the SDT-10000 device, you can do so as root with:
312 echo "scsi remove-single-device 2 0 4 0">/proc/scsi/scsi
316 and you can put add it back with:
320 echo "scsi add-single-device 2 0 4 0">/proc/scsi/scsi
324 where the 2 0 4 0 are the Host, Channel, Id, and Lun as seen on the output
325 from {\bf cat /proc/scsi/scsi}. Note, the Channel must be specified as
329 \subsection*{Tips for Resolving Problems}
330 \index[general]{Problems!Tips for Resolving }
331 \index[general]{Tips for Resolving Problems }
332 \addcontentsline{toc}{subsection}{Tips for Resolving Problems}
334 \label{CannotRestore}
336 \subsubsection*{Bacula Saves But Cannot Restore Files}
337 \index[general]{Files!Bacula Saves But Cannot Restore }
338 \index[general]{Bacula Saves But Cannot Restore Files }
339 \addcontentsline{toc}{subsubsection}{Bacula Saves But Cannot Restore Files}
341 If you are getting error messages such as:
345 Volume data error at 0:1! Wanted block-id: "BB02", got "". Buffer discarded
349 It is very likely that Bacula has tried to do block positioning and ended up
350 at an invalid block. This can happen if your tape drive is in fixed block mode
351 while Bacula's default is variable blocks. Note that in such cases, Bacula is
352 perfectly able to write to your Volumes (tapes), but cannot position to read
355 There are two possible solutions.
358 \item The first and best is to always ensure that your drive is in variable
359 block mode. Note, it can switch back to fixed block mode on a reboot or if
360 another program uses the drive. So on such systems you need to modify the
361 Bacula startup files to explicitly set:
365 mt -f /dev/nst0 defblksize 0
369 or whatever is appropriate on your system.
370 \item The second possibility, especially, if Bacula wrote while the drive was
371 in fixed block mode, is to turn off block positioning in Bacula. This is done
376 Block Positioning = no
380 to the Device resource. This is not the recommended procedure because it can
381 enormously slow down recovery of files, but it may help where all else
382 fails. This directive is available in version 1.35.5 or later (and not yet
388 \subsubsection*{Bacula Cannot Open the Device}
389 \index[general]{Device!Bacula Cannot Open the }
390 \index[general]{Bacula Cannot Open the Device }
391 \addcontentsline{toc}{subsubsection}{Bacula Cannot Open the Device}
393 If you get an error message such as:
397 dev open failed: dev.c:265 stored: unable to open
398 device /dev/nst0:> ERR=No such device or address
402 the first time you run a job, it is most likely due to the fact that you
403 specified the incorrect device name on your {\bf Archive Device}.
405 If Bacula works fine with your drive, then all off a sudden you get error
406 messages similar to the one shown above, it is quite possible that your driver
407 module is being removed because the kernel deems it idle. This is done via
408 {\bf crontab} with the use of {\bf rmmod -a}. To fix the problem, you can
409 remove this entry from {\bf crontab}, or you can manually {\bf modprob} your
410 driver module (or add it to the local startup script). Thanks to Alan Brown
412 \label{IncorrectFiles}
414 \subsubsection*{Incorrect File Number}
415 \index[general]{Number!Incorrect File }
416 \index[general]{Incorrect File Number }
417 \addcontentsline{toc}{subsubsection}{Incorrect File Number}
419 When Bacula moves to the end of the medium, it normally uses the {\bf
420 ioctl(MTEOM)} function. Then Bacula uses the {\bf ioctl(MTIOCGET)} function to
421 retrieve the current file position from the {\bf mt\_fileno} field. Some SCSI
422 tape drivers will use a fast means of seeking to the end of the medium and in
423 doing so, they will not know the current file position and hence return a {\bf
424 -1}. As a consequence, if you get {\bf ``This is NOT correct!''} in the
425 positioning tests, this may be the cause. You must correct this condition in
426 order for Bacula to work.
428 There are two possible solutions to the above problem of incorrect file
432 \item Figure out how to configure your SCSI driver to keep track of the file
433 position during the MTEOM request. This is the preferred solution.
434 \item Modify the {\bf Device} resource of your {\bf bacula-sd.conf} file to
439 Hardware End of File = no
443 This will cause Bacula to use the MTFSF request to seek to the end of the
444 medium, and Bacula will keep track of the file number itself.
447 \label{IncorrectBlocks}
449 \subsubsection*{Incorrect Number of Blocks or Positioning Errors during btape
451 \index[general]{Testing!Incorrect Number of Blocks or Positioning Errors
453 \index[general]{Incorrect Number of Blocks or Positioning Errors during btape
455 \addcontentsline{toc}{subsubsection}{Incorrect Number of Blocks or Positioning
456 Errors during btape Testing}
458 {\bf Bacula's} preferred method of working with tape drives (sequential
459 devices) is to run in variable block mode, and this is what is set by default.
460 You should first ensure that your tape drive is set for variable block mode
463 If your tape drive is in fixed block mode and you have told Bacula to use
464 different fixed block sizes or variable block sizes (default), you will get
465 errors when Bacula attempts to forward space to the correct block (the kernel
466 driver's idea of tape blocks will not correspond to Bacula's).
468 All modern tape drives support variable tape blocks, but some older drives (in
469 particular the QIC drives) as well as the ATAPI ide-scsi driver run only in
470 fixed block mode. The Travan tape drives also apparently must run in fixed
471 block mode (to be confirmed).
473 Even in variable block mode, with the exception of the first record on the
474 second or subsequent volume of a multi-volume backup, Bacula will write blocks
475 of a fixed size. However, in reading a tape, Bacula will assume that for each
476 read request, exactly one block from the tape will be transferred. This the
477 most common way that tape drives work and is well supported by {\bf Bacula}.
479 Drives that run in fixed block mode can cause serious problems for Bacula if
480 the drive's block size does not correspond exactly to {\bf Bacula's} block
481 size. In fixed block size mode, drivers may transmit a partial block or
482 multiple blocks for a single read request. From {\bf Bacula's} point of view,
483 this destroys the concept of tape blocks. It is much better to run in variable
484 block mode, and almost all modern drives (the OnStream is an exception) run in
485 variable block mode. In order for Bacula to run in fixed block mode, you must
486 include the following records in the Storage daemon's Device resource
491 Minimum Block Size = nnn
492 Maximum Block Size = nnn
496 where {\bf nnn} must be the same for both records and must be identical to the
497 driver's fixed block size.
499 We recommend that you avoid this configuration if at all possible by using
500 variable block sizes.
502 If you must run with fixed size blocks, make sure they are not 512 bytes. This
503 is too small and the overhead that Bacula has with each record will become
504 excessive. If at all possible set any fixed block size to something like
505 64,512 bytes or possibly 32,768 if 64,512 is too large for your drive. See
506 below for the details on checking and setting the default drive block size.
508 To recover files from tapes written in fixed block mode, see below.
511 \subsubsection*{Ensuring that the Tape Modes Are Properly Set -- {\bf Linux
513 \index[general]{Ensuring that the Tape Modes Are Properly Set -- Linux Only }
514 \index[general]{Only!Ensuring that the Tape Modes Are Properly Set -- Linux }
515 \addcontentsline{toc}{subsubsection}{Ensuring that the Tape Modes Are Properly
518 If you have a modern SCSI tape drive and you are having problems with the {\bf
519 test} command as noted above, it may be that some program has set one or more
520 of the your SCSI driver's options to non-default values. For example, if your
521 driver is set to work in SysV manner, Bacula will not work correctly because
522 it expects BSD behavior. To reset your tape drive to the default values, you
523 can try the following, but {\bf ONLY} if you have a SCSI tape drive on a {\bf
529 mt -f /dev/nst0 rewind
530 mt -f /dev/nst0 stoptions buffer-writes async-writes read-ahead
534 The above commands will clear all options and then set those specified. None
535 of the specified options are required by Bacula, but a number of other options
536 such as SysV behavior must not be set. Bacula does not support SysV tape
537 behavior. On systems other than Linux, you will need to consult your {\bf mt}
538 man pages or documentation to figure out how to do the same thing. This should
539 not really be necessary though -- for example, on both Linux and Solaris
540 systems, the default tape driver options are compatible with Bacula.
542 You may also want to ensure that no prior program has set the default block
543 size, as happened to one user, by explicitly turning it off with:
547 mt -f /dev/nst0 defblksize 0
551 If you would like to know what stoptions you have set before making any of the
552 changes noted above, you can now view them on Linux systems, thanks to a tip
553 provided by Willem Riede. Do the following:
558 mt -f /dev/nst0 stsetoptions 0
559 grep st0 /var/log/messages
563 and you will get output that looks something like the following:
567 kernel: st0: Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
568 kernel: st0: can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0,
569 kernel: st0: defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 0
570 kernel: st0: sysv: 0 nowait: 0
574 Note, I have chopped off the beginning of the line with the date and machine
575 name for presentation purposes.
577 Some people find that the above settings only last until the next reboot, so
578 please check this otherwise you may have unexpected problems.
580 Beginning with Bacula version 1.35.8, if Bacula detects that you are running
581 in variable block mode, it will attempt to set your drive appropriately. All
582 OSes permit setting variable block mode, but some OSes do not permit setting
583 the other modes that Bacula needs to function properly.
586 \subsubsection*{Checking and Setting Tape Hardware Compression and Blocking
588 \index[general]{Checking and Setting Tape Hardware Compression and Blocking
590 \index[general]{Size!Checking and Setting Tape Hardware Compression and
592 \addcontentsline{toc}{subsubsection}{Checking and Setting Tape Hardware
593 Compression and Blocking Size}
595 As far as I can tell, there is no way with the {\bf mt} program to check if
596 your tape hardware compression is turned on or off. You can, however, turn it
597 on by using (on Linux):
602 mt -f /dev/nst0 defcompression 1
606 and of course, if you use a zero instead of the one at the end, you will turn
609 You may also want to ensure that no prior program has set the default block
610 size, as happened to one user, by explicitly turning it off with:
614 mt -f /dev/nst0 defblksize 0
618 If you have built the {\bf mtx} program in the {\bf depkgs} package, you can
619 use tapeinfo to get quite a bit of information about your tape drive even if
620 it is not an autochanger. This program is called using the SCSI control
621 device. On Linux for tape drive /dev/nst0, this is usually /dev/sg0, while on
622 FreeBSD for /dev/nsa0, the control device is often /dev/pass2. For example on
623 my DDS-4 drive (/dev/nst0), I get the following:
628 Product Type: Tape Drive
630 Product ID: 'C5713A '
639 Medium Type: Not Loaded
645 where the {\bf DataCompEnabled: yes} means that tape hardware compression is
646 turned on. You can see it turn on and off (yes|no) by using the {\bf mt}
647 commands given above. Also, this output will tell you if the {\bf BlockSize}
648 is non-zero and hence set for a particular block size. Bacula is not likely to
649 work in such a situation because it will normally attempt to write blocks of
650 64,512 bytes, except the last block of the job which will generally be
651 shorter. The first thing to try is setting the default block size to zero
652 using the {\bf mt \ -f \ /dev/nst0 \ defblksize \ 0} command as shown above.
653 On FreeBSD, this would be something like: {\bf mt \ -f \ /dev/nsa0 \ blocksize
656 If your tape drive requires fixed block sizes (very unusual), you can use the
661 Minimum Block Size = nnn
662 Maximum Block Size = nnn
666 in your Storage daemon's Device resource to force Bacula to write fixed size
667 blocks (where you sent nnn to be the same for both of the above records). This
668 should be done only if your drive does not support variable block sizes, or
669 you have some other strong reasons for using fixed block sizes. As mentioned
670 above, a small fixed block size of 512 or 1024 bytes will be very inefficient.
671 Try to set any fixed block size to something like 64,512 bytes or larger if
672 your drive will support it.
674 Also, note that the {\bf Medium Type} field of the output of {\bf tapeinfo}
675 reports {\bf Not Loaded}, which is not correct. As a consequence, you should
676 ignore that field as well as the {\bf Attached Changer} field.
678 To recover files from tapes written in fixed block mode, see below.
681 \subsubsection*{Tape Modes on FreeBSD}
682 \index[general]{FreeBSD!Tape Modes on }
683 \index[general]{Tape Modes on FreeBSD }
684 \addcontentsline{toc}{subsubsection}{Tape Modes on FreeBSD}
686 On most FreeBSD systems such as 4.9 and most tape drives, Bacula should run
691 mt \ -f \ /dev/nsa0 \ seteotmodel \ 2
692 mt \ -f \ /dev/nsa0 \ blocksize \ 0
693 mt \ -f \ /dev/nsa0 \ comp \ enable
697 You might want to put those commands in a startup script to make sure your
698 tape driver is properly initialized before running Bacula.
700 Then according to what the {\bf btape test} command returns, you will probably
701 need to set the following (see below for an alternative):
705 Hardware End of Medium = no
707 Backward Space Record = no
708 Backward Space File = no
709 Fast Forward Space File = no
714 Then be sure to run some append tests with Bacula where you start and stop
715 Bacula between appending to the tape, or use {\bf btape} version 1.35.1 or
716 greater, which includes simulation of stopping/restarting Bacula.
718 Please see the file {\bf platforms/freebsd/pthreads-fix.txt} in the main
719 Bacula directory concerning {\bf important} information concerning
720 compatibility of Bacula and your system. A much more optimal Device
721 configuration is shown below, but does not work with all tape drives. Please
722 test carefully before putting either into production.
724 Note, for FreeBSD 4.10-RELEASE, using a Sony TSL11000 L100 DDS4 w/Autochanger
725 set to variable block size and DCLZ compression, Brian McDonald reports that
726 to get Bacula to append correctly between Bacula executions, the correct
731 mt \ -f \ /dev/nsa0 \ seteotmodel \ 1
732 mt \ -f \ /dev/nsa0 \ blocksize \ 0
733 mt \ -f \ /dev/nsa0 \ comp \ enable
741 Hardware End of Medium = no
743 Backward Space Record = no
744 Backward Space File = no
745 Fast Forward Space File = yes
750 This has been confirmed by several other people using different hardware. This
751 configuration is the preferred one because it uses one EOF and no backspacing
752 at the end of the tape, which works much more efficiently and reliably with
755 \subsubsection*{Determining What Tape Drives and Autochangers You Have on
757 \index[general]{FreeBSD!Determining What Tape Drives and Autochangers You Have
759 \index[general]{Determining What Tape Drives and Autochangers You Have on
761 \addcontentsline{toc}{subsubsection}{Determining What Tape Drives and
762 Autochangers You Have on FreeBSD}
764 On FreeBSD, you can do a {\bf camcontrol devlist} as root to determine what
765 drives and autochangers you have. For example,
769 undef# camcontrol devlist
770 at scbus0 target 2 lun 0 (pass0,sa0)
771 at scbus0 target 4 lun 0 (pass1,sa1)
772 at scbus0 target 4 lun 1 (pass2)
776 from the above, you can determine that there is a tape drive on {\bf /dev/sa0}
777 and another on {\bf /dev/sa1} in addition since there is a second line for the
778 drive on {\bf /dev/sa1}, you know can assume that it is the control device for
779 the autochanger (i.e. {\bf /dev/pass2}). It is also the control device name to
780 use when invoking the tapeinfo program. E.g.
784 tapeinfo -f /dev/pass2
790 \subsubsection*{Using the OnStream driver on Linux Systems}
791 \index[general]{Using the OnStream driver on Linux Systems }
792 \index[general]{Systems!Using the OnStream driver on Linux }
793 \addcontentsline{toc}{subsubsection}{Using the OnStream driver on Linux
796 Bacula version 1.33 (not 1.32x) is now working and ready for testing with the
797 OnStream kernel osst driver version 0.9.14 or above. Osst is available from:
798 \elink{http://sourceforge.net/projects/osst/}{http://sourceforge.net/projects/%
801 To make Bacula work you must first load the new driver then, as root, do:
805 mt -f /dev/nosst0 defblksize 32768
809 Also you must add the following to your Device resource in your Storage
814 Minimum Block Size = 32768
815 Maximum Block Size = 32768
819 Here is a Device specification provided by Michel Meyers that is known to
825 Name = "Onstream DI-30"
826 Media Type = "ADR-30"
827 Archive Device = /dev/nosst0
828 Minimum Block Size = 32768
829 Maximum Block Size = 32768
830 Hardware End of Medium = yes
832 Backward Space File = yes
833 Fast Forward Space File = yes
837 Removable Media = yes
844 \subsubsection*{Using btape to Simulate Bacula Filling a Tape}
845 \index[general]{Using btape to Simulate Bacula Filling a Tape }
846 \index[general]{Tape!Using btape to Simulate Bacula Filling a }
847 \addcontentsline{toc}{subsubsection}{Using btape to Simulate Bacula Filling a
850 Because there are often problems with certain tape drives or systems when end
851 of tape conditions occur, {\bf btape} has a special command {\bf fill} that
852 causes it to write random data to a tape until the tape fills. It then writes
853 at least one more Bacula block to a second tape. Finally, it reads back both
854 tapes to ensure that the data has been written in a way that Bacula can
855 recover it. Note, there is also a single tape option as noted below, which you
856 should use rather than the two tape test. See below for more details.
858 This can be an extremely time consuming process (here is is about 6 hours) to
859 fill a full tape. Note, that btape writes random data to the tape when it is
860 filling it. This has two consequences: 1. it takes a bit longer to generate
861 the data, especially on slow CPUs. 2. the total amount of data is
862 approximately the real physical capacity of your tape, regardless of whether
863 or not the tape drive compression is on or off. This is because random data
864 does not compress very much.
866 To begin this test, you enter the {\bf fill} command and follow the
867 instructions. There are two options: the simple single tape option and the
868 multiple tape option. Please use only the simple single tape option because
869 the multiple tape option still doesn't work totally correctly. If the single
870 tape option does not succeed, you should correct the problem before using
872 \label{RecoveringFiles}
874 \subsection*{Recovering Files Written to Tape With Fixed Block Sizes}
875 \index[general]{Recovering Files Written to Tape With Fixed Block Sizes }
876 \index[general]{Sizes!Recovering Files Written to Tape With Fixed Block }
877 \addcontentsline{toc}{subsection}{Recovering Files Written to Tape With Fixed
880 If you have been previously running your tape drive in fixed block mode
881 (default 512) and Bacula with variable blocks (default), then in version
882 1.32f-x and 1.34 and above, Bacula will fail to recover files because it does
883 block spacing, and because the block sizes don't agree between your tape drive
884 and Bacula it will not work.
886 The long term solution is to run your drive in variable block mode as
887 described above. However, if you have written tapes using fixed block sizes,
888 this can be a bit of a pain. The solution to the problem is: while you are
889 doing a restore command using a tape written in fixed block size, ensure that
890 your drive is set to the fixed block size used while the tape was written.
891 Then when doing the {\bf restore} command in the Console program, do not
892 answer the prompt {\bf yes/mod/no}. Instead, edit the bootstrap file (the
893 location is listed in the prompt) using any ASCII editor. Remove all {\bf
894 VolBlock} lines in the file. When the file is re-written, answer the question,
895 and Bacula will run without using block positioning, and it should recover
899 \subsection*{Tape Blocking Modes}
900 \index[general]{Modes!Tape Blocking }
901 \index[general]{Tape Blocking Modes }
902 \addcontentsline{toc}{subsection}{Tape Blocking Modes}
904 SCSI tapes may either be written in {\bf variable} or {\bf fixed} block sizes.
905 Newer drives support both modes, but some drives such as the QIC devices
906 always use fixed block sizes. Bacula attempts to fill and write complete
907 blocks (default 65K), so that in normal mode (variable block size), Bacula
908 will always write blocks of the same size except the last block of a Job. If
909 Bacula is configured to write fixed block sizes, it will pad the last block of
910 the Job to the correct size. Bacula expects variable tape block size drives to
911 behave as follows: Each write to the drive results in a single record being
912 written to the tape. Each read returns a single record. If you request less
913 byte than are in the record, only those number of bytes will be returned, but
914 the entire logical record will have been read (the next read will retrieve the
915 next record). Thus data from a single write is always returned in a single
916 read, and sequentially written records are returned by sequential reads.
918 Bacula expects fixed block size tape drives to behave as follows: If a write
919 length is greater than the physical block size of the drive, the write will be
920 written as two blocks each of the fixed physical size. This a single write may
921 become multiple physical records on the tape. (This is not a good situation).
922 According to the documentation, one may never write an amount of data that is
923 not the exact multiple of the blocksize (it is not specified if an error
924 occurs or if the the last record is padded). When reading, it is my
925 understanding that each read request reads one physical record from the tape.
926 Due to the complications of fixed block size tape drives, you should avoid
927 them if possible with Bacula, or you must be ABSOLUTELY certain that you use
928 fixed block sizes within Bacula that correspond to the physical block size of
929 the tape drive. This will ensure that Bacula has a one to one correspondence
930 between what it writes and the physical record on the tape.
932 Please note that Bacula will not function correctly if it writes a block and
933 that block is split into two or more physical records on the tape. Bacula
934 assumes that each write causes a single record to be written, and that it can
935 sequentially recover each of the blocks it has written by using the same
936 number of sequential reads as it had written.