Director Resource

The Director resource defines the attributes of the Directors running on the network. In the current implementation, there is only a single Director resource, but a future design may contain multiple Directors to maintain index and media database redundancy.

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.

Director Start of the Director resource. One and only one director resource must

Name

Description: Director name used by the system administrator.

Value(s): <name>

Data Type: string

Required: Yes

Description

Description: The text field contains a description of the Director that will be displayed in the graphical user interface.

Value(s): <text>

Data Type: string

Password

Description: Specifies the password that must be supplied for the default Bacula Console to be authorized.

Value(s): <password>

Data Type: password

Required: Yes

Comment: The same password must appear in the resource of the Console configuration file. For added security, the password is never passed across the network but instead a challenge response hash code created from the password. 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 and you must manually supply it.

The password is plain text. It is not generated through any special process but as noted above, it is better to use random text for security reasons.

Malware Database Command

Description: Specifies the command used to update the Malware database.

Value(s): <command>

Data Type: string

Comment: The default Malware database handler uses abuse.ch (get_malware_abuse.ch). The database is synchronized automatically when an update is available.

Messages

Description: Specifies where to deliver Director messages that are not associated with a specific Job.

Value(s): <messages-resource-name>

Data Type: string

Comment: Most messages are specific to a job and will be directed to the Messages resource specified by the job. However, there are a few messages that can occur when no job is running.

Plugin Directory

Description: Each daemon (DIR, FD, SD) has a Plugin Directory directive that may be added to the daemon definition resource.

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.

Working Directory

Description: Specifies a directory in which the Director 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. However, if this directory is shared with other Bacula daemons (the File daemon and Storage daemon), you must ensure that the given to each daemon is unique so that the temporary filenames used do not collide. By default the Bacula configure process creates unique daemon names by postfixing them with -dir, -fd, and -sd. Standard shell expansion of the Working Directory is done when the configuration file is read so that if you wish to use values such as $HOME they will be properly expanded. This directive is required.

The working directory specified must already exist and be readable and writable by the Bacula daemon referencing it.

Pid Directory

Description: This directive is mandatory and specifies a directory in which the Director may put its status files.

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.

The PID directory specified must already exist and be readable and writable by the Bacula daemon referencing it.

By default, Bacula will use the working directory to store the process id file.

Scripts Directory

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-changer script, 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 $HOME they will be properly expanded.

Query File

Description: Specifies a directory and file in which the Director can find the canned SQL statements for the query command of the Console.

Value(s): <path>

Data Type: string

Required: Yes

Comment: Standard shell expansion of the File is done when the configuration file is read so that if you wish to use values such as $HOME they will be properly expanded.

Heartbeat Interval

Description: Makes Director set a keepalive interval (heartbeat) in seconds on each of the sockets it opens for the Client resource.

Value(s): <time>

Data Type: time

Default: 0 seconds

Comment: This value will override any specified at the Director level. It is implemented only on systems (e.g. Linux) that provide the setsockopt TCP_KEEPIDLE function.

Maximum Concurrent Jobs

Description: Maximum number of total Director Jobs that should run concurrently.

Value(s): <number>

Data Type: positive integer

Default: 1

Comment: The default is set to 20, but you may set it to a larger number. Every valid connection to any daemon (Director, File daemon, or Storage daemon) results in a Job. This includes connections from bconsole. Thus the number of concurrent Jobs must, in general, be greater than the maximum number of Jobs that you wish to actually run.

In general, increasing the number of Concurrent Jobs increases the total throughput of Bacula, because the simultaneous Jobs can all feed data to the Storage daemon and to the Catalog at the same time. However, keep in mind, that the Volume format becomes more complicated with multiple simultaneous jobs, consequently, restores may take longer if must sort through interleaved volume blocks from multiple simultaneous jobs. Though not normally necessary, this can be avoided by having each simultaneous job write to a different volume or by using data spooling, which will first spool the data to disk simultaneously, then write one spool file at a time to the volume thus avoiding excessive interleaving of the different job blocks.

Maximum Reload Requests

Description: Defines the maximum number of reload requests that can be queued, waiting for resources that are locked while Jobs are active. If the limit is reached, subsequent reloads will not be possible until some of the currently running jobs are finished.

Value(s): <number>

Data Type: positive integer

Default: 32

Comment: Increasing the default value should be considered carefully, as the operational consequences can be considerable.

Example: See the following example:
Director {
    Name = localhost-dir
    Maximum Reload Requests = 64
    ...
}

FD Connect Timeout

Description: Time that the Director should continue attempting to contact the File Daemon to start a job, and after which the Director will cancel the job.

Value(s): <time>

Data Type: time

Default: 3 minutes

SD Connect Timeout

Description: Time that the Director should continue attempting to contact the Storage daemon to start a job, and after which the Director will cancel the job.

Value(s): <time>

Data Type: time

Default: 30 minutes

Dir Addresses

Description: Specifies the ports and addresses on which the Director daemon will listen for Bacula Console connections.

Value(s): <IP-address-specification>

Data Type: string

Comment: If you use the DirAddresses directive, you must not use either a DirPort or a DirAddress directive in the same resource.

Example: See the following example:
DirAddresses = {
    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, that 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.

Dir Port

Description: Specifies the port (a positive integer) on which the Director daemon will listen for Bacula Console connections.

Value(s): <port-number>

Data Type: port

Default: 9101

Comment: This same port number must be specified in the Director resource of the Console configuration file. The default is 9101, so normally this directive need not be specified. This directive should not be used if you specify the DirAddresses (plural) directive.

Dir Address

Description: Makes the Director server (for the Console program) bind to the specified, which is either a domain name or an IP address specified as a dotted quadruple in string or quoted string format.

Value(s): <IP-address>

Data Type: string

Comment: Unlike the DirAddresses specification noted above, this directive only permits a single address to be specified. This directive should not be used if you specify a DirAddresses (plural) directive.

Dir Source Address

Description: Makes the Director server (when initiating connections to a storage or file daemon) source its connections from the specified address.

Value(s): <IP-address>

Data Type: string

Comment: Only a single IP address may be specified.

Events Retention

Description: The Events Retention directive defines the length of time that Bacula will keep events records in the Catalog database.

Value(s): <time>

Data Type: time

Default: 1 month

Comment: When this time period expires, and if the user runs the prune events command, Bacula will prune (remove) Events records that are older than the specified period. See the Configuration chapter of this manual for additional details of time specifications.

Statistics Retention

Description: Defines the length of time that Bacula will keep statistics job records in the Catalog database after the Job End time (JobHistory table).

Value(s): <time>

Data Type: time

Default: 5 years 2 months

Comment: When this time period expires, and if the user runs the prune stats command, Bacula will prune (remove) Job records that are older than the specified period. These statistics records aren’t used for restore purpose, but mainly for capacity planning, billings, etc. See the Configuration chapter of this manual for additional details of time specifications.

AutoPrune

Description: If this directive is specified and the value is no, it will override the value specified in all the other resources.

Value(s): <yes|no>

Data Type: boolean

Default: yes

Comment: If you set AutoPrune=no, pruning will not be done automatically, and your Catalog will grow in size each time you run a Job. Pruning affects only information in the catalog and not data stored in the backup archives (on Volumes). The prune bconsole command can be used to prune catalog records respecting the Client and/or the Pool FileRetention, JobRetention and VolumeRetention directives.

Customer Id

Description: Identifier which can be used for support purposes.

Value(s): <unique-id>

Data Type: string

Ver Id

Description: Identifier which can be used for support purposes.

Value(s): <unique-id>

Data Type: string

Maximum Console Connections

Description: Maximum number of Console Connections that could 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.

Fips Require

Description: Require FIPS cryptographic module to start the daemon.

Value(s): <yes|no>

Data Type: boolean

Comm Compression

Description: If the two Bacula components (DIR, FD, SD, bconsole) have the comm line compression enabled, the line compression will be enabled. The default value is yes.

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.

Tls Psk Enable

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.

Tls Dh File

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

Tls Authenticate

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

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.

Tls Verify Peer

Description: Verify peer certificate. Instructs server to request and verify the client’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.

Tls Key

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

Tls Enable

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.

Tls Allowed Cn

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".

Tls Ca Certificate Dir

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

Tls Require

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.

Tls Certificate

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.

Example:

File Daemon configuration file (bacula-fd.conf), resource configuration has TLS Verify Peer=no:
Director {
    Name = bacula-dir
    Password = "password"
    Address = director.example.com
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    TLS Verify Peer = no
    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
}

Tls Ca Certificate File

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 Director 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.