  
#include "bacula_template.inc" title="Tape Testing" num=18

<h1>Testing Your Tape Drive With Bacula</h1>
This chapter is concerned with testing and configuring
your tape drive to make sure that it will work properly
with Bacula using the <b>btape</b> program.

<a name="summary"></a>
<h2>Summary of Steps to Take to Get Your Tape Drive Working</h2>
In general, you should follow the following steps to get your
tape drive to work with Bacula.  Start with a tape mounted
in your drive.  If you have an autochanger, load a tape
into the drive. We use <b>/dev/nst0</b> as the tape drive
name, you will need to adapt it according to your system.
<p>
Do not proceed to the next item until you have succeeded
with the previous one.
<ol>
 <li>Use tar to write to, then read from your drive:
   <pre>
   mt -f /dev/nst0 rewind
   tar cvf /dev/nst0 .
   mt -f /dev/nst0 rewind
   tar tvf /dev/nst0 
   </pre>
   </li>
 <li>Make sure you have a valid and correct Device resource
     corresponding to your drive. For Linux users, generally,
     the default one works. For FreeBSD users, there are two
     possible Device configurations (see below).</li>
 <li>Run the btape <b>test</b> command:
   <pre>
   ./btape -c bacula-sd.conf /dev/nst0
   test
   </pre>
   It isn't necessary to run the autochanger part of the
   test at this time,
   but do not go past this point until the basic test succeeds.</li>
 <li>Run the btape <b>fill</b> command, preferrably with two volumes.
   This can take a long time.  If you have an autochanger and it
   is configured, Bacula will automatically use it. If you do
   not have it configured, you can manual issue the appopriate
   <b>mtx</b> command, or press the autochanger buttons to change
   the tape when requested to do so. </li>
 <li>FreeBSD users, run the <b>tapetest</b> program, and make
   sure your system is patched if necessary. See below for more
   details.</li>
 <li>Run Bacula, and backup a reasonably small directory,
   say 60 Megabytes.  Do three successive backups of this
   directory.</li>
 <li>Stop Bacula, then restart it. Do another full backup
   of the same directory. Then stop and restart Bacula.</li>
 <li>Do a restore of the directory backed up, by entering the
   following restore command, being careful to restore it to
   an alternate location:
   <pre>
   restore select all done
   yes
   </pre>
   Do a <b>diff</b> on the restored directory to ensure it is identical
   to the original directory.
   </li>
 <li>If you have an autochanger, you should now go back to the
     btape program and run the autochanger test:
     <pre>
     ./btape -c bacula-sd.conf /dev/nst0
     auto
     </pre>
     Adjust your autochanger as necessary to ensure that it works
     correctly.
     </li>
</ol>
If you have reached this point, you stand a good chance of having
everything work. If you get into trouble at any point, <b>carefully</b>
read the documentation given below. If you cannot get past some point,
ask the <b>bacula-users</b> email list, but specify which of the
steps you have successfully completed. In particular, you may
want to look at the <a href="tapetesting.html#problems">
Tips for Resolving Problems</a> section below.

<h3>Specifying the Configuration File</h3>
Starting with version 1.27, each of the tape utility
programs including the <b>btape</b> program
requires a valid Storage daemon configuration
file (actually, the only part of the configuration file
that <b>btape</b> needs is
the <b>Device</b> resource definitions). 
This permits <b>btape</b> to find the configuration parameters
for your archive device (generally a tape drive). 
Without those parameters, the testing and utility programs
do not no how to properly read and write your drive.
By default, they use <b>bacula-sd.conf</b> in the current directory,
but you may specify a different     
configuration file using the <b>-c</b> option.

<h3>Specifying a Device Name For a Tape</h3>
<b>btape</b> <b>device-name</b> where the Volume can be found.
In the case of a tape, this is the
physical device name such as <b>/dev/nst0</b> or 
<b>/dev/rmt/0ubn</b> depending on your system
that you specify on the Archive Device directive. For the
program to work, it must find the identical name in
the Device resource of the configuration file. 
If the name is not found in the list of phsical names, the utility program will       
compare the name you entered to the Device names (rather
than the Archive device names).
See below for specifying Volume names.

<h3>Specifying a Device Name For a File</h3>
If you are attempting to read or write
an archive file rather than
a tape, the <b>device-name</b> should be the full 
path to the archive location including
the filename. The filename (last part of the specification) will
be stripped and used as the Volume name, and the path
(first part before the filename) must have the same
entry in the configuration file.  So, the path is equivalent
to the archive device name, and the filename is equivalent
to the volume name.

<h1><a name="btape">btape</a></h1>
This program permits a number of elementary tape operations via a
tty command interface.  The <b>test</b> command, described below,
can be very useful for testing tape drive compatibility
problems.  Aside from initial testing of tape drive compatibility
with <b>Bacula</b>, <b>btape</b> will be mostly used by
developers writing new tape drivers.
<p>
<b>btape</b> can be dangerous to use with existing
<b>Bacula</b> tapes because it will relabel a tape or  
write on the tape if so requested regardless of whether or not
the tape contains valuable data, so please be
careful and use it only on blank tapes.

<p>To work properly, <b>btape</b> needs to read the Storage
daemon's configuration file. As a default, it will look for
<b>bacula-sd.conf</b> in the current directory. If your
configuration file is elsewhere, please use the <b>-c</b>
option to specify where.
<p>The physical device name or the Device resource name
must be specified
on the command line, and that this same device name must be present
in the Storage daemon's configuration file read by <b>btape</b>
<pre>
Usage: btape [options] device_name
       -b &lt;file&gt;   specify bootstrap file
       -c &lt;file&gt;   set configuration file to file
       -d &lt;nn&gt;     set debug level to nn
       -s          turn off signals
       -v          be verbose
       -?          print this message.
</pre>


<h3>Using btape to Verify your Tape Drive</h3>                 
<p>An important reason for this program is
to ensure that a Storage daemon configuration
file is defined so that Bacula will correctly read and write
tapes. 
<p>
It is highly recommended that you run the <b>test</b> command 
before running 
your first Bacula job to ensure that the parameters you
have defined for your storage device (tape drive) will permit
<b>Bacula</b> to function properly. You only need to mount
a blank tape, enter the command, and the output should be
reasonably self explanatory.
For example:
<pre>
(ensure that Bacula is not running)
./btape -c /usr/bin/bacula/bacula-sd.conf /dev/nst0
</pre>
The output will be:
<pre>
Tape block granularity is 1024 bytes.
btape: btape.c:376 Using device: /dev/nst0
*
</pre>
Enter the test command:
<pre>
test
</pre>
The output produced should be something similar to the following:
I've cut the listing short because it is frequently updated to
have new tests.
<pre>

=== Append files test ===

This test is essential to Bacula.

I'm going to write one record  in file 0,
                   two records in file 1,
             and three records in file 2

btape: btape.c:387 Rewound /dev/nst0
btape: btape.c:855 Wrote one record of 64412 bytes.
btape: btape.c:857 Wrote block to device.
btape: btape.c:410 Wrote EOF to /dev/nst0
btape: btape.c:855 Wrote one record of 64412 bytes.
btape: btape.c:857 Wrote block to device.
btape: btape.c:855 Wrote one record of 64412 bytes.
btape: btape.c:857 Wrote block to device.
btape: btape.c:410 Wrote EOF to /dev/nst0
btape: btape.c:855 Wrote one record of 64412 bytes.
btape: btape.c:857 Wrote block to device.
btape: btape.c:855 Wrote one record of 64412 bytes.
btape: btape.c:857 Wrote block to device.
btape: btape.c:855 Wrote one record of 64412 bytes.
btape: btape.c:857 Wrote block to device.
btape: btape.c:410 Wrote EOF to /dev/nst0
btape: btape.c:387 Rewound /dev/nst0
btape: btape.c:693 Now moving to end of media.
btape: btape.c:427 Moved to end of media
We should be in file 3. I am at file 3. This is correct!

Now the important part, I am going to attempt to append to the tape.

...

=== End Append files test ===
</pre>

If you do not successfully complete the above test, please
resolve the problem(s) before attempting to use <b>Bacula</b>. 
Depending on your tape drive, the test may recommend that you
add certain records to your configuration. We strongly
recommend that you do so and then re-run the above test
to insure it works the first time.
<p>
Some of the suggestions it provides for resolving the problems
may or may not be useful. If at all possible avoid using fixed
blocking. If the test suddenly starts to print a long 
series of:
<pre>
Got EOF on tape.
Got EOF on tape.
...
</pre>
then almost certainly, you are running your drive in fixed
block mode rather than variable block mode. Please see below
for help on resolving that.
<p>
For FreeBSD users, please see the notes below for doing further
testing of your tape drive.

<h3>Linux SCSI Tricks</h3>
You can find out what SCSI devices you have by doing:
<pre>
cat /proc/scsi/scsi
</pre>
For example, I get the following:
<pre>
Attached devices:
Host: scsi2 Channel: 00 Id: 01 Lun: 00
  Vendor: HP       Model: C5713A           Rev: H107
  Type:   Sequential-Access                ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 04 Lun: 00
  Vendor: SONY     Model: SDT-10000        Rev: 0110
  Type:   Sequential-Access                ANSI SCSI revision: 02
</pre>
If you want to remove the SDT-10000 device, you can do so as root 
with:
<pre>
echo "scsi remove-single-device 2 0 4 0" >/proc/scsi/scsi
</pre>
and you can put add it back with:
<pre>
echo "scsi add-single-device 2 0 4 0" >/proc/scsi/scsi
</pre>
where the 2 0 4 0 are the Host, Channel, Id, and Lun as seen
on the output from <b>cat /proc/scsi/scsi</b>. Note, the 
Channel must be specified as numeric.

<a name="problems"></a>
<h2>Tips for Resolving Problems</h2>

<a name="CannotRestore"></a>
<h3>Bacula Saves But Cannot Restore Files</h3>
If you are getting error messages such as:
<pre>
Volume data error at 0:1! Wanted block-id: "BB02", got "". Buffer discarded
</pre>
It is very likely that Bacula has tried to do block
positioning and ended up at an invalid block. This       
can happen if your tape drive is in fixed block mode
while Bacula's default is variable blocks.  Note that
in such cases, Bacula is perfectly able to write to
your Volumes (tapes), but cannot position to read them.
<p>
There are two possible solutions. 
<ol>
 <li> The first and 
    best is to always ensure that your drive is in
    variable block mode. Note, it can switch back to
    fixed block mode on a reboot or if another program
    uses the drive. So on such systems you
    need to modify the Bacula startup files
    to explicitly set:
<pre>
mt -f /dev/nst0 defblksize 0
</pre>
   or whatever is appropriate on your system.
   </li>
<li>
    The second possibility, especially, if Bacula wrote
    while the drive was in fixed block mode, is to turn
    off block positioning in Bacula. This is done by
    adding:
<pre>
Block Positioning = no
</pre>
    to the Device resource. This is not the recommended 
    procedure because it can enormously slow down 
    recovery of files, but it may help where all else
    fails. This directive is available in version 1.35.5
    or later (and not yet tested).
    </li>
</ol>

<a name="opendevice"></a>
<h3>Bacula Cannot Open the Device</h3>
If you get an error message such as:
<pre>
dev open failed: dev.c:265 stored: unable to open 
device /dev/nst0:> ERR=No such device or address
</pre>
the first time you run a job, it is most likely due to
the fact that you specified the incorrect device
name on your <b>Archive Device</b>.
<p>
If Bacula works fine with your drive, then all off a sudden
you get error messages similar to the one shown above,
it is quite possible that your driver module is
being removed because the kernel deems it idle.
This is done via <b>crontab</b> with the use of
<b>rmmod -a</b>. To fix the problem, you can remove this
entry from <b>crontab</b>, or you can manually <b>modprob</b>
your driver module (or add it to the local startup script).
Thanks to Alan Brown for this tip.

<a name="IncorrectFiles"></a>
<h3>Incorrect File Number</h3>
When Bacula moves to the end of the medium, it     
normally uses the <b>ioctl(MTEOM)</b> function. 
Then Bacula uses the <b>ioctl(MTIOCGET)</b> 
function to retrieve the current file position from the
<b>mt_fileno</b> field. Some SCSI 
tape drivers will use a fast means of seeking to the end
of the medium and in doing so, they will not know
the current file position and hence return a <b>-1</b>.
As a consequence, if you get <b>"This is NOT correct!"</b> in
the positioning tests, this may be the cause.  You must 
correct this condition in order for Bacula to work.
<p>There are two possible solutions to the above problem
of incorrect file number:
<ul>
  <li>Figure out how to configure your SCSI driver to
      keep track of the file position during the MTEOM
      request. This is the preferred solution.</li>
  <li>Modify the <b>Device</b> resource of your <b>bacula-sd.conf</b> file
      to include:
      <pre>Hardware End of File = no</pre>
      This will cause Bacula to use the MTFSF request to
      seek to the end of the medium, and Bacula will keep
      track of the file number itself. </li>
</ul>


<a name="IncorrectBlocks"></a>
<h3>Incorrect Number of Blocks or Positioning Errors during btape Testing</h3>
<b>Bacula's</b> preferred method of working with tape drives
(sequential devices) is to run in variable block mode, and this
is what is set by default. You should first ensure that your tape drive
is set for variable block mode (see below).
<p>
If your tape drive is in fixed block
mode and you have told Bacula to use different fixed block sizes or
variable block sizes (default), 
you will get errors when Bacula attempts to forward space to
the correct block (the kernel driver's idea of tape blocks
will not correspond to Bacula's). 
<p>All modern tape drives support variable tape blocks, but some
older drives (in particular the QIC drives) as well as the ATAPI
ide-scsi driver run only in fixed block mode. The Travan tape drives
also apparently must run in fixed block mode (to be confirmed).
<p>
Even in variable block mode, with the exception of the first 
record on the second or subsequent volume of a multi-volume
backup, Bacula will write blocks of a fixed size.
However, in reading a tape, Bacula will assume that for    
each read request, exactly one block from the tape will
be transferred. This the most common way that tape drives
work and is well supported by <b>Bacula</b>.

<p>Drives that run in fixed block mode can cause serious
problems for Bacula if the drive's block size does
not correspond exactly to <b>Bacula's</b> block size. 
In fixed block size mode, drivers may transmit a partial
block or multiple blocks for a single read request. From
<b>Bacula's</b> point of view, this destroys the concept
of tape blocks. It is much better to run in variable block
mode, and almost all modern drives (the OnStream is an
exception) run in variable block mode.
In order for Bacula to run in fixed block
mode, you must include the following records in the
Storage daemon's Device resource definition:
<pre>
Minimum Block Size = nnn
Maximum Block Size = nnn
</pre>
where <b>nnn</b> must be the same for both records and must be identical
to the driver's fixed block size.
<p>
We recommend that you avoid this configuration if at all
possible by using variable block sizes.

<p>If you must run with fixed size blocks, make sure they are
not 512 bytes. This is too small and the overhead that Bacula has      
with each record will become excessive. If at all possible
set any fixed block size to something like 64,512 bytes or
possibly 32,768 if 64,512 is too large for your drive.
See below for the details on checking and setting the default 
drive block size.
<p>To recover files from tapes written in fixed block mode, see below.

<a name="TapeModes"></a>
<h3>Ensuring that the Tape Modes Are Properly Set -- <b>Linux Only</b></h3>
If you have a modern SCSI tape drive and you are having
problems with the <b>test</b> command as noted above, it
may be that some program has set one or more of the
your SCSI driver's options to non-default values. For
example, if your driver is set to work in SysV manner,
Bacula will not work correctly because it expects
BSD behavior.  To reset your tape drive to the default
values, you can try the following, but <b>ONLY</b> if you
have a SCSI tape drive on a <b>Linux</b> system:
<pre>
become super user
mt -f /dev/nst0 rewind
mt -f /dev/nst0 stoptions buffer-writes async-writes read-ahead
</pre>
The above commands will clear all options and then
set those specified. None of the specified options are
required by Bacula, but a number of other options such
as SysV behavior must not be set.  On systems other than 
Linux, you will need to consult your <b>mt</b> man pages
or documentation to figure out how to do the same thing.
This should not really be necessary though -- for example,
on both Linux and Solaris systems, the default tape
driver options are compatible with Bacula.
<p>
You may also want to ensure that no prior program has
set the default block size, as happened to one user, by
explicitly turning it off with:
<pre>
mt -f /dev/nst0 defblksize 0
</pre>
<p>
If you would like to know what stoptions you have set before
making any of the changes noted above, you can now view them on
Linux systems, thanks to a tip provided by Willem Riede. Do the
following:
<pre>
become super user
mt -f /dev/nst0 stsetoptions 0
grep st0 /var/log/messages
</pre>
and you will get output that looks something like the following:
<pre>
kernel: st0: Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
kernel: st0:    can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0,
kernel: st0:    defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 0
kernel: st0:    sysv: 0 nowait: 0
</pre>
Note, I have chopped off the beginning of the line with the date and machine     
name for presentation purposes.
<p>
Some people find that the above settings only last until the next
reboot, so please check this otherwise you may have unexpected problems.
<p>
Beginning with Bacula version 1.35.8, if Bacula detects that you are 
running in variable block mode, it will attempt to set your drive 
appropriately. All OSes permit setting variable block mode, but some
OSes do not permit setting the other modes that Bacula needs to function
properly. 


<a name="compression"></a>
<h3>Checking and Setting Tape Hardware Compression and Blocking Size</h3>
As far as I can tell, there is no way with the <b>mt</b>
program to check if your tape hardware compression is
turned on or off.  You can, however, turn it on by
using (on Linux):
<pre>
become super user
mt -f /dev/nst0 defcompression 1
</pre>
and of course, if you use a zero instead of the one at the end,
you will turn it off.
<p>
You may also want to ensure that no prior program has
set the default block size, as happened to one user, by
explicitly turning it off with:
<pre>
mt -f /dev/nst0 defblksize 0
</pre>
<p>If you have built the <b>mtx</b> program in the <b>depkgs</b>
package, you can use tapeinfo to get quite a bit of information
about your tape drive even if it is not an autochanger. This
program is called using the SCSI control device. On Linux
for tape drive /dev/nst0, this is usually /dev/sg0, while
on FreeBSD for /dev/nsa0, the control device is often /dev/pass2.
For example on my DDS-4 drive (/dev/nst0), I get the following:
<pre>
tapeinfo -f /dev/sg0
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'C5713A          '
Revision: 'H107'
Attached Changer: No
MinBlock:1
MaxBlock:16777215
SCSI ID: 5
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x26
BlockSize: 0             <==== check this
DataCompEnabled: yes     <==== check this
DataCompCapable: yes
DataDeCompEnabled: yes   <==== check this
CompType: 0x20
DeCompType: 0x0
Block Position: 1141
</pre>
where the <b>DataCompEnabled: yes</b> means that tape hardware
compression is turned on. You can see it turn on and off (yes/no) 
by using the <b>mt</b> commands given above.  Also, this output
will tell you if the <b>BlockSize</b> is non-zero and hence set for a
particular block size. Bacula is not likely to work in such
a situation because it will normally attempt
to write blocks of 64,512 bytes, except the last block
of the job which will generally be shorter.  The first thing
to try is setting the default block size to zero using the
<b>mt &nbsp; -f &nbsp; /dev/nst0 &nbsp; defblksize &nbsp; 0</b> command as shown 
above. On FreeBSD, this would be something like:
<b>mt &nbsp; -f &nbsp; /dev/nsa0 &nbsp; blocksize &nbsp; 0</b>.
<p>
<p> 
If your tape drive requires fixed block sizes (very unusual),
you can use the following records:
<pre>
Minimum Block Size = nnn
Maximum Block Size = nnn
</pre>
in your Storage daemon's Device resource to force
Bacula to write fixed size blocks (where you sent nnn
to be the same for both of the above records).
This should be done only if your drive does not support
variable block sizes, or you have some other strong
reasons for using fixed block sizes.
As mentioned above, a small fixed block size of 512 or
1024 bytes will be very inefficient. Try to set any fixed
block size to something like 64,512 bytes or larger if
your drive will support it.       
<p>Also, note that the <b>Medium Type</b> field of the
output of <b>tapeinfo</b> reports <b>Not Loaded</b>, which 
is not correct. As a consequence, you should ignore 
that field as well as the <b>Attached Changer</b> field.
<p>To recover files from tapes written in fixed block mode, see below.

<a name="FreeBSDTapes"></a>
<h3>Tape Modes on FreeBSD</h3></a>
On most FreeBSD systems such as 4.9 and most tape
drives, Bacula should run with:
<pre>
mt &nbsp; -f &nbsp; /dev/nsa0 &nbsp; seteotmodel &nbsp; 2
mt &nbsp; -f &nbsp; /dev/nsa0 &nbsp; blocksize &nbsp; 0
mt &nbsp; -f &nbsp;/dev/nsa0 &nbsp; comp &nbsp; enable
</pre>
You might want to put those commands in a startup script
to make sure your tape driver is properly initialized before
running Bacula.
<p>
Then according to what the
<b>btape test</b> command returns, you will probably need to set
the following (see below for an alternative):
<pre>
  Hardware End of Medium = no
  BSF at EOM = yes
  Backward Space Record = no
  Backward Space File = no
  Fast Forward Space File = no
  TWO EOF = yes
</pre>
Then be sure to run some append tests
with Bacula where you start and stop Bacula between appending
to the tape, or use <b>btape</b> version 1.35.1 or greater, which
includes simulation of stopping/restarting Bacula.
<p>
Please see the file <b>platforms/freebsd/pthreads-fix.txt</b>
in the main Bacula directory concerning <b>important</b> information
concerning compatibility of Bacula and your system. A much more
optimal Device configuration is shown below, but does not work
with all tape drives. Please test carefully before putting either
into production.
<p>
Note, for FreeBSD 4.10-RELEASE, using a Sony TSL11000 L100 DDS4
w/Autochanger set to variable block size and DCLZ compression,
Brian McDonald reports that to get Bacula to append correctly
between Bacula executions, the correct values to use are:
<pre>
mt &nbsp; -f &nbsp; /dev/nsa0 &nbsp; seteotmodel &nbsp; 1
mt &nbsp; -f &nbsp; /dev/nsa0 &nbsp; blocksize &nbsp; 0
mt &nbsp; -f &nbsp;/dev/nsa0 &nbsp; comp &nbsp; enable
</pre>
and
<pre>
  Hardware End of Medium = no
  BSF at EOM = no
  Backward Space Record = no
  Backward Space File = no
  Fast Forward Space File = yes
  TWO EOF = no
</pre>
This has been confirmed by several other people using different hardware.
This configuration is the preferred one because it uses one EOF and no 
backspacing at the end of the tape, which works much more efficiently
and reliably with modern tape drives.

<h3>Determining What Tape Drives and Autochangers You Have on FreeBSD</h3>
On FreeBSD, you can do a <b>camcontrol devlist</b> as root to determine
what drives and autochangers you have. For example,
<pre>
undef# camcontrol devlist
<WANGTEK 51000  SCSI M74H 12B3>    at scbus0 target 2 lun 0 (pass0,sa0)
<ARCHIVE 4586XX 28887-XXX 4BGD>    at scbus0 target 4 lun 0 (pass1,sa1)
<ARCHIVE 4586XX 28887-XXX 4BGD>    at scbus0 target 4 lun 1 (pass2)
</pre>
from the above, you can determine that there is a tape drive on
<b>/dev/sa0</b> and another on <b>/dev/sa1</b> in addition since there
is a second line for the drive on <b>/dev/sa1</b>, you know can assume
that it is the control device for the autochanger (i.e. <b>/dev/pass2</b>).
It is also the control device name to use when invoking the tapeinfo 
program. E.g.
<pre>
tapeinfo -f /dev/pass2
</pre>

<a name="onstream"></a>
<h3>Using the OnStream driver on Linux Systems</h3>
Bacula version 1.33 (not 1.32x) is now working and ready for testing
with the OnStream kernel osst driver version 0.9.14 or above. Osst is available
from: <a href="http://sourceforge.net/projects/osst/">http://sourceforge.net/projects/osst/</a>.
<p>
To make Bacula work you must first load the new driver then, as root,
do:
<pre>
  mt -f /dev/nosst0 defblksize 32768
</pre>
Also you must add the following to your Device resource in your Storage
daemon's conf file:
<pre>
 Minimum Block Size = 32768 
 Maximum Block Size = 32768
</pre>
Here is a Device specification provided by Michel Meyers that is            
known to work:
<pre>
Device {
  Name = "Onstream DI-30"
  Media Type = "ADR-30"
  Archive Device = /dev/nosst0
  Minimum Block Size = 32768
  Maximum Block Size = 32768
  Hardware End of Medium = yes
  BSF at EOM = no
  Backward Space File = yes
  Fast Forward Space File = yes
  Two EOF = no
  AutomaticMount = yes
  AlwaysOpen = yes
  Removable Media = yes
}
</pre>

<a name="fill"></a>
<h3>Using btape to Simulate Bacula Filling a Tape</h3>
Because there are often problems with certain tape drives
or systems when end of tape conditions occur, <b>btape</b>
has a special command <b>fill</b> that causes it to write
random data to a tape until the tape fills. It then writes
at least one more Bacula block to a second tape.   
Finally, it reads back both tapes to ensure that the data
has been written in a way that Bacula can recover it.
Note, there is also a single tape option as noted below, which
you should use rather than the two tape test. See below for
more details.
<p>
This can be an extremely time consuming process (here is
is about 6 hours) to fill a full tape.  Note, that btape    
writes random data to the tape when it is filling it. This
has two consequences: 1. it takes a bit longer to generate
the data, especially on slow CPUs. 2. the total amount
of data is approximately the real physical capacity of your
tape, regardless of whether or not the tape drive compression
is on or off. This is because random data does not compress
very much. 
<p>
To begin this test, you enter the <b>fill</b> command and
follow the instructions. There are two options:           
the simple single tape option and the multiple tape option. Please
use only the simple single tape option because the multiple
tape option still doesn't work totally correctly.  If the single
tape option does not succeed, you should correct the problem 
before using Bacula.

<a name="RecoveringFiles"></a>
<h2>Recovering Files Written to Tape With Fixed Block Sizes</h2>
If you have been previously running your tape drive in fixed block 
mode (default 512) and Bacula with variable blocks (default), then
in version 1.32f-x and 1.34 and above, Bacula will fail to recover
files because it does block spacing, and because the block sizes don't
agree between your tape drive and Bacula it will not work.  
<p>The long term solution is to run your drive in variable block 
mode as described above. However, if you have written tapes using
fixed block sizes, this can be a bit of a pain. The solution to
the problem is: while you are doing a restore command using a
tape written in fixed block size, ensure that your drive is 
set to the fixed block size used while the tape was written. Then
when doing the <b>restore</b> command in the Console program,
do not answer the prompt <b>yes/mod/no</b>. Instead, edit the
bootstrap file (the location is listed in the prompt) using
any ASCII editor. Remove all <b>VolBlock</b> lines in the 
file. When the file is re-written, answer the question, and
Bacula will run without using block positioning, and it should
recover your files.


<a name="BlockModes"></a>
<h2>Tape Blocking Modes</h2>
SCSI tapes may either be written in <b>variable</b> or <b>fixed</b>
block sizes. Newer drives support both modes, but some drives such
as the QIC devices always use fixed block sizes. Bacula
attempts to fill and write complete blocks (default 65K), so
that in normal mode (variable block size), Bacula will always
write blocks of the same size except the last block of a Job.
If Bacula is configured to write fixed block sizes, it will pad
the last block of the Job to the correct size.

Bacula expects variable tape block size drives to behave as follows:
Each write to the drive results in a single record being written to the
tape.  Each read returns a single record.  If you request less byte than
are in the record, only those number of bytes will be returned, but the
entire logical record will have been read (the next read will retrieve
the next record).  Thus data from a single write is always returned in a
single read, and sequentially written records are returned by
sequential reads.
<p>
Bacula expects fixed block size tape drives to behave as follows:
If a write length is greater than the physical block size of the
drive, the write will be written as two blocks each of the fixed
physical size. This a single write may become multiple physical
records on the tape. (This is not a good situation). According to
the documentation, one may never write an amount of data that is not the
exact multiple  of the blocksize (it is not specified if an error occurs
or if the the last record is padded). When reading, it is my understanding
that each read request reads one physical record from the tape.  Due
to the complications of fixed block size tape drives, you should
avoid them if possible with Bacula, or you must be ABSOLUTELY certain
that you use fixed block sizes within Bacula that correspond to
the physical block size of the tape drive.  This will ensure that
Bacula has a one to one correspondence between what it writes and
the physical record on the tape.
<p>
Please note that Bacula will not function correctly if it writes
a block and that block is split into two or more physical records
on the tape. Bacula assumes that each write causes a single record
to be written, and that it can sequentially recover each of the
blocks it has written by using the same number of sequential reads
as it had written.


<hr>

<page_prev name="Utility Programs" url="progs.html">
<page_next name="When Bacula crashes (Kaboom)" url="kaboom.html">
