The Storage resource defines which Storage devices, provided by Storage Daemons, are
available for use by the Director.
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
}
The explanation on how to read the directive format:
Name: Contains the linked name of the directive.
Description: Explains what the directive does.
Value: Indicates what type of value to provide (e.g., <type-specification>).
Data Type: Specifies the type of data expected.
Values: Lists specific acceptable values.
Required: If present, indicates that the directive must be set by the user, there is no default value.
Default: If present, indicates that the directive has a predefined value that does not need to be set by the user, cannot be removed.
Comment: Additional important notes.
Example: Shows a usage example.
Storage Start of the Storage resources. At least one storage resource must be
Description: The address is a host name, a FQDN, or an IP Address.
Value(s):<address>
Data Type: address
Required: Yes
Comment: 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.
Description:<address> is a host name, a FQDN, or an IP Address.
Value(s):<address>
Data Type: string
Comment: 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.
Description: The password to be used when establishing a connection with the Storage services.
Value(s):<password>
Data Type: password
Required: Yes
Comment: 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.
Description: Specifies the Storage Daemon’s name of the device resource to be used for the storage.
Value(s):<device-name>
Data Type: string
Required: Yes
Comment: 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.
Description: Specifies the Media Type to be used to store the data.
Value(s):<media-type>
Data Type: string
Required: Yes
Comment: 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.
Description: If you specify yes for this command, when you use the label command or the add command to create a new Volume, Bacula will also request the Autochanger Slot number.
Value(s):<yes|no>
Data Type: string
Default: false
Comment: 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.
Description: Maximum number of Jobs with the current Storage resource that can run concurrently.
Value(s):<number>
Data Type: positive integer
Default: 1
Comment: 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.
Description: Limits 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.
Value(s):<number>
Data Type: positive integer
Default: 0
Comment: 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.
Description: Enable or Disable automatic TLS PSK support.
Value(s):<yes|no>
Data Type: boolean
Default: yes
Comment: TLS PSK is enabled by default between all Bacula components. The Pre-Shared Key used between the programs is the Bacula password. If both TLS Enable and TLS PSK Enable are enabled, the system will use TLS certificates.
Description: Verify peer certificate. Instructs server to request and verify theclient’s X.509 certificate.
Value(s):<yes|no>
Data Type: boolean
Default: yes
Comment: Any client certificate signed by a known-CA will be accepted. Additionally,
the client’s X509 certificate Common Name must meet the value of the
Address directive. If the TLSAllowedCN configuration option is used,
the client’s x509 certificate Common Name must also correspond to one of the
CN specified in the TLS Allowed CN directive. This directive is valid only
for a server and not in client context. The default is yes.
Description: Common name attribute of allowed peer certificates.
Value(s):<certificate-list>
Data Type: string list
Comment: This directive is valid for a server and in a client context.
If this directive is specified, the peer certificate will be verified against
this list. In the case this directive is configured on a server side, the
allowed CN list will not be checked if TLS Verify Peer is set to no
(TLS Verify Peer is yes by default). This can be used to ensure that
only the CN-approved component may connect. This directive may be specified
more than once.
Example: In the case this directive is configured in a server side, the allowed CN
list will only be checked if TLS Verify Peer = yes (default).
Director {
Name = bacula-dir
Password = "password"
Address = director.example.com
# TLS configuration directives
TLS Enable = yes
TLS Require = yes
# if TLS Verify Peer = no, then TLS Allowed CN will not be checked.
TLS Verify Peer = yes
TLS Allowed CN = director.example.com
TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem
TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem
TLS Key = /opt/bacula/ssl/keys/client1_key.pem
}
In the case this directive is configured in a client side, the allowed CN list will always be checked.
Client {
Name = client1-fd
Address = client1.example.com
FDPort = 9102
Catalog = MyCatalog
Password = "password"
...
# TLS configuration directives
TLS Enable = yes
TLS Require = yes
# the Allowed CN will be checked for this client by director
# the client's certificate Common Name must match any of
# the values of the Allowed CN list
TLS Allowed CN = client1.example.com
TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem
TLS Certificate = /opt/bacula/ssl/certs/director_cert.pem
TLS Key = /opt/bacula/ssl/keys/director_key.pem
}
If the client doesn’t provide a certificate with a Common Name that meets any value in the TLS Allowed CN list, an error message will be issued:
16-Nov 17:30 bacula-dir JobId 0: Fatal error: bnet.c:273 TLS certificate
verification failed. Peer certificate did not match a required commonName
16-Nov 17:30 bacula-dir JobId 0: Fatal error: TLS negotiation failed with FD at
"192.168.100.2:9102".
Comment: If TLS is not enabled, none of the other TLS directives have any effect. In other words, even if you set TLS Require = yes you need to have TLS enabled or TLS will not be used.
Description: Full path to TLS CA certificate directory. In the current implementation, certificates must be stored PEM encoded with OpenSSL-compatible hashes, which is the subject name’s hash and an extension of .0. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer is set to no, and are always required in a client context.
Description: Path to PEM encoded Diffie-Hellman parameter file.
Value(s):<directory>
Data Type: string
Comment: If this directive is specified, DH key exchange will be used for the ephemeral
keying, allowing for forward secrecy of communications. DH key exchange adds an
additional level of security because the key used for encryption/decryption by the
server and the client is computed on each end and thus is never passed over the
network if Diffie-Hellman key exchange is used. Even if DH key exchange is not
used, the encryption/decryption key is always passed encrypted. This directive
is only valid within a server context.
To generate the parameter file, you may use openssl:
Comment: This directive is ignored unless one of TLS Enable or TLS PSK Enable is set to yes. If TLS is not required
while TLS or TLS-PSK are enabled, then the Bacula component will connect with other components either with or without TLS or TLS-PSK.
If TLS or TLS-PSK is enabled and TLS is required, then the Bacula component will refuse any connection request that does not use TLS.
Description: The full path and filename of a PEM encoded TLS certificate.
Value(s):<filename>
Data Type: string
Comment: It will be used as either a client or server certificate, depending on the connection
direction. PEM stands for Privacy Enhanced Mail, but in this context refers to how the
certificates are encoded. This format is used because PEM files are base64 encoded and
hence ASCII text based rather than binary. They may also contain encrypted information.
Example: This directive is required in a server context, but it may not be specified in a client
context if TLS Verify Peer is set to no in the corresponding server context.
Description: The full path and filename specifying a PEM encoded TLS CA certificate(s).
Value(s):<filename>
Data Type: string
Comment: Multiple certificates are permitted in the file.
One of TLS CA Certificate File or TLS CA Certificate Dir are required in a
server context, unless TLS Verify Peer (see above) is set to no, and are
always required in a client context.
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.
