Client Resource

The Client Resource (or FileDaemon) resource defines the name of the Client (as used by the Director) as well as the port on which the Client listens for Director connections.

There must be one and only one Client resource in the configuration file, since it defines the properties of the current client program.

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.

The following is an example of a valid Client resource definition:

Client {
  Name = rufus-fd
  WorkingDirectory = $HOME/bacula/bin/working
  PIDDirectory = $HOME/bacula/bin/working
}

FileDaemon Start of the FileDaemon records.

Name:

Description: Must be used by the Director when connecting.

Value(s): <name>

Data Type: string

Required: Yes

Comment: Generally, it is a good idea to use a name related to the machine so that error messages can be easily identified if you have multiple Clients.

Working Directory

Description: Specifies a directory in which the File 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 daemons provided the daemon names on the definition are unique for each daemon.

Pid Directory

Description: Specifies a directory in which the File Daemon may put its process Id file files. The process Id file is used to shutdown Bacula and to prevent multiple copies of from running simultaneously.

Value(s): <directory>

Data Type: string

Required: Yes

Comment: Standard shell expansion of the is done when the configuration file is read so that values such as $HOME will be properly expanded. Typically on Linux systems, you will set this to: /var/run. If you are not installing Bacula in the system directories, you can use the Working Directory as defined above.

Client Rehydration

Description: Allows to try to do rehydration using existing local data on the Client at restore time.

Value(s): <directory>

Data Type:

Comment: In some cases, the use of this directive permits to transfer less data over the network during a restore.

Heartbeat Interval

Description: Defines an interval of time in seconds. For each heartbeat that the File Daemon receives from the Storage Daemon, it will forward it to the Director. In addition, if no heartbeat has been received from the Storage Daemon and thus forwarded the File Daemon will send a heartbeat signal to the Director and to the Storage daemon to keep the channels active.

Value(s): <time>

Data Type: time

Default: 5 minutes

Comment: 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.

Note

If you continue getting broken pipe error messages despite using the Heartbeat Interval and you are using Windows, you should consider upgrading your ethernet driver.

Lack of communications, or communications that get interrupted can also be caused by Linux firewalls where you have a rule that throttles connections or traffic.

Maximum Concurrent Jobs

Description: Maximum number of Jobs that should run concurrently.

Value(s): <number>

Data Type: positive integer

Default: 20

Comment: 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. If set to a large value, be careful to have this value higher than the Maximum Concurrent Jobs configured in the resource in the Director configuration file. Otherwise, backup jobs can fail due to the Director connection to FD be refused because Maximum Concurrent Jobs was exceeded on the FD side.

Maximum Job Error Count

Description: Error threshold for the Job, after reaching it Job will be failed.

Value(s): <number>

Data Type:

Comment: If this value is set to 0, job will continue to run no matter how many errors it encounters.

FD Addresses

Description: Specifies the ports and addresses on which the File daemon listens for Director connections.

Value(s): <IP-address>

Data Type: string

Example: See the following example:

FDAddresses = {
    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.

FD Port

Description: Specifies the port number on which the Client listens for Director connections.

Value(s): <port-number>

Data Type: port

Default: 9102

Comment: It must agree with the FDPort specified in the Client resource of the Director’s configuration file.

FD Address

Description: Cause the File Daemon server (for Director 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

Comment: If this record is not specified by a user, the File Daemon will bind to any available address.

FD Source Address

Description: Cause the File Daemon server (for Storage 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

Comment: If this record is not specified, the kernel will choose the best address according to the routing table.

SD Connect Timeout

Description: Defines an interval of time in seconds that the File Daemon will try to connect to the Storage Daemon.

Value(s): <time>

Data Type: time

Default: 30 minutes

Comment: If no connection is made in the specified time interval, the File

Daemon cancels the Job.

Maximum Network Buffer Size

Description: Specifies the initial network buffer size to use with the File Daemon. This size will be adjusted down if it is too large until it is accepted by the OS.

Value(s): <size>

Data Type: positive integer

Comment: Exercise caution when configuring this value, as setting it too high will result in a reduction of 512 bytes until the operating system is satisfied, potentially leading to a significant number of system calls. The default value is 65,536 bytes. The maximum value is 1,000,000 bytes.

Note

On certain Windows machines, there are reports that the transfer rates are very slow and this seems to be related to the default 65,536 size. On systems where the transfer rates seem abnormally slow compared to other systems, you might try setting the Maximum Network Buffer Size to 32,768 in both the File Daemon and in the Storage Daemon.

Maximum Bandwidth Per Job

Description: Specifies the maximum allowed bandwidth in bytes per second that a job may use.

Value(s): <speed>

Data Type: positive integer

Comment: You may specify the following speed parameter modifiers: kb/s (1,000 bytes per second), k/s (1,024 bytes per second), mb/s (1,000,000 bytes per second), or m/s (1,048,576 bytes per second).

The use of TLS, TLS PSK, CommLine compression and Deduplication can interfere with the value set with this Directive.

Comm Compression

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.

Disable Command

Description: Adds security to your File Daemon by disabling certain commands globally.

Value(s): <command>

Data Type: string list

Comment: The commands that can be disabled are:

backup
cancel
setdebug=
setbandwidth=
estimate
fileset
JobId=
level=
restore
endrestore
session
status
.status
storage
verify
RunBeforeNow
RunBeforeJob
RunAfterJob
Run
accurate

One or more of these command keywords can be placed in quotes and separated by spaces on the directive line. The commands must be written exactly as they appear above.

SD Packet Check

Description: If the integer is greater than zero, it is the number of packets that the FileDaemon will send to the Storage Daemon before sending a POLL request and waiting for the Storage Daemon answer. If the integer is zero, it turns off this feature.

Value(s): <number>

Data Type:

Comment: If the time between two POLL requests is too short (less than few seconds) and the number of bytes transferred is less than few hundred of MB, the value of the SD Packet Check is increased dynamically.

FIPS Require

Description: Require FIPS cryptographic module to start the daemon.

Value(s): <yes|no>

Data Type: boolean

Plugin Directory

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.

Plugin Options

Description: To configure non-job specific plugins (antivirus, security, etc.), it is possible to use the Plugin Options directive.

Value(s): <plugin-command-line>

Data Type: string

Comment: Multiple directives are allowed.

PKI Cipher

Description: Configures the data encryption to use a specific cipher.

Value(s): <cipher>

Data Type: string

Comment: The following ciphers are available: aes128, aes192, aes256 and blowfish.

PKI Digest

Description: Configures the data encryption to use a specific digest algorithm.

Value(s): <cipher>

Data Type: string

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

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 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: If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.

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

PKI Encryption See the Data Encryption chapter.

PKI Signatures See the Data Encryption chapter.

PKI Keypair See the Data Encryption chapter.

PKI Master Key See the Data Encryption chapter.

Note

TLS Directives in the FileDaemon (or Client) resource of bacula-fd.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.

Go back to the File Daemon (Client) Resource Types page.

Go back to the Technical Reference for File Daemon.

Go back to the main Technical Reference page.