bareos-sd-resource-device-definitions.tex

\defDirective{Sd}{Device}{Alert Command}{}{}{%
The {\bf name-string} specifies an external program to be called at the
completion of each Job after the device is released.  The purpose of this
command is to check for Tape Alerts, which are present when something is
wrong with your tape drive (at least for most modern tape drives).  The same
substitution characters that may be specified in the Changer Command may
also be used in this string.  For more information, please see the
\ilink{Autochangers}{AutochangersChapter} chapter of this manual.

Note, it is not necessary to have an autochanger to use this command. The
example below uses the {\bf tapeinfo} program that comes with the {\bf mtx}
package, but it can be used on any tape drive. However, you will need to
specify a {\bf Changer Device} directive in your Device resource (see above)
so that the generic SCSI device name can be edited into the command (with
the \%c).

An example of the use of this command to print Tape Alerts  in the Job report
is:
\bconfigInput{config/SdDeviceAlertCommand1.conf}

and an example output when there is a problem could be:
\bconfigInput{config/SdDeviceAlertCommand2.conf}
}

\defDirective{Sd}{Device}{Always Open}{}{}{%
If {\bf Yes}, Bareos will always keep the device open unless
specifically {\bf unmounted} by the Console program.  This permits
Bareos to ensure that the tape drive is always available, and properly
positioned. If you set
{\bf AlwaysOpen} to {\bf no} {\bf Bareos} will only open the
drive when necessary, and at the end of the Job if no other Jobs are
using the drive, it will be freed.  The next time Bareos wants to append
to a tape on a drive that was freed, Bareos will rewind the tape and
position it to the end.  To avoid unnecessary tape positioning and to
minimize unnecessary operator intervention, it is highly recommended
that {\bf Always Open = yes}.  This also ensures that the drive is
available when Bareos needs it.

If you have {\bf Always Open = yes} (recommended) and you want to use the
drive for something else, simply use the {\bf unmount} command in the
Console program to release the drive. However, don't forget to remount the
drive with {\bf mount} when the drive is available or the next Bareos job
will block.

For File storage, this directive is ignored. For a FIFO storage  device, you
must set this to {\bf No}.

Please note that if you set this directive to {\bf No} Bareos  will release
the tape drive between each job, and thus the next job  will rewind the tape
and position it to the end of the data. This  can be a very time consuming
operation. In addition, with this directive set to no, certain multiple
drive autochanger operations will fail.  We strongly recommend to keep
{\bf Always Open} set to {\bf Yes}
}

\defDirective{Sd}{Device}{Archive Device}{}{}{%
Specifies where to read and write the backup data.
The type of the Archive Device can be specified by the \linkResourceDirective{Sd}{Device}{Device Type} directive.
If Device Type is not specified, Bareos tries to guess the Device Type
accordingly to the type of the specified Archive Device file type.

There are different types that are supported:
\begin{description}
    \item[device] Usually the device file
name of a removable storage device (tape drive),  for example \path|/dev/nst0|
or \path|/dev/rmt/0mbn|, preferably in the "non-rewind" variant.
In addition, on systems such as Sun, which have multiple tape
access methods, you must be sure to specify to use Berkeley I/O
conventions with the device.  The {\bf b} in the Solaris (Sun) archive
specification \path|/dev/rmt/0mbn| is what is needed in this case.
Bareos does not support SysV tape drive behavior.

    \item[directory] If a directory is specified, it is used as file storage.
The directory must be existing and be specified as absolute path.
Bareos will write to file storage in the specified
directory and the filename used will be the Volume name as specified in the
Catalog.  If you want to write into more than one directory (i.e.  to spread
the load to different disk drives), you will need to define two Device
resources, each containing an Archive Device with a different directory.

    \item[fifo] \label{SetupFifo}
A FIFO is a special kind of file that connects two programs
via kernel memory. If a FIFO device is specified  for a backup operation, you
must have a program that reads what Bareos  writes into the FIFO. When the
Storage daemon starts the job,
it  will wait for \linkResourceDirective{Sd}{Device}{Maximum Open Wait} seconds
for the read program to start reading, and then time it out and  terminate
the job. As a consequence, it is best to start the read  program at the
beginning of the job perhaps with the  \linkResourceDirective{Dir}{Job}{Run Before Job} directive.
For this kind of device,
you always want to specify \linkResourceDirective{Sd}{Device}{Always Open} = no,
because you want the Storage daemon to open it only  when a job starts.
Since a FIFO is a one way device, Bareos will not attempt
to read  a label of a FIFO device, but will simply write on it. To create a
FIFO Volume in the catalog, use the {\bf add} command rather than the {\bf
label} command to avoid attempting to write a label.

\bconfigInput{config/SdDeviceArchiveDevice1.conf}

During a restore operation, if the Archive Device is a FIFO, Bareos  will
attempt to read from the FIFO, so you must have an external program  that
writes into the FIFO. 
Bareos will wait \linkResourceDirective{Sd}{Device}{Maximum Open Wait} seconds  for the
program to begin writing and will then time it out and  terminate the job. As
noted above, you may use the \linkResourceDirective{Dir}{Job}{Run Before Job} to start the writer program
at the beginning of the job.

A FIFO device can also be used to test your configuration, see the \ilink{Howto section}{TestUsingFifoDevice}.

    \item[GlusterFS Storage] \label{GlusterArchiveType}
	don't use this directive,
	but only \linkResourceDirective{Sd}{Device}{Device Type} and \linkResourceDirective{Sd}{Device}{Device Options}
	(this behavior have changed with \sinceVersion{Sd}{Device Options}{15.2.0}).
    
   \item[Ceph Object Store] \label{CephArchiveType}
	don't use this directive,
	but only \linkResourceDirective{Sd}{Device}{Device Type} and \linkResourceDirective{Sd}{Device}{Device Options}.
	(this behavior have changed with \sinceVersion{Sd}{Device Options}{15.2.0}).
\end{description}
}

\defDirective{Sd}{Device}{Auto Deflate}{}{13.4.0}{%
This is a parameter used by \nameref{plugin-autoxflate-sd}
 which allow you to transform
a non compressed piece of data into a compressed piece of data on the storage daemon.
e.g. Storage Daemon compression. You can either enable compression on the client
and use the CPU cyclces there to compress your data with one of the supported
compression algorithms. The value of this parameter specifies a so called io-direction
currently you can use the following io-directions:

\begin{itemize}
\item in - compress data streams while reading the data from a device.
\item out - compress data streams while writing the data to a device.
\item both - compress data streams both when reading and writing to a device.
\end{itemize}

Currently only plain data streams are compressed (so things that are already
compressed or encrypted will not be considered for compression.) Also meta-data
streams are not compressed. The compression is done in a way that the stream is
transformed into a native compressed data stream. So if you enable this and
send the data to a filedaemon it will know its a compressed stream and will
do the decompression itself. This also means that you can turn this option on
and off at any time without having any problems with data already written.

This option could be used if your clients doesn't have enough power to do
the compression/decompression itself and you have enough network bandwidth.
Or when your filesystem doesn't have the option to transparently compress
data you write to it but you want the data to be compressed when written.
}

\defDirective{Sd}{Device}{Auto Deflate Algorithm}{}{13.4.0}{%
This option specifies the compression algorithm used for the autodeflate option
which is performed by the autoxflate-sd plugin. The algorithms supported are:
\begin{itemize}
\item GZIP - gzip level 1--9
\item LZO
\item LZFAST
\item LZ4
\item LZ4HC
\end{itemize}
}

\defDirective{Sd}{Device}{Auto Deflate Level}{}{13.4.0}{%
This option specifies the level to be used when compressing when you select a
compression algorithm that has different levels.
}

\defDirective{Sd}{Device}{Auto Inflate}{}{13.4.0}{%
This is a parameter used by \nameref{plugin-autoxflate-sd}
which allow you to transform
a compressed piece of data into a non compressed piece of data on the storage daemon.
e.g. Storage Daemon decompression. You can either enable decompression on the client
and use the CPU cyclces there to decompress your data with one of the supported
compression algorithms. The value of this parameter specifies a so called io-direction
currently you can use the following io-directions:

\begin{itemize}
\item in - decompress data streams while reading the data from a device.
\item out - decompress data streams while writing the data to a device.
\item both - decompress data streams both when reading and writing to a device.
\end{itemize}

This option allows you to write uncompressed data to for instance a tape drive
that has hardware compression even when you compress your data on the client with
for instance a low cpu load compression method (LZ4 for instance) to transfer
less data over the network. It also allows you to restore data in a compression
format that the client might not support but the storage daemon does. This only
works on normal compressed datastreams not on encrypted datastreams or meta data
streams.
}

\defDirective{Sd}{Device}{Auto Select}{}{}{%
If this directive is set to {\bf yes} (default), and the Device
belongs to an autochanger, then when the Autochanger is referenced
by the Director, this device can automatically be selected. If this
directive is set to {\bf no}, then the Device can only be referenced
by directly using the Device name in the Director. This is useful
for reserving a drive for something special such as a high priority
backup or restore operations.
}

\defDirective{Sd}{Device}{Autochanger}{}{}{%
If {\bf Yes}, this device belongs to an automatic tape changer, and you
must specify an {\bf Autochanger} resource that points to the {\bf
Device} resources.  You must also specify a
\linkResourceDirective{Sd}{Device}{Changer Device}.
If the Autochanger directive is set to {\bf No}, 
the volume must be manually changed.  You should also
have an identical directive to the
\linkResourceDirective{Dir}{Storage}{Auto Changer} in the Director's
configuration file so that  when labeling tapes you are prompted for the slot.
}

\defDirective{Sd}{Device}{Automatic Mount}{}{}{%
If {\bf Yes}, permits the daemon to examine the device to
determine if it contains a Bareos labeled volume.  This is done
initially when the daemon is started, and then at the beginning of each
job.  This directive is particularly important if you have set
{\bf Always Open = no} because it permits Bareos to attempt to read the
device before asking the system operator to mount a tape.  However,
please note that the tape must be mounted before the job begins.
}

\defDirective{Sd}{Device}{Backward Space File}{}{}{%
If {\bf Yes}, the archive device supports the {\bf MTBSF} and  {\bf MTBSF
  ioctl}s to backspace over an end of file mark and to the  start of a file. If
  {\bf No}, these calls are not used and the  device must be rewound and
  advanced forward to the desired position.
}

\defDirective{Sd}{Device}{Backward Space Record}{}{}{%
If {\bf Yes}, the archive device supports the {\tt MTBSR ioctl} to backspace
records. If {\bf No}, this call is not used and the device must be rewound
and advanced forward to the desired position.
This function if enabled is used at the end of a
Volume after writing the end of file and any ANSI/IBM labels to determine
whether or not the last block was written correctly. If you turn this
function off, the test will not be done. This causes no harm as the re-read
process is precautionary rather than required.
}

\defDirective{Sd}{Device}{Block Checksum}{}{}{%
You may turn off the Block Checksum (CRC32) code that Bareos uses when
writing blocks to a Volume. Doing so can reduce the Storage daemon CPU usage
slightly.  It will also permit Bareos to read a Volume that has corrupted
data.

It is not recommend to turn this off, particularly on older tape
drives or for disk Volumes where doing so may allow corrupted data to go
undetected.
}

\defDirective{Sd}{Device}{Block Positioning}{}{}{%
This directive tells Bareos not to use block positioning when doing restores.
Turning this directive off can cause Bareos to be {\bf extremely} slow
when restoring files.  You might use this directive if you wrote your
tapes with Bareos in variable block mode (the default), but your drive
was in fixed block mode.
}

\defDirective{Sd}{Device}{Bsf At Eom}{}{}{%
If {\bf No}, no special action is taken by Bareos with the End
of Medium (end of tape) is reached because the tape will be positioned after
the last EOF tape mark, and Bareos can append to the tape as desired.
However, on some systems, such as FreeBSD, when Bareos reads the End of
Medium (end of tape), the tape will be positioned after the second EOF tape
mark (two successive EOF marks indicated End of Medium). If Bareos appends
from that point, all the appended data will be lost. The solution for such
systems is to specify {\bf BSF at EOM} which causes Bareos to backspace over
the second EOF mark. Determination of whether or not you need this directive
is done using the {\bf test} command in the {\bf btape} program.
}

\defDirective{Sd}{Device}{Changer Command}{}{}{%
The {\bf name-string} specifies an external program to be called  that will
automatically change volumes as required by {\bf Bareos}.  Normally,
this directive will be specified only in the {\bf AutoChanger} resource,
which is then used for all devices.  However, you may also specify
the different {\bf Changer Command} in each Device resource.
Most frequently,
you will specify the Bareos supplied {\bf mtx-changer}  script as follows:

\bconfigInput{config/SdDeviceChangerCommand1.conf}

and you will install the \command{mtx} on your system.
An example of this command is in the default \file{bareos-sd.conf} file.
For more details on the substitution characters that may be specified  to
configure your autochanger please see  the
\nameref{AutochangersChapter} chapter of this  manual.
}

\defDirective{Sd}{Device}{Changer Device}{}{}{%
The specified {\bf name-string} must be the {\bf generic SCSI} device
name of the autochanger that corresponds to the normal read/write
{\bf Archive Device}  specified in the Device resource. This
generic SCSI device name should be specified if you have an autochanger
or if you have a standard tape drive and want to use the
{\bf Alert Command} (see below). For example, on Linux systems, for
an Archive Device name of {\bf /dev/nst0}, you would specify {\bf
/dev/sg0} for the Changer Device name. Depending on your exact
configuration, and the number of autochangers or the type of
autochanger, what you specify here can vary.  This directive is
optional.  See the \ilink{ Using Autochangers}{AutochangersChapter} chapter
of this manual for more details of using this and the following
autochanger directives.
}

\defDirective{Sd}{Device}{Check Labels}{}{}{%
If you intend to read ANSI or IBM labels, this \textbf{must} be set.
Even if the volume is not ANSI labeled, you can set this to yes, and Bareos will check the
label type. Without this directive set to yes, Bareos will assume that
labels are of Bareos type and will not check for ANSI or IBM labels.
In other words, if there is a possibility of Bareos encountering an
ANSI/IBM label, you must set this to yes.
}

\defDirective{Sd}{Device}{Close On Poll}{}{}{%
If {\bf Yes}, Bareos close the device (equivalent to  an unmount except no
mount is required) and reopen it at each  poll. Normally this is not too
useful unless you have the  {\bf Offline on Unmount} directive set, in which
case the  drive will be taken offline preventing wear on the tape  during any
future polling. Once the operator inserts a new  tape, Bareos will recognize
the drive on the next poll and  automatically continue with the backup.
Please see above for more details.
}

\defDirective{Sd}{Device}{Collect Statistics}{}{}{%
}

\defDirective{Sd}{Device}{Description}{}{}{%
}

\defDirective{Sd}{Device}{Device Options}{}{}{%
Some \linkResourceDirective{Sd}{Device}{Device Type} require additional configuration.
This can be specified in this directive, e.g. for
\begin{description}
    \item [\sdBackend{GFAPI}{GlusterFS}]
	A GlusterFS Storage can be used as Storage backend of Bareos.
	Prerequistes are a working GlusterFS storage system and the package \package{bareos-storage-glusterfs}.
	See \url{http://www.gluster.org/} for more information regarding GlusterFS installation and configuration
    and specifically \url{https://gluster.readthedocs.org/en/latest/Administrator Guide/Bareos/}
    for Bareos integration.
	You can use following snippet to configure it as storage device:
	\bconfigInput{config/SdDeviceDeviceOptionsGfapi1.conf}
	Adapt server and volume name to your environment.

	\sinceVersion{sd}{GlusterFS Storage}{15.2.0}

   \item [\sdBackend{Rados}{Ceph Object Store}]
	Here you configure the Ceph object store, which is accessed by the SD using the Rados library. Prerequistes are a
	working Ceph object store and the package \package{bareos-storage-ceph}. See \url{http://ceph.com} for more information regarding Ceph installation and configuration.
	Assuming that you have an object store with name \file{poolname}
	and your Ceph access is configured in \file{/etc/ceph/ceph.conf},
	you can use following snippet to configure it as storage device:
	\bconfigInput{config/SdDeviceDeviceOptionsRados1.conf}

	\sinceVersion{sd}{Ceph Storage}{15.2.0}
\end{description}

Before the Device Options directive have been introduced,
these options have to be configured in the \linkResourceDirective{Sd}{Device}{Archive Device} directive.
This behavior have changed with \sinceVersion{sd}{Device Options}{15.2.0}.
}


\defDirective{Sd}{Device}{Device Type}{}{}{%
The Device Type specification allows you to explicitly define the kind of device you want to use.
It may be one of the following:
\begin{description}
\item [\sdBackend{Tape}{}] is used to access tape device and thus has sequential access. Tape devices
  are controlled using ioctl() calls.
\item [\sdBackend{File}{}]
  tells Bareos that the device is a file. It may either be a
  file defined on fixed medium or a removable filesystem such as
  USB.  All files must be random access devices.
\item [\sdBackend{Fifo}{}] is a first-in-first-out sequential access read-only
  or write-only device.
\item [\sdBackend{GFAPI}{GlusterFS}] \label{SdBackendGfapi} is used to access a GlusterFS storage.
  It must be configured using \linkResourceDirective{Sd}{Device}{Device Options}.
  \sinceVersion{sd}{GlusterFS (gfapi)}{14.2.2}
\item [\sdBackend{Rados}{Ceph Object Store}] \label{SdBackendRados} is used to access a Ceph object store.
  It must be configured using \linkResourceDirective{Sd}{Device}{Device Options}.
  \sinceVersion{sd}{Ceph (Rados)}{14.2.2}
\end{description}

The Device Type directive is not required in all cases.
If it is not specified, Bareos will attempt to guess what kind of device has been specified using the
\linkResourceDirective{Sd}{Device}{Archive Device} specification supplied.
There are several advantages to
explicitly specifying the Device Type. First, on some systems, block and
character devices have the same type.
Secondly, if you explicitly specify the Device Type, the mount point
need not be defined until the device is opened. This is the case with
most removable devices such as USB.
If the Device Type is not explicitly specified, then the mount point
must exist when the Storage daemon starts.
}


\defDirective{Sd}{Device}{Diagnostic Device}{}{}{%
}

\defDirective{Sd}{Device}{Drive Crypto Enabled}{}{}{%
The default for this directive is {\bf No}. If {\bf Yes} the storage daemon
can perform so called Application Managed Encryption (AME) using a special
Storage Daemon plugin which loads and clears the Encryption key using the
SCSI SPIN/SPOUT protocol.
}

\defDirective{Sd}{Device}{Drive Index}{}{}{%
The {\bf Drive Index} that you specify is passed to the {\bf
mtx-changer} script and is thus passed to the {\bf mtx} program.  By
default, the Drive Index is zero, so if you have only one drive in your
autochanger, everything will work normally.  However, if you have
multiple drives, you must specify multiple Bareos Device resources (one
for each drive).  The first Device should have the Drive Index set to 0,
and the second Device Resource should contain a Drive Index set to 1,
and so on.  This will then permit you to use two or more drives in your
autochanger.
}

\defDirective{Sd}{Device}{Drive Tape Alert Enabled}{}{}{%
}

\defDirective{Sd}{Device}{Fast Forward Space File}{}{}{%
If {\bf No}, the archive device is not required to support  keeping track of
the file number ({\bf MTIOCGET} ioctl) during  forward space file. If {\bf
Yes}, the archive device must support  the {\tt ioctl} {\tt MTFSF} call, which
virtually all drivers  support, but in addition, your SCSI driver must keep
track of the  file number on the tape and report it back correctly by the
{\bf MTIOCGET} ioctl. Note, some SCSI drivers will correctly  forward space,
but they do not keep track of the file number or more  seriously, they do not
report end of medium.
}

\defDirective{Sd}{Device}{Forward Space File}{}{}{%
If {\bf Yes}, the archive device must support the {\tt MTFSF  ioctl} to
forward space by file marks. If {\bf No}, data  must be read to advance the
position on the device.
}

\defDirective{Sd}{Device}{Forward Space Record}{}{}{%
If {\bf Yes}, the archive device must support the {\bf MTFSR  ioctl} to
forward space over records. If {\bf No}, data must  be read in order to
advance the position on the device.
}

\defDirective{Sd}{Device}{Free Space Command}{}{}{%
}

\defDirective{Sd}{Device}{Hardware End Of File}{}{}{%
}

\defDirective{Sd}{Device}{Hardware End Of Medium}{}{}{%
All modern (after 1998) tape drives should support this
feature. In doubt, use the {\bf btape} program  to test your drive to see whether or not it
supports this function.
If the archive device does not support the end of medium
ioctl request {\tt MTEOM}, set this parameter to {\bf No}.
The storage daemon will then use the forward space file
function to find the end of the recorded data.
In addition, your SCSI driver must
keep track of the file number on the tape and report it back correctly by
the {\bf MTIOCGET} ioctl. Note, some SCSI drivers will correctly forward
space to the end of the recorded data, but they do not keep track of the
file number.  On Linux machines, the SCSI driver has a {\bf fast-eod}
option, which if set will cause the driver to lose track of the file
number. You should ensure that this option is always turned off using the
{\bf mt} program.
}

\defDirective{Sd}{Device}{Label Block Size}{64512}{14.2.0}{%
The storage daemon will write the label blocks with the size configured here.
Usually, you will not need to change this directive.

For more information on this directive, please see \nameref{Tapespeed and blocksizes}.
}

\defDirective{Sd}{Device}{Label Media}{}{}{%
\index[general]{Label Media}%
If {\bf Yes}, permits this device to automatically label blank media
without an explicit operator command.  It does so by using an internal
algorithm as defined on the \linkResourceDirective{Dir}{Pool}{Label Format} record in each
Pool resource.  If this is {\bf No} as by default, Bareos will label
tapes only by specific operator command (\bcommand{label}{} in the Console) or
when the tape has been recycled.  The automatic labeling feature is most
useful when writing to disk rather than tape volumes.
}

\defDirective{Sd}{Device}{Label Type}{}{}{%
Defines the label type to use, see section \nameref{AnsiLabelsChapter}.
This directive is implemented in the Director Pool resource (\linkResourceDirective{Dir}{Pool}{Label Type})
and in the SD Device resource.  If it is specified in the the SD Device resource, it will take
precedence over the value passed from the Director to the SD.
If it is set to a non-default value, make sure to also enable \linkResourceDirective{Sd}{Device}{Check Labels}.
}

\defDirective{Sd}{Device}{Maximum Block Size}{64512}{}{%
The Storage daemon will always attempt to
write blocks of the specified size (in-bytes) to the archive device.
As a consequence, this statement specifies both the default block size
and the maximum block size.  The size written never exceed the given
size.  If adding data to a block would cause it to exceed
the given maximum size, the block will be written to the archive device,
and the new data will begin a new block.

If no value is specified or zero is specified, the Storage daemon will
use a default block size of 64,512 bytes (126 * 512).

\warning{If your are using LTO drives, changing the block size after labeling the tape will result into unreadable tapes.}

Please read chapter \nameref{Tapespeed and blocksizes},
to see how to tune this value in a safe manner.
}

\defDirective{Sd}{Device}{Maximum Changer Wait}{}{}{%
This directive specifies the maximum time in seconds for Bareos to wait
for an autochanger to change the volume.  If this time is exceeded,
Bareos will invalidate the Volume slot number stored in the catalog and
try again.  If no additional changer volumes exist, Bareos will ask the
operator to intervene.
% TODO: if this is the format, then maybe "5 minutes" should be in
% TODO: quotes? define style. see others.
}

\defDirective{Sd}{Device}{Maximum Concurrent Jobs}{}{}{%
where {\textless}number{\textgreater} is the maximum number of Jobs that can run
concurrently on a specified Device.  Using this directive, it is possible
to have different Jobs using multiple drives, because when
the Maximum Concurrent Jobs limit is
reached, the Storage Daemon will start new Jobs on any other available
compatible drive.  This facilitates writing to multiple drives with
multiple Jobs that all use the same Pool.
}

\defDirective{Sd}{Device}{Maximum File Size}{}{}{%
No more than {\bf size} bytes will be written into a given logical file
on the volume.  Once this size is reached, an end of file mark is
written on the volume and subsequent data are written into the next
file.  Breaking long sequences of data blocks with file marks permits
quicker positioning to the start of a given stream of data and can
improve recovery from read errors on the volume.  The default is one
Gigabyte.  This directive creates EOF marks only on tape media.
However, regardless of the medium type (tape, disk, USB ...) each time
a the Maximum File Size is exceeded, a record is put into the catalog
database that permits seeking to that position on the medium for
restore operations. If you set this to a small value (e.g. 1MB),
you will generate lots of database records (JobMedia) and may
significantly increase CPU/disk overhead.

If you are configuring an modern drive like LTO-4 or newer, you probably will
want to set the {\bf Maximum File Size} to 20GB or bigger to avoid making
the drive stop to write an EOF mark.

For more info regarding this parameter, read the tape speed whitepaper:
\url{http://www.bareos.org/en/Whitepapers/articles/Speed\_Tuning\_of\_Tape\_Drives.html}

Note, this directive does not limit the size of Volumes that Bareos
will create regardless of whether they are tape or disk volumes. It
changes only the number of EOF marks on a tape and the number of
block positioning records (see below) that are generated. If you
want to limit the size of all Volumes for a particular device, use
the {\bf Maximum Volume Size} directive (above), or use the
{\bf Maximum Volume Bytes} directive in the Director's Pool resource,
which does the same thing but on a Pool (Volume) basis.
}

\defDirective{Sd}{Device}{Maximum Job Spool Size}{}{}{%
where the bytes specify the maximum spool size for any one job  that is
running. The default is no limit.
}

\defDirective{Sd}{Device}{Maximum Network Buffer Size}{}{}{%
where {\bf bytes} specifies the initial network buffer  size to use with the
File daemon.  This size will be adjusted down if it is too large until
it is accepted by the OS. Please use care in setting this value since if
it is too large, it will be trimmed by 512 bytes until the OS is happy,
which may require a large number of system calls.  The default value is
32,768 bytes.

The default size was chosen to be relatively large but not too big in
the case that you are transmitting data over Internet.  It is clear that
on a high speed local network, you can increase this number and improve
performance. For example, some users have found that if you use a value
of 65,536 bytes they get five to ten times the throughput.  Larger values for
most users don't seem to improve performance. If you are interested
in improving your backup speeds, this is definitely a place to
experiment. You will probably also want to make the corresponding change
in each of your File daemons conf files.
}

\defDirective{Sd}{Device}{Maximum Open Volumes}{}{}{%
}

\defDirective{Sd}{Device}{Maximum Open Wait}{}{}{%
This directive specifies the maximum amount of time that
Bareos will wait for a device that is busy.
If the device cannot be obtained, the current Job will be terminated in
error.  Bareos will re-attempt to open the drive the next time a Job
starts that needs the the drive.
}



\defDirective{Sd}{Device}{Maximum Part Size}{}{}{%
}

\defDirective{Sd}{Device}{Maximum Rewind Wait}{}{}{%
This directive specifies the maximum time in seconds for Bareos to wait
for a rewind before timing out.  If this time is exceeded,
Bareos will cancel the job.
}

\defDirective{Sd}{Device}{Maximum Spool Size}{}{}{%
where the bytes specify the maximum spool size for all jobs that are
running.  The default is no limit.
}

\defDirective{Sd}{Device}{Maximum Volume Size}{}{}{%
No more than {\bf size} bytes will be written onto a given volume on the
archive device.  This directive is used mainly in testing Bareos to
simulate a small Volume.  It can also be useful if you wish to limit the
size of a File Volume to say less than 2GB of data.  In some rare cases
of really antiquated tape drives that do not properly indicate when the
end of a tape is reached during writing (though I have read about such
drives, I have never personally encountered one).  Please note, this
directive is deprecated (being phased out) in favor of the {\bf Maximum
Volume Bytes} defined in the Director's configuration file.
}

\defDirective{Sd}{Device}{Media Type}{}{}{%
The specified {\bf name-string} names the type of media supported by this
device, for example, "DLT7000".  Media type names are arbitrary in that you
set them to anything you want, but they must be known to the volume
database to keep track of which storage daemons can read which volumes.  In
general, each different storage type should have a unique Media Type
associated with it.  The same {\bf name-string} must appear in the
appropriate Storage resource definition in the Director's configuration
file.

Even though the names you assign are arbitrary (i.e.  you choose the name
you want), you should take care in specifying them because the Media Type
is used to determine which storage device Bareos will select during
restore.  Thus you should probably use the same Media Type specification
for all drives where the Media can be freely interchanged.  This is not
generally an issue if you have a single Storage daemon, but it is with
multiple Storage daemons, especially if they have incompatible media.

For example, if you specify a Media Type of "DDS-4" then during the
restore, Bareos will be able to choose any Storage Daemon that handles
"DDS-4".  If you have an autochanger, you might want to name the Media Type
in a way that is unique to the autochanger, unless you wish to possibly use
the Volumes in other drives.  You should also ensure to have unique Media
Type names if the Media is not compatible between drives.  This
specification is required for all devices.

In addition, if you are using disk storage, each Device resource will
generally have a different mount point or directory. In order for
Bareos to select the correct Device resource, each one must have a
unique Media Type.
}

\defDirective{Sd}{Device}{Minimum Block Size}{}{}{%
This statement applies only to non-random access devices (e.g.
tape drives).  Blocks written by the storage daemon to a non-random
archive device will never be smaller than the given size.
The Storage daemon will attempt to efficiently fill blocks with data
received from active sessions but will, if necessary, add padding to a
block to achieve the required minimum size.

To force the block size to be fixed, as is the case for some non-random
access devices (tape drives), set the {\bf Minimum block size} and the
{\bf Maximum block size} to the same value.  The default
is that both the minimum and maximum block size are zero and the default
block size is 64,512 bytes.

For  example, suppose you want a fixed block size of 100K bytes, then you
would specify:

\bconfigInput{config/SdDeviceMinimumBlockSize1.conf}

Please note that if you specify a fixed block size as shown above,  the tape
drive must either be in variable block size mode, or  if it is in fixed block
size mode, the block size (generally  defined by \command{mt}) {\bf must} be
identical to the size specified  in Bareos -- otherwise when you attempt to
re-read your Volumes,  you will get an error.

If you want the  block size to be variable but with a 63K minimum and 200K
maximum (and  default as well), you would specify:

\bconfigInput{config/SdDeviceMinimumBlockSize2.conf}
}

\defDirective{Sd}{Device}{Mount Command}{}{}{%
This directive specifies the command that must be executed to mount
devices such as many USB devices. Before the command is
executed, \%a is replaced with the Archive Device, and \%m with the Mount
Point.

See the \nameref{mountcodes} section below for more details of
the editing codes that can be used in this directive.

If you need to specify multiple commands, create a shell script.
}

\defDirective{Sd}{Device}{Mount Point}{}{}{%
Directory where the device can be mounted.
This directive is used only
for devices that have {\bf Requires Mount} enabled such as
USB file devices.
}

\defDirective{Sd}{Device}{Name}{}{}{%
Specifies the Name that the Director will use when asking to backup or
restore to or from to this device. This is the logical  Device name, and may
be any string up to 127 characters in length.  It is generally a good idea to
make it correspond to the English  name of the backup device. The physical
name of the device is  specified on the {\bf Archive Device} directive
described below.  The name you specify here is also used in your Director's
conf  file on the
\nameref{DirectorResourceStorage} in its Storage
resource.
}

\defDirective{Sd}{Device}{No Rewind On Close}{}{}{%
If {\bf Yes} the storage daemon
will not try to rewind the device on closing the device e.g. when shutting
down the Storage daemon. This allows you to do an emergency shutdown of
the Daemon without the need to wait for the device to rewind. On restarting
and opening the device it will get a rewind anyhow and this way services
don't have to wait forever for a tape to spool back.
}

\defDirective{Sd}{Device}{Offline On Unmount}{}{}{%
If {\bf Yes} the  archive device
must support the {\tt MTOFFL ioctl} to rewind and  take the volume offline. In
this case, Bareos will issue the  offline (eject) request before closing the
device during the {\bf unmount}  command. If {\bf No} Bareos will not attempt
to offline the  device before unmounting it. After an offline is issued,  the
cassette will be ejected thus {\bf requiring operator intervention}  to
continue, and on some systems require an explicit load command  to be issued
({\bf mt -f /dev/xxx load}) before the system will recognize  the tape. If you
are using an autochanger, some devices  require an offline to be issued prior
to changing the volume. However,  most devices do not and may get very
confused.

If you are using a Linux 2.6 kernel or other OSes
such as FreeBSD or Solaris, the Offline On Unmount will leave the drive
with no tape, and Bareos will not be able to properly open the drive and
may fail the job.
%\TODO{missing reference:  For more information on this problem, please see the
%\ilink{description of Offline On Unmount}{NoTapeInDrive} in the Tape
%Testing chapter.}
}

\defDirective{Sd}{Device}{Query Crypto Status}{}{}{%
The default for this directive is {\bf No}. If {\bf Yes} the storage daemon
may query the tape device for it security status. This only makes sense when
Drive Crypto Enabled is also set to {\bf yes} as the actual query is performed
by the same Storage Daemon plugin and using the same SCSI SPIN protocol.
}

\defDirective{Sd}{Device}{Random Access}{}{}{%
If {\bf Yes}, the archive device is assumed to be a random access medium
which supports the {\bf lseek} (or {\bf lseek64} if Largefile is enabled
during configuration) facility. This should be set to {\bf Yes} for all
file systems such as USB, and fixed files.  It should be set to
{\bf No} for non-random access devices such as tapes and named pipes.
}

\defDirective{Sd}{Device}{Removable Media}{}{}{%
If {\bf Yes}, this device supports removable media (for example tapes).
If {\bf No}, media cannot be removed (for example, an
intermediate backup area on a hard disk). If {\bf Removable media} is
enabled on a File device (as opposed to a tape) the Storage daemon will
assume that device may be something like a USB device that can be
removed or a simply a removable harddisk. When attempting to open
such a device, if the Volume is not found (for File devices, the Volume
name is the same as the Filename), then the Storage daemon will search
the entire device looking for likely Volume names, and for each one
found, it will ask the Director if the Volume can be used.  If so,
the Storage daemon will use the first such Volume found.  Thus it
acts somewhat like a tape drive -- if the correct Volume is not found,
it looks at what actually is found, and if it is an appendable Volume,
it will use it.

If the removable medium is not automatically mounted (e.g. udev), then
you might consider using additional Storage daemon device directives
such as {\bf Requires Mount}, {\bf Mount Point}, {\bf Mount Command},
and {\bf Unmount Command}, all of which can be used in conjunction with
{\bf Removable Media}.
}

\defDirective{Sd}{Device}{Requires Mount}{}{}{%
When this directive is enabled, the Storage daemon will submit
a {\bf Mount Command} before attempting to open the device.
You must set this directive to {\bf yes} for removable
file systems such as USB devices that are not automatically mounted
by the operating system when plugged in or opened by Bareos.
It should be set to {\bf no} for
all other devices such as tapes and fixed filesystems. It should also
be set to {\bf no} for any removable device that is automatically
mounted by the operating system when opened (e.g. USB devices mounted
by udev or hotplug). This directive
indicates if the device requires to be mounted using the {\bf Mount
Command}.  To be able to write devices need a mount, the following
directives must also be defined: {\bf Mount Point}, {\bf Mount Command},
and {\bf Unmount Command}.
}

\defDirective{Sd}{Device}{Spool Directory}{}{}{%
specifies the name of the directory to be used to store  the spool files for
this device. This directory is also used to store  temporary part files when
writing to a device that requires mount (USB).  The default is to use the
working directory.
}

\defDirective{Sd}{Device}{Two Eof}{}{}{%
If {\bf Yes}, Bareos will write two end of file marks when terminating a
tape -- i.e. after the last job or at the end of the medium. If {\bf No},
Bareos will only write one end of file to terminate the tape.
}

\defDirective{Sd}{Device}{Unmount Command}{}{}{%
This directive specifies the command that must be executed to unmount
devices such as many USB devices. Before the command  is
executed, \%a is replaced with the Archive Device, and \%m with the  Mount
Point.

Most frequently, you will define it as follows:

\bconfigInput{config/SdDeviceUnmountCommand1.conf}

See the \nameref{mountcodes} section below for more details of
the editing codes that can be used in this directive.

If you need to specify multiple commands, create a shell script.
}

\defDirective{Sd}{Device}{Use Mtiocget}{}{}{%
If {\bf No}, the operating system is not required to support keeping track of
the file number and reporting it in the ({\bf MTIOCGET} ioctl).
If you must set this to No, Bareos will do the proper file
position determination, but it is very unfortunate because it means that
tape movement is very inefficient.
Fortunately, this operation system deficiency seems to be the case only
on a few *BSD systems.  Operating systems known to work correctly are
Solaris, Linux and FreeBSD.
}

\defDirective{Sd}{Device}{Volume Capacity}{}{}{%
}

\defDirective{Sd}{Device}{Volume Poll Interval}{}{}{%
If the time  specified on this directive is non-zero,
%after  asking the operator to mount a new volume
Bareos will  periodically poll (or read) the
drive at the specified  interval to see if a new volume has been mounted. If
the  time interval is zero, no polling will occur.  This
directive can be useful if you want to avoid operator  intervention via the
console. Instead, the operator can  simply remove the old volume and insert
the requested one,  and Bareos on the next poll will recognize the new tape
and  continue.
Please be aware that if you set this interval  too small, you
may excessively wear your tape drive if the  old tape remains in the drive,
since Bareos will read it on  each poll.
% This can be avoided by ejecting the
% tape using  the {\bf Offline On Unmount} and the {\bf Close on Poll}
% directives.
% However, if you are using a Linux 2.6 kernel or other OSes
% such as FreeBSD or Solaris, the Offline On Unmount will leave the drive
% with no tape, and Bareos will not be able to properly open the drive and
% may fail the job.
%\TODO{reference is missing:  For more information on this problem, please see the
%\ilink{description of Offline On Unmount}{NoTapeInDrive} in the Tape
%Testing chapter.}
}

\defDirective{Sd}{Device}{Write Part Command}{}{}{%
}