Storage Resource
The Storage resource defines which Storage devices, provided by Storage Daemons, are available for use by the Director.
Storage Start of the Storage resources. At least one storage resource must be specified.
Name = <name> The name of the storage resource. This name appears on the Storage
directive specified in the Job resource and is required.
Enabled = <yes|no> This directive allows you to enable or disable a resource.
When the resource is disabled, the storage device will not be used. To reuse it you
must re-enable the resource.
Address = <address> Where the address is a host name, a FQDN, or an
IP Address. Please note that the <address> as specified here will be
transmitted to the File daemon who will then use it to contact the Storage Daemon.
Hence, it is not, a good idea to use localhost as the name but rather a fully
qualified machine name or an IP Address. This directive is required.
FDStorageAddress = <address>Where the <address> is a hostname, a FQDN, or an IP Address. The <address> specified here will be transmitted to the File Daemon instead of the address the Director uses to contact the Storage Daemon. This FDStorageAddress will then be used by the File Daemon to contact the Storage Daemon. This directive particularly useful if the File daemon is in a different network domain than the Director or Storage daemon. It is also useful in NAT or firewall environments.
See the DirectorClientFdStorageAddress section for a full explanation.
SDPort = <port> Where port is the port to use to contact the storage daemon for
information and to start jobs. This same port number must appear in the Storage
resource of the Storage daemon’s configuration file. The default is 9103.
Password = <password> This is the password to be used when establishing a connection
with the Storage services. This same password also must appear in the Director resource
of the Storage daemon’s configuration file. This directive is required. If you have
either /dev/random or bc on your machine, Bacula will generate a random
password during the configuration process, otherwise it will be left blank.
The password is plain text. It is not generated through any special process, but it is preferable for security reasons to use random text.
Device = <device-name> This directive specifies the Storage daemon’s name of the
device resource to be used for the storage. If you are using an Autochanger, the name
specified here should be the name of the Storage daemon’s Autochanger resource rather
than the name of an individual device. This name is not the physical device name, but
the logical device name as defined on the Name directive contained in the or the
resource definition of the Storage daemon configuration file. You can specify any
name you would like (even the device name if you prefer) up to a maximum of 127
characters in length. The physical device name associated with this device is specified
in the Storage daemon configuration file (as Archive Device). Do not
define two different Storage resource directives in the Director that point to the
same Device in the Storage daemon. Doing so may cause the Storage daemon to block
(or hang) attempting to open the same device that is already open. This directive is
required.
MediaType = <MediaType> This directive specifies the Media Type to be used to
store the data. This is an arbitrary string of characters up to 127 maximum that you
define. It can be anything you want. However, it is best to make it descriptive of the
storage media (e.g. File, LTO-7, LTO-8, …). In addition, it is essential that you
make the specification unique for each storage media type. If you have two LTO
drives that have incompatible formats, or if you have a LTO-7 drive and a
LTO-8 autochanger, you almost certainly should specify different Media Types.
During a restore, assuming a LTO-8 Media Type is associated with the Job, Bacula
can decide to use any Storage daemon that supports Media Type LTO-8 and on any
drive that supports it.
If you are writing to disk Volumes, you must make doubly sure that each Device resource defined in the Storage daemon (and hence in the Director’s conf file) has a unique media type. Otherwise, your restores may not work because Bacula will assume that you can mount any volume with the same Media Type any Device associated with that Media Type. This is possible with tape drives, but with disk drives, unless you are very clever you cannot mount a Volume in any directory – this can be done by creating an appropriate soft link.
Currently Bacula permits only a single Media Type per Storage and Device definition. Consequently, if you have a drive that supports more than one Media Type, you can give a unique string to Volumes with different intrinsic Media Type (Media Type = LTO-7-8 for LTO-7 and LTO-8 types), but then those volumes will only be mounted on drives indicated with the dual type (LTO-7-8).
If you want to tie Bacula to using a single Storage daemon or drive, you must specify a unique Media Type for that drive. This is an important point that should be carefully understood. Note, this applies equally to Disk Volumes. If you define more than one disk Device resource in your Storage daemon’s conf file, the Volumes on those two devices are in fact incompatible because one can not be mounted on the other device since they are found in different directories. For this reason, you probably should use two different Media Types for your two disk Devices (even though you might think of them as both being File types). You can find more on this subject in the Basic Volume Management chapter of this manual.
The MediaType specified in the Director’s Storage resource, must correspond to
the MediaType specified in the resource of the Storage daemon configuration file. This directive is required, and it is used by the Director and the Storage daemon to ensure that a Volume automatically selected from the Pool corresponds to the physical device. If a Storage daemon handles multiple devices (e.g. will write to various file Volumes on different partitions), this directive allows you to specify exactly which device.
As mentioned above, the value specified in the Director’s Storage resource must agree with the value specified in the Device resource in the Storage daemon’s configuration file. It is also an additional check so that you don’t try to write data for a LTO onto an disk device.
Autochanger = <yes|no> If you specify yes for this command (the default is
no), when you use the label command or the add command to create a new
Volume, Bacula will also request the Autochanger Slot number. This simplifies
creating database entries for Volumes in an autochanger. If you forget to specify the
Slot, the autochanger will not be used. However, you may modify the Slot associated
with a Volume at any time by using the update volume or update slots command
in the console program. When Autochanger is enabled, the algorithm used by
Bacula to search for available volumes will be modified to consider only Volumes
that are known to be in the autochanger’s magazine. If no in changer volume is
found, Bacula will attempt recycling, pruning, …, and if still no volume is found,
Bacula will search for any volume whether or not in the magazine. By privileging
in changer volumes, this procedure minimizes operator intervention. The default is
no.
For the autochanger to be used, you must also specify Autochanger=yes in the in the Device Resource Storage Daemon’s configuration file as well as other important Storage daemon configuration information. Consult the Using Autochanger chapter for the details of using autochangers. You can modify any additional resources that correspond to devices that are part of the device.
Instead of the previous Autochanger=yes directive, the configuration should be modified to be Autochanger=xxx where xxx is the name of the Autochanger, as documented in TechnicalReferenceDirAutochangerResource.
MaximumConcurrentJobs = <number> where <number> is the maximum number of Jobs
with the current Storage resource that can run concurrently. Note, this directive limits
only Jobs for Jobs using this Storage daemon. Any other restrictions on the maximum
concurrent jobs such as in the Director, Job, or Client resources will also apply in
addition to any limit specified here. The default is set to 1, but you may set it
to a larger number. However, if you set the Storage daemon’s number of concurrent
jobs greater than one, we recommend that you read the waring documented
under Maximum Concurrent Jobs in the Director’s resource or
simply turn data spooling on as documented in
the Data Spooling chapter.
MaximumConcurrentReadJobs = <number> The main purpose is to limit the number
of concurrent Copy, Migration, and VirtualFull jobs so that they don’t monopolize
all the Storage drives causing a deadlock situation where all the drives are allocated
for reading but none remain for writing. This deadlock situation can occur when running
multiple simultaneous Copy, Migration, and VirtualFull jobs.
The default value is set to 0 (zero), which means there is no limit on the number of read jobs. Note, limiting the read jobs does not apply to Restore jobs, which are normally started manually. A reasonable value for this directive is one half the number of drives that the Storage resource has rounded down. Doing so will leave the same number of drives for writing and will generally avoid over committing drives and a deadlock.
AllowCompression = <yes|no> This directive is optional, and if you specify no
(the default is yes), it will cause backups jobs running on this storage resource
to run without client File Daemon compression. This effectively overrides compression
options in FileSets used by jobs which use this storage resource. When set to no
there will be a warning in the job log to notify that compression is disabled on this
resource.
HeartbeatInterval = <time-interval> This directive is optional and if specified
will cause the Director to set a keepalive interval (heartbeat) in seconds on each of
the sockets it opens for the Storage resource. This value will override any specified
at the Director level. It is implemented only on systems (Linux, …) that provide the
setsockopt TCP_KEEPIDLE function. The default value is 300s.
Note
TLS Directives in the Storage resource of bacula-dir.conf
Bacula has built-in network encryption code to provide secure network transport similar to that offered by stunnel or ssh . The Bacula TLS encryption applies only to information transmitted across a network, so the data written to Volumes by the Storage daemon is not encrypted by this code.
For more information how to enable TLS encryption, click here.
The following is an example of a valid Storage resource definition:
# Definition of tape storage device
Storage {
Name = LTO-Autochanger
Address = bacula-sd.example.com
Password = storage_password # password for Storage daemon
Device = "LTO-Autochanger"
# same as Device in Storage daemon
Media Type = LTO
# same as MediaType in Storage daemon
}
See also
Go back to:
Go to:
Go back to the Director Resource Types page.
Go back to the Technical Reference for Director.