Storage Resource
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.
The following is a typical Storage daemon Storage definition.
#
# "Global" Storage daemon configuration specifications appear
# under the Storage resource.
#
Storage {
Name = "bacula-sd"
Address = baculasd.example.com
WorkingDirectory = "/opt/bacula/working"
PidDirectory = "/opt/bacula/working"
}
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 directives.
Description: Specifies the Name of the Storage daemon.
Value(s):
<name>Data Type: string
Required: Yes
Description: The text field contains a description of the Storage Daemon that will be displayed in the graphical user interface.
Value(s):
<text>Data Type: string
Description: Specifies a directory in which the Storage Daemon may put its status files.
Value(s):
<directory>Data Type: string
Required: Yes
Comment: This directory should be used only by Bacula, but may be shared by other Bacula daemons provided the names given to each daemon are unique. This directive is required.
Description: Specifies a directory in which the Storage Daemon may put its process Id file.
Value(s):
<directory>Data Type: string
Required: Yes
Comment: The process Id file is used to shutdown Bacula and to prevent multiple copies of from running simultaneously. Standard shell expansion of the PidDirectory is done when the configuration file is read so that values such as $HOME will be properly expanded.
Description: Each daemon (DIR, FD, SD) has a Plugin Directory directive that may be added to the daemon definition resource. The directory takes a quoted string argument, which is the name of the directory in which the daemon can find the Bacula plugins.
Value(s):
<directory>Data Type: string
Comment: If this directive is not specified, Bacula will not load any plugins. Since each plugin has a distinctive name, all the daemons can share the same plugin directory.
Description: Specifies a directory in which the Storage Daemon may put data block files for all devices of the type dedup.
Value(s):
<directory>Data Type: string
Comment: This directive is mandatory when using Global Endpoint Deduplication feature. The Dedup Directory can be very large after some point, we advise you to use a logical volume manager to be able to extend the filesystem when needed with new disks.
Description: Specifies a directory in which the Storage Daemon may put its index files for all devices of the type dedup.
Value(s):
<directory>Data Type: string
Description: Specifies an external program that must provide the encryption keys for the volumes.
Value(s):
<command>Data Type: string
Comment: This is related to the Volume Encryption directive in Device resource. More information can be found in the Volume Encryption chapter.
Description: Defines a time interval in seconds.
Value(s):
<time>Data Type: time
Default: 5 minutes
Comment: 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 300s. This feature is particularly useful if you have a router that does not follow Internet standards and times out a valid connection after a short duration despite the fact that keepalive is set. This usually results in a broken pipe error message.
Description: Defines an interval of time in seconds that the Storage Daemon will wait for a Client (the File Daemon) to connect.
Value(s):
<time>Data Type: time
Default: 30 minutes
Comment: The default is 30 minutes. Be aware that the longer the Storage daemon waits for a Client, the more resources will be tied up.
Description: Defines an interval of time in seconds that the Storage Daemon will try to connect to the File Daemon.
Value(s):
<time>Data Type: time
Default: 30 minutes
Comment: If no connection is made in the specified time interval, the Storage Daemon cancels the Job.
Description: Maximum number of Jobs that may run concurrently.
Value(s):
<number>Data Type: positive integer
Default: 20
Comment: The default is set to 20, 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 status request in the console at the same time as a Job is running, you will need to set this value greater than 1. To run simultaneous Jobs, you will need to set a number of other directives in the Director’s configuration file. Which ones you set depend on what you want, but you will almost certainly need to set the Maximum Concurrent Jobs in the Storage resource in the Director’s configuration file and possibly those in the Job and Client resources.
Description: Limits container file growth for better performance. It prevents indefinite expansion, even if the file system supports large files.
Value(s):
<>Data Type: positive integer
Comment: The recommended value is between 1 TB and 4 TB.
Description: Specifies the ports and addresses on which the Storage Daemon will listen for Director connections.
Value(s):
<IP-address>Data Type: string
Comment: Normally, the default is sufficient and you do not need to specify this directive.
Example: Probably the simplest way to explain how this directive works is to show an example:
SDAddresses = { ip = { addr = 1.2.3.4; port = 1205; } ipv4 = { addr = 1.2.3.4; port = http; } ipv6 = { addr = 1.2.3.4; port = 1205; } ip = { addr = 1.2.3.4 port = 1205 } ip = { addr = 1.2.3.4 } ip = { addr = 201:220:222::2 } ip = { addr = bluedot.thun.net } }where ip, ip4, ip6, addr, and port are all keywords.
Note
The address can be specified as either a dotted quadruple, or IPv6 colon notation, or as a symbolic name (only in the ip specification). Also, port can be specified as a number or as the mnemonic value from the /etc/services file. If a port is not specified, the default will be used. If an ip section is specified, the resolution can be made either by IPv4 or IPv6. If ip4 is specified, then only IPv4 resolutions will be permitted, and likewise with ip6.
Using this directive, you can replace both the SDPort and SDAddress directives shown below.
Description: Specifies port number on which the Storage daemon listens for Director connections.
Value(s):
<port-number>Data Type: port
Default: 9103
Description: Lets the Storage Daemon server (for Director and File Daemon connections) to bind to the specified IP-Address, which is either a domain name or an IP address specified as a dotted quadruple.
Value(s):
<IP-address>Data Type: string
Description: Require
FIPScryptographic module to start the daemon.Value(s):
<yes|no>Data Type: boolean
Description: If the two Bacula components (DIR, FD, SD, bconsole) have the comm line compression enabled, the line compression will be enabled.
Value(s):
<yes|no>Data Type: boolean
Default: yes
Comment: In many cases, the volume of data transmitted across the communications line can be reduced by a factor of three when this directive is enabled. In the case that the compression is not effective, Bacula turns it off on a record by record basis.
If you are backing up data that is already compressed the comm line compression will not be effective, and you are likely to end up with an average compression ratio that is very small. In this case, Bacula reports None in the Job report.
Description: <string> is an identifier which can be used for support purpose. This string is displayed using the version command.
Value(s):
<string>Data Type: string
Description: Specifies a directory in which the Director and the Storage daemon will look for many of the scripts that it needs to use during particular operations such as starting/stopping, the
mtx-changerscript, tape alerts, as well as catalog updates.Value(s):
<directory>Data Type: string
Comment: This directory may be shared by other Bacula daemons. Standard shell expansion of the directory is done when the configuration file is read so that if you wish to use values such as
$HOMEthey will be properly expanded.
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: Enable TLS support.
Value(s):
<yes|no>Data Type: boolean
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: When TLS Authenticate is enabled, after doing the CRAM-MD5 authentication, Bacula will also do TLS authentication, then TLS encryption will be turned off, and the rest of the communication between the two Bacula components will be done without encryption. If TLS-PSK is used instead of the regular TLS, the encryption is turned off after the TLS-PSK authentication step.
Value(s):
<yes|no>Data Type: boolean
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: 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:
openssl dhparam -out dh4096.pem -5 4096
Description: The full path and filename of a PEM encoded TLS private key. It must correspond to the TLS certificate.
Value(s):
<filename>Data Type: string
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.
Value(s):
<directory>Data Type: string
Description: Require TLS or TLS-PSK encryption.
Value(s):
<yes|no>Data Type: boolean
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: 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.
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).
Example: For example, in bacula-fd.conf, Director resource definition:
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".
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. 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-sd.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.
See also
Go to:
Go back to Storage Daemon Resource Types page.
Go back to the Technical Reference for Storage Daemon.
Go back to the main Technical Reference page.