
#include "bacula_template.inc" title="Storage Daemon Configuration" num=5.3

<H1>Storage Daemon Configuration</H1>

<h2>General</h2>
The Storage Daemon configuration file has relatively few resource
definitions.  However, due to the great variation in backup media and system
capabilities, the storage daemon must be highly configurable.  As a
consequence, there are quite a large number of record types in the
Device Resource definition that allow you to define all the
characteristics of your Storage device (normally a tape drive).
Fortunately, with modern storage devices, very few records are actually
needed.
<p>Examples of <b>Device</b> resource records that are known to
work for a number of common tape drives can be found in the 
<b>&lt;bacula-src&gt;/examples/devices</b> directory.

<p>For a general discussion of configuration file and resources
including the data types recognized by <b>Bacula</b>, please
see the <a href="configure.html">Configuration</a> chapter of this
manual.


The following Storage Resource definitions must be defined:
<ul> 
  <li><a href="#StorageResource.html">Storage</a> -- to define the
      name of the Storage daemon.</li>
  <li><a href="#DirectorResource">Director</a> -- to
      define the Director's name and his access password.</li>
  <li><a href="#DeviceResource">Device</a> -- to define
      the characteristics of your storage device (tape
      drive).
  <li><a href="messagesres.html">Messages</a> -- to define where error
      and information messages are to be sent.  </li>
</ul>

<h2><a name="StorageResource">Storage Resource</a></h2>
 In general, the properties specified under the Storage resource
 define global properties of the Storage daemon. Each Storage daemon
 configuration file must have one and only one Storage resource definition.
 <p></p>
<dl>
  <dt>Name = &lt;Storage-Daemon-Name&gt;</dt>
     <dd>Specifies the Name of the Storage daemon. This
     record is required. </dd>
  <dt>Working Directory = &lt;Directory&gt;</dt><dd>This directive
     is mandatory and specifies a directory in which the Storage daemon
     may put its status files. This directory should be used only
     by <b>Bacula</b>, but may be shared by other Bacula daemons. This
     record is required</dd>
  <dt>Pid Directory = &lt;Directory&gt;</dt><dd>This directive
    is mandatory and specifies a directory in which the Director 
    may put its process Id file files. The process Id file is used to 
    shutdown <b>Bacula</b> and to prevent multiple copies of
    <b>Bacula</b> from running simultaneously.
    This record is required. Standard shell expansion of the <b>Directory</b>
    is done when the configuration file is read so that values such
    as <b>$HOME</b> will be properly expanded.     
    <p>Typically on Linux systems, you will set this to:  
    <b>/var/run</b>. If you are not installing <b>Bacula</b> in the
    system directories, you can use the <b>Working Directory</b> as
    defined above. </dd>

  <dt>Heartbeat Interval = &lt;time-interval&gt;</dt><dd>This record
    defines an interval of time.  When the Storage daemon is waiting for
    the operator to mount a tape, each time interval, it will send a
    heartbeat signal to the File daemon.  The default interval is zero
    which disables the heartbeat.  This feature is particularly useful
    if you have a router such as 3Com that does not follow Internet
    standards and times out an inactive connection after a short
    duration.</dd>

  <dt>Maximum Concurrent Jobs = &lt;number&gt;</dt><dd>where &lt;number&gt;
    is the maximum number of Jobs that should run concurrently. The
    default is set to 2, but you may set it to a larger number. Each
    contact from the Director (e.g. status request, job start request) is
    considered as a Job, so if you want to be able to do a <b>status</b>
    request in the console at the same time as a Job is running, you
    will need to set this value greater than 1.</dd>

  <dt>SDPort = &lt;port-number&gt;</dt>
    <dd>Specifies port number on which the Storage daemon
    listens for Director connections. The default is 9103.</dd>

  <dt>SDAddress = &lt;IP-Address&gt;</dt><dd>This record is optional,
    and if it is specified, it will cause the Storage daemon server (for
    Director and File daemon connections) to bind to the specified
    <b>IP-Address</b>, which is either a domain name or an IP address
    specified as a dotted quadruple.  If this record is not specified,
    the Storage daemon will bind to any available address (the default).
    </dd>
</dl>
 
The following is a typical Storage daemon Storage definition.
<pre>
\#
\# &quot;Global&quot; Storage daemon configuration specifications appear
\# under the Storage resource.
\#
Storage {
  Name = &quot;Storage daemon&quot;
  Address = localhost
  WorkingDirectory = "~/bacula/working"
  Pid    Directory = "~/bacula/working"
}
</pre>


<h2><a name="DirectorResource">Director Resource</a></h2>
The Director resource specifies the Name of the Director
which is permitted to use the services of the Storage
daemon. There may be multiple Director resources.
The Director Name and Password must match the corresponding
values in the Director's configuration file.
<p></p>
<dl>
  <dt>Name = &lt;Director-Name&gt;
    <dd>Specifies the Name of the Director allowed to connect
    to the Storage daemon. This record is required.</dd>
  <dt>Password = &lt;Director-password&gt;
     <dd>Specifies the password that must be supplied by the above named
     Director. This record is required.</dd>
</dl>


The following is an example of a valid Director resource definition:
<pre>
Director {
  Name = MainDirector
  Password = my_secret_password
}
</pre>


<a name="DeviceResource">
<h2>Device Resource</h2></a>
The Device Resource specifies the details of each device (normally a
tape drive) that can be used by the Storage daemon.  There may be
multiple Device resources for a single Storage daemon.  In general, the
properties specified within the Device resource are specific to the
Device.

<dl>
<dt>Name = <em>Device-Name</em> 
  <dd>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 <b>Archive Device</b> record described below.
    The name you specify here is also used in your Director's conf
    file on the <a href="dirdconf.html#StorageResource">Device record</a>
    in its Storage resource.</dd>


<dt>Archive Device = <em>name-string</em> 
  <dd>The specified <b>name-string</b> gives the system file name of the
    storage device managed by this storage daemon.  This will usually be
    the device file name of a removable storage device (tape drive), for example
    &quot;<b>/dev/nst0</b>&quot; or &quot;<b>/dev/rmt/0mbn</b>&quot;.
    When specifying a tape device, it is preferable that the
    &quot;non-rewind&quot; variant of the device file name be given.
    In addition, on systems such as Sun, which have modified the tape
    access methods, you must be sure to specify to use
    Berkeley I/O conventions with the device. The <b>b</b> in the Solaris (Sun) 
    archive specification <b>/dev/rmt/0mbn</b> is what is needed in
    this case. Bacula does not support SysV tape drive behavior.
    <p>As noted above, normally the Archive Device is the name of a 
    tape drive, but you may also specify a directory name. In that case,
    Bacula 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.
    <p>In addition to a tape device name or a directory name, Bacula will
    accept the name of a FIFO. 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 Bacula
    writes into the FIFO. When the Storage daemon starts the job, it
    will wait for <b>MaximumOpenWait</b> 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 <b>RunBeforeJob</b>
    record. For this kind of device, you never want to specify
    <b>AlwaysOpen</b>, because you want the Storage daemon to open it only
    when a job starts, so you must explicitly set it to <b>No</b>.
    Since a FIFO is a one way device, Bacula 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 <b>add</b> command rather than
    then <b>label</b> command to avoid attempting to write a label.
    <p>During a restore operation, if the Archive Device is a FIFO, Bacula
    will attempt to read from the FIFO, so you must have an external program
    that writes into the FIFO. Bacula will wait <b>MaximumOpenWait</b> seconds
    for the program to begin writing and will then time it out and
    terminate the job. As noted above, you may use the <b>RunBeforeJob</b>
    to start the writer program at the beginning of the job.

    <p>The Archive Device record is required.  <p></p></dd>

<dt>Changer Device = <em>name-string</em> 
  <dd>The specified <b>name-string</b> gives the system file name of the
    autochanger device name that corresponds to the <b>Archive Device</b>
    specified. This device name is specified only if you have an autochanger.
    Typically, you will want to specify the <b>generic scsi</b> device
    name. For example, on Linux systems, for archive device <b>/dev/nst0</b>,
    This record is optional.  See the <a href="autochangers.html">
    Using Autochangers</a> chapter of this manual for more details
    of using this and the following autochanger records. <p></p></dd>

<dt>Media Type = <em>name-string</em> 
  <dd>The specified <b>name-string</b> names the type of media supported
    by this device, for example, &quot;DLT7000&quot;.  Media type names
    are arbitrary in that you set it to anything you want, but must be
    known to the volume database to keep track of which storage daemons
    can read which volumes.  The same <b>name-string</b> must appear in
    the appropriate Storage resource definition in the Director's
    configuration file.  This specification is required for all devices.
    <p></p></dd>

<a name="Autochanger">
<dt>Autochanger = <em>Yes|No</em></a>
  <dd>If <b>Yes</b>, this device is an automatic tape changer, and
      you should also specify a <b>Changer Device</b> as well as
      a <b>Changer Command</b>. 
      If <b>No</b> (default), the volume must be manually changed.
      You might also want to add an identical record to the 
      <a href="dirdconf.html#Autochanger"> Storage resource</a>
      in the Director's configuration file so that
      when labeling tapes you are prompted for the slot.
      <p></p></dd>

<dt>Changer Command = <em>name-string</em>
  <dd>The <b>name-string</b> specifies an external program to be called
      that will automatically change volumes as required by <b>Bacula</b>.
      There are a number of substitution characters that may be specified
      to configure your autochanger. For additional details, please see
      the <a href="autochangers.html">Autochangers</a> chapter of this
      manual.<p><p></dd>

<dt>Maximum Changer Wait = <em>time</em>
  <dd>This record specifies the maximum time for <b>Bacula</b> to wait
      for an autochanger to change the volume. If this time is exceeded,
      <b>Bacula</b> will invalidate the Volume slot number stored in
      the catalog and try again. If no additional changer volumes exist,
      <b>Bacula</b> will ask the operator to intervene. The default time
      out is 120 seconds.<p><p></dd>

<dt>Always Open = <em>Yes|No</em>
  <dd>If <b>Yes</b> (default), <b>Bacula</b> will always keep the device
      open unless specifically <b>unmounted</b> by the Console program.
      This permits <b>Bacula</b> to ensure that the tape drive is always
      available.  If you set <b>AlwaysOpen</b> to <b>no</b> <b>Bacula</b>
      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. To 
      minimize unnecessary operator intervention, it is highly recommended
      that <b>Always Open = yes</b>. This also ensures that the drive
      is available when <b>Bacula</b> needs it.
      <p>
      If you have <b>Always Open = yes</b> (recommended) and you want
      to use the drive for something else, simply use the <b>unmount</b>
      command in the Console program to release the drive. However, don't
      forget to remount the drive with <b>mount</b> when the drive is
      available or the next <b>Bacula</b> job will block.
      <p>For File storage, this record is ignored. For a FIFO storage
      device, you must set this to <b>No</b>.<p><p></dd>

<dt>Maximum Open Wait = <em>time</em>
  <dd>This record specifies the maximum amount of time that
     <b>Bacula</b> will wait for a device that is busy. The default is
     5 minutes. If the device cannot be obtained, the current Job will
     be terminated in error. <b>Bacula</b> will re-attempt to open the
     drive the next time a Job starts that needs the the drive.<p><p></dd>

<dt>Removable media = <em>Yes|No</em> 
  <dd>If <b>Yes</b>, this device supports removable media (for
    example, tapes or CDs).  If <b>No</b>, media cannot be removed
    (for example, an intermediate backup area on a hard disk).
    <p></p></dd>

<dt>Random access = <em>Yes|No</em> 
  <dd>If <b>Yes</b>, the archive device is assumed to be a random
    access medium which supports the <b>lseek</b> (or
    <b>lseek64</b> if Largefile is enabled during configuration) facility.
    <p></p></dd>

<dt>Maximum block size = <em>size-in-bytes</em> 
  <dd>The Storage daemon will aways attempt to write blocks of the
    specified <b>size-in-bytes</b> 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
    <b>size-in-bytes</b>.  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.  <p> If no
    value is specified or zero is specified, the Storage daemon will use
    a default block size of 64,512 bytes (126 * 512).  <p></p></dd>


<dt>Minimum block size = <em>size-in-bytes</em> 
  <dd>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
    <b>size-in-bytes</b>.  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.  <p>To force the block size to be fixed, as is
    normally the case for non-random access devices (tape drives), set
    the <b>Minimum block size</b> and the <b>Maximum block size</b> to
    the same value (zero included).  The default is that both the
    minimum and maximum block size are zero and the default block size
    is 64,512 bytes.  If you wish the block size to be fixed and
    different from the default, specify the same value for both
    <b>Minimum block size</b> and <b>Maximum block size</b>.  <p> For
    example, suppose you want a fixed block size of 100K bytes, then you
    would specify:

   <pre> 
    Minimum block size = 100K 
    Maximum block size = 100K 
   </pre> 
    If you want the
    block size to be variable but with a 64K minimum and 200K maximum (and
    default as well), you would specify: 

   <pre> 
    Minimum block size = 64K 
    Maximum blocksize = 200K 
   </pre>
<p></p></dd>


<dt>Hardware End of Medium = <em>Yes|No</em> 
  <dd>If <b>No</b>, the archive device is not required to support end
    of medium ioctl request, and the storage daemon will use the forward
    space file function to find the end of the recorded data. If
    <b>Yes</b>, the archive device must support the <TT>ioctl</TT>
    <TT>MTEOM</TT> call, which will position the tape to the end of the
    recorded data.  Default is <b>Yes</b>.  This function is
    used before appending to a tape to ensure that no previously
    written data is lost. We recommend if you have a non standard
    or unusual tape drive that you use the <b>btape</b> program to
    test your drive to see whether or not it supports this function.
    All modern (after 1998) tape drives support this feature. <p></p></dd>

<dt>BSF at EOM = <em>Yes|No</em>
  <dd>If <b>No</b>, the default, no special action is taken by
    Bacula with the End of Medium (end of tape) is reached because
    the tape will be positioned after the last EOF tape mark, and
    Bacula can append to the tape as desired.  However, on some
    systems, such as FreeBSD, when Bacula 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 Bacula appends from that point, all the appended
    data will be lost.  The solution for such systems is to
    specify <b>BSF at EOM</b> which causes Bacula to backspace
    over the second EOF mark.  Determination of whether or not
    you need this record is done using the <b>test</b> command
    in the <b>btape</b> program.<p></p></dd>

<dt>Backward Space Record = <em>Yes|No</em> 
  <dd>If <em>Yes</em>, the archive device supports the <TT>MTBSR
    ioctl</TT> to backspace records.  If <em>No</em>, this call is not
    used and the device must be rewound and advanced forward to the
    desired position.  Default is <b>Yes</b> for non random-access
    devices.  <p></p></dd>

<dt>Backward Space File = <em>Yes|No</em> 
  <dd>If <em>Yes</em>, the archive device supports the <b>MTBSF</b> and
    <b>MTBSF ioctl</b>s to backspace over an end of file mark and to the
    start of a file.  If <em>No</em>, these calls are not used and the
    device must be rewound and advanced forward to the desired position.
    Default is <b>Yes</b> for non random-access devices.  <p></p></dd>

<dt>Forward Space Record = <em>Yes|No</em> 
  <dd>If <em>Yes</em>, the archive device must support the <b>MTFSR
    ioctl</b> to forward space over records.  If <b>No</b>, data must
    be read in order to advance the position on the device.  Default is
    <b>Yes</b> for non random-access devices.  <p></p></dd>

<dt>Forward Space File = <em>Yes|No</em> 
  <dd>If <b>Yes</b>, the archive device must support the <TT>MTFSF
    ioctl</TT> to forward space by file marks.  If <em>No</em>, data
    must be read to advance the position on the device.  Default is
    <b>Yes</b> for non random-access devices.  <p></p></dd>

<dt>Offline On Unmount = <em>Yes|No</em> 
  <dd>The default for this record is <b>No</b>.  If <b>Yes</b> the
    archive device must support the <TT>MTOFFL ioctl</TT> to rewind and
    take the volume offline.  In this case, <b>Bacula</b> will issue the
    offline (eject) request before closing the device during the <b>unmount</b>
    command.  If <b>No</b> <b>Bacula</b> will not attempt to offline the
    device before unmounting it.  After an offline is issued,
    the cassette will be ejected thus <b>requiring operator intervention</b>
    to continue, and on some systems require an explicit load command
    to be issued (<b>mt -f /dev/xxx load</b>) 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.            
     <p><p></dd>

<dt>Maximum Volume Size = <em>size</em> 
  <dd>No more than <b>size</b> bytes will be written onto a given
    volume on the archive device. This record is used mainly in
    testing <b>Bacula</b> 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 record is deprecated (being phased out) in favor of the
    <b>Maximum Volume Bytes</b> defined in the Director's configuration
    file.
    <p></p></dd>

<dt>Maximum File Size = <em>size</em> 
  <dd>No more than <b>size</b> 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.<p></p></dd>


</dl>
<H2>Parallelism</H2>
<dl>
<dt>Maximum Concurrent Jobs = <em>positive integer</em> 
  <dd>The storage daemon will accept no more than the given
    <b>positive integer</b> of simultaneous connections.  The default
    is 10.  It is best to set this number fairly large (e.g. 10 or 20) and
    control how many Jobs are running with the   
    <b>Maximum Concurrent Jobs</b> in the Storage resource in the Director's 
    configuration file. <p></p></dd>

</dl>
  
<H2>Capabilities</H2>
<dl>
<dt>Label media = <em>Yes|No</em> 
  <dd>If <b>Yes</b>, 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 <a href="dirdconf.html#Label"><b>Label Format</b>
    </a> record in each Pool resource.  
    If this is <b>No</b> as by default,
    <b>Bacula</b> will label tapes only by specific operator 
    command (<b>label</b> 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.
    <p></p></dd>

<dt>Automatic mount = <em>Yes|No</em> 
  <dd>If <b>Yes</b> (the default), permits the daemon to examine the
    device to determine if it contains a <b>Bacula</b> labeled
    volume. This is done initially when the daemon is started,
    and then at the beginning of each job. This record is particularly
    important if you have set <b>Always Open = no</b> because it
    permits Bacula to attempt to read the device before asking
    the system operator to mount a tape.
    <p></p></dd>

</dl>
  
<!--  Comment off for now    ========================================

<dt>Mount anonymous volumes = <em>Yes|No</em> 
  <dd>If <b>Yes</b> (the default), the daemon will accept mount
    requests without a volume name, which will mount any <b>Bacula</b> labeled
    volume present in the archive device (the label of the mounted
    volume can be determined by a query request after it has been
    mounted) in read-only mode.  This permits scanning volumes to
    recover their contents in a disaster recovery scenario or when
    restoring from volumes whose entries in the media database have
    expired and been removed.  </dd>


<dt>*Hardware End of File = <em>Yes|No</em> 
  <dd>If <b>No</b>, the archive device is not required to support
    hardware end of file marks.  Instead, special data blocks are
    written which the storage daemon interprets as logical end of file
    marks.  If <b>Yes</b>, the archive device must support the
    <b>ioctl</b> <b>MTWEOF</b> call and return zero when an end of file
    mark is read.  Default is <b>Yes</b>.  Note! this record is not
    implemented since we have yet to encounter a tape drive that does
    not support MTWEOF. <p></p></dd>


<dt>*Maximum Connections = <em>number</em> 
  <dd>The storage daemon will accept no more than the given
    <em>number</em> of simultaneous connections from clients.  Note that
    the <em>connections</em>, which may be simply for query purposes,
    are distinct from <em>sessions</em>, which actually transfer data to
    and from the archive device.  Connections are limited simply to
    avoid running out of file descriptors and other resources.  Default
    is 16.  <p></p></dd>

<dt>*Maximum append sessions = <em>number</em> 
  <dd>No more than the specified <em>number</em> of simultaneous
    sessions may be opened for appending to a mounted, appendable
    volume.  This allows restricting the number of concurrent sessions
    to that appropriate to the speed of the archive device and network.
    Default is 0 (no limit).  <p></p></dd>

<dt>*Maximum append bandwidth = <em>size</em> 
  <dd>Regardless of any limitation on the number of simultaneous append
    sessions, the storage daemon will refuse to open new append sessions
    when the moving average of data transfer to the archive device
    exceeds <em>size</em> bytes per second.  This prevents accepting too
    many connections for the speed of the device, which only delays all
    parties attempting to use it.  Default is 0 (no limit).
    <p></p></dd>

<dt>*Maximum read sessions = <em>number</em> 
  <dd>No more than the specified <em>number</em> of read sessions may be
    opened simultaneously.  For non- random access devices, this should
    be set to 1 to avoid thrashing back and forth on the volume.
    Default is 1.  <p></p></dd>

<dt>*Simultaneous read and append = <em>Yes|No</em> 
  <dd>If <em>Yes</em>, the device permits read and append sessions to be
    opened at the same time.  This should be permitted only on random
    access devices with adequate performance for the number of sessions
    permitted.  Default is <em>No</em>.  </dd>


<dt>*Access mode = <em>Read/Append|Read|Append</em> 
  <dd>Restrict this storage daemon to the specified type(s) of sessions.
    Most simple configurations will use the default of
    <b>Read/Append</b>, but larger installations with multiple archive
    devices might want to dedicate one or more solely for writing
    backups while reserving another (or several others) for performing
    restores.  This keeps volume mount requests for restores from
    interfering with appending to backup tapes.  <p></p></dd>


<H4>Permissions and Passwords</H4>
<dl>
<dt>*Permission default = <em>Permit|Deny</em> 
  <dd>If <em>Deny</em> (the default), hosts not explicitly named on a
    Permit host statement may not access the storage daemon.  If
    <em>Permit</em>, any host not specifically listed on a Deny host
    statement may access the daemon.  <p></p>

<dt>*Permit append host = <em>string1 string2</em> 
  <dd>Permit the host named by the <em>string1</em>, which may specify a
    host name, a fully qualified domain name, or a network address,
    optionally followed by a slash and a subnet mask, to append data to
    media mounted on this storage daemon.  If <em>string2</em> is
    supplied, the named host must supply this password in order to open
    an append connection to the storage server.  Any number of Permit
    append host statements may be given.  <p></p>

<dt>*Deny append host = <em>string</em> 
  <dd>Deny append access to the host named by the <em>string</em>, which
    may specify a host name, a fully qualified domain name, or a network
    address, optionally followed by a slash and a subnet mask.  Any
    number of Deny append host statements may be given.  <p></p></dd>

<dt>*Permit read host = <em>string1 string2</em> 
  <dd>Permit the host named by the <em>string</em>, which may specify a
    host name, a fully qualified domain name, or a network address,
    optionally followed by a slash and a subnet mask, to read data on
    media mounted on this storage daemon.  If <em>string2</em> is
    supplied, the named host must supply this password in order to open
    a read connection to the storage server.  Any number of Permit read
    host statements may be given.  <p></p></dd>

<dt>*Deny read host = <em>string</em> 
  <dd>Deny read access to the host named by the <em>string</em>, which
    may specify a host name, a fully qualified domain name, or a network
    address, optionally followed by a slash and a subnet mask.  Any
    number of Deny read host statements may be given.  </dd>
</dl>
  
<H4>*Cleaning</H4>
<dl>
<dt>*Cleaning time = <em>time</em> 
  <dd>After each period of <em>time</em> elapses, automatically clean
    the archive device or, if it does not permit that, post a
    notification that the device requires cleaning.  <p></p>

<dt>*Cleaning capacity = <em>size</em> 
  <dd>Clean the device (or notify of its need to be cleaned) after
    <em>size</em> bytes have been transferred since the last cleaning.
    <p></p>

<dt>*Cleaning media changes = <em>number</em> 
  <dd>Clean the device (or notify of its need to be cleaned) after
    <em>number</em> media changes have occurred, regardless of the time
    and number of bytes transferred since the last cleaning.  <p></p>

<dt>*Cleaning required = <em>Yes|No</em> 
  <dd>If <em>Yes</em>, refuse to load media other that that for cleaning
    once the device is determined to require cleaning.  Default is
    <em>No</em>.  </dd></dl>
  

<H4>Logging</H4>
<dl>
  <dt>*Log file name = <em>string</em> 
  <dd>Append log file entries to the file name given by <em>string</em>. By 
  default no log is written. 
  <p></p>
  <dt>*Log file capacity = <em>size</em> 
  <dd>When the size of the log file exceeds <em>size</em>, the storage daemon 
  begins logging into a new file and renames the old log file with that name 
  followed by &quot;<TT>.0</TT>&quot;, successively renaming older logs up to the limit on 
  cycles kept. Default log file capacity is 64k bytes. 
  <p></p>
  <dt>*Log file cycles = <em>number</em> 
  <dd>Keep <em>number</em> previously filled log files with name suffixes of 
  &quot;<TT>.0</TT>&quot;, &quot;<TT>.1</TT>&quot;, etc. When cycling log files, those which exceed 
  the cycle limit are deleted, starting with the oldest. By default, 5 cycles 
  are kept. </dd></dl>

  
<H4>*Notification</H4>
<dl>
<dt>*Notify = <em>string1 Ignore|Client|Log|Exec  string2</em> 
  <dd>Send notifications of events of type <em>string1</em> to the
    <em>Log</em> or pass them to an external program executed with the
    command line given by <em>string2</em>, passed the storage daemon's
    identity, notification type, and notification string as command line
    arguments.  <em>Client</em> causes a notification event to be posted
    (where appropriate) to the client session whose action resulted in
    the notification.  If <em>Ignore</em> is specified, notifications of
    the specified type are ignored.  Multiple Notify statements may
    appear for a given type; all specified notifications are made.
    </dd>
</dl>



 end comment out     -->


<h2><a name="MessagesResource">Messages Resource</a></h2>
For a description of the Messages Resource, please see
the <a href="messagesres.html">Messages Resource</a> Chapter
of this manual.


<h2><a name="SampleConfiguration">Sample Storage Daemon Configuration File</a></h2>
A example Storage Daemon configuration file might be the following:
<pre>
\#
\# Default Bacula Storage Daemon Configuration file
\#
\#  For Bacula release 1.15 (5 March 2002) -- redhat 7.1
\#
\# You may need to change the name of your tape drive
\#   on the "Archive Device" directive in the Device
\#   resource.  If you change the Name and/or the 
\#   "Media Type" in the Device resource, please ensure
\#   that bacula-dir.conf has corresponding changes.
\#

Storage {                             \# definition of myself
  Name = rufus-sd
  Address = rufus
  WorkingDirectory = "$HOME/bacula/bin/working"
  Pid Directory = "$HOME/bacula/bin/working"
}

\#
\# List Directors who are permitted to contact Storage daemon
\#
Director {
  Name = rufus-dir
  Password = "ZF9Ctf5PQoWCPkmR3s4atCB0usUPg+vWWyIo2VS5ti6k"
}

\#
\# Devices supported by this Storage daemon
\# To connect, the Director's bacula-dir.conf must have the
\#  same Name and MediaType. 
\#
Device {
  Name = "HP DLT 80"
  Media Type = DLT8000
  Archive Device = /dev/nst0
  AutomaticMount = yes;               \# when device opened, read it
  AlwaysOpen = yes;
  RemovableMedia = yes;
}

\#Device {
\#  Name = SDT-7000                     # 
\#  Media Type = DDS-2
\#  Archive Device = /dev/nst0
\#  AutomaticMount = yes;               # when device opened, read it
\#  AlwaysOpen = yes;
\#  RemovableMedia = yes;
\#}

\#Device {
\#  Name = Floppy
\#  Media Type = Floppy
\#  Archive Device = /mnt/floppy
\#  RemovableMedia = yes;
\#  Random Access = Yes;
\#  AutomaticMount = yes;               # when device opened, read it
\#  AlwaysOpen = no;
\#}

\#Device {
\#  Name = FileStorage
\#  Media Type = File
\#  Archive Device = /tmp
\#  LabelMedia = yes;                   # lets Bacula label unlabeled media
\#  Random Access = Yes;
\#  AutomaticMount = yes;               # when device opened, read it
\#  RemovableMedia = no;
\#  AlwaysOpen = no;
\#}

\#
\# A very old Exabyte with no end of media detection
\#
\#Device {
\#  Name = "Exabyte 8mm"
\#  Media Type = "8mm"
\#  Archive Device = /dev/nst0
\#  Hardware end of medium = No;
\#  AutomaticMount = yes;               # when device opened, read it
\#  AlwaysOpen = Yes;
\#  RemovableMedia = yes;
\#}

\# 
\# Send all messages to the Director, 
\# mount messages also are sent to the email address
\#
Messages {
  Name = Standard
  director = rufus-dir = all
  operator = root = mount
}

</pre>

<!--   Commented out

<hr>
<H3>*Storage Daemon Configuration NOT YET IMPLEMENTED!!!</H3>
Due to the great variation in backup media and system capabilities, the
storage daemon must be highly configurable.  The configuration is
defined by a text file containing a sequence of configuration
statements.  These statements may eventually be integrated as a section
into a more comprehensive BACULA configuration file covering an entire
server or, perhaps, network, but for expedience in development a
separate configuration file will exist for each storage daemon, its file
name supplied on the command line when the storage daemon is started.

<p>The following configuration statements will be supported by the
initial storage daemon implementation; as the storage daemon grows in
complexity, configuration statements may be expected to proliferate.
Configuration statement tags and option values are insensitive to case
and extra embedded white space between words.

<p><em>Strings</em> are user-supplied specifications which may be quoted using 
the conventions of C language string constants. 

<p><em>Number</em> specifications are decimal or hexadecimal numbers, written as 
in the C language. 

<p><em>Size</em> specifications are sizes in bytes in the range 0 to 
2<SUP>128</SUP>-1 (340282366920938463463374607431768211455); sizes are specified 
as decimal numbers, optionally followed by one of the following letters (case 
insensitive) denoting multiplication by the corresponding unit: 
<BLOCKQUOTE>
  <DL compact>
    <dt>k 
    <dd>1024 (kilobyte) 
    <dt>m 
    <dd>1048576 (megabyte) 
    <dt>g 
    <dd>1073741824 (gigabyte) 
    <dt>t 
    <dd>1099511627776 (terabyte) 
    <dt>p 
    <dd>1125899906842624 (petabyte) 
    <dt>e 
    <dd>1152921504606846976 (exabyte) </dd></dl></BLOCKQUOTE>
<p><em>Time</em> specifications are in terms of days and fractions of a day, 
either absolute Julian day numbers or relative durations. The following 
case-independent letters may be appended to a time specification to multiply it 
by the corresponding factor. 
<BLOCKQUOTE>
  <DL compact>
    <dt>s 
    <dd>*second 
    <dt>m 
    <dd>*minute 
    <dt>h 
    <dd>*hour 
    <dt>d 
    <dd>*day 
    <dt>w 
    <dd>*week 
    <dt>o 
    <dd>*month 
    <dt>q 
    <dd>*quarter 
    <dt>y 
    <dd>*year 
    <dt>x 
    <dd>*decade 
    <dt>c 
    <dd>*century 
    <dt>l 
    <dd>*millennium </dd></dl></BLOCKQUOTE>
  </dl>
</blockquote>

  End comment out -->

<page_prev name="Client/File daemon Configuration" url="filedconf.html">
<page_next name="Messages Resource" url="messagesres.html">
