The Client resource defines the attributes of the Clients that are
served by this Director; that is the machines that are to be backed up.
You will need one Client resource definition for each machine to be
backed up.
The following is an example of a valid Client resource definition:
Description: Where the <address> is a host name, a fully qualified domain name, or a network address in dotted quad notation for a Bacula File server daemon.
Description: When AllowFDConnections is set to true, the Director will accept incoming connections from the Client and will keep the socket open for a future use.
Value(s):<yes|no>
Data Type: boolean
Default: no
Comment: This configuration is useful if the Director cannot contact the File Daemon
directly. See the ConnectToDirector directive in the
client configuration for more information.
Description: This is the password to be used when establishing a connection with the File services.
Value(s):<password>
Data Type: password
Required: Yes
Comment: The Client configuration file on the machine to
be backed up must have the same password defined for this Director. 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 make the text random.
Description: Defines the length of time that Bacula will keep Snapshots in the Catalog database and on the Client after the Snapshot creation.
Value(s):<time>
Data Type: time
Default: 0 seconds
Comment: When this time period expires, and if
using the SnapshotPrune command, Bacula will prune (remove) Snapshot records
that are older than the specified Snapshot Retention period and will contact the
File Daemon to delete Snapshots from the system.
The Snapshot retention period is specified as seconds, minutes, hours, days, weeks,
months, quarters, or years. See the Configuration chapter for additional details of time specification.
The default is 0 seconds, Snapshots are deleted at the end of the backup. The
Job SnapshotRetention directive overwrites the Client SnapshotRetention
directive.
Description: Defines the length of time that Bacula will keep File records in the Catalog database after the End time of the Job corresponding to the File records.
Value(s):<time>
Data Type: time
Default: 2 months
Comment: When this time
period expires, and if AutoPrune is set to yes, Bacula will prune
(remove) File records that are older than the specified File Retention period.
Note
This affects only records in the catalog database. It does not affect your
archive backups.
File records may actually be retained for a shorter period than you specify on this
directive if you specify either a shorter Job Retention or a shorter
Volume Retention period. The shortest retention period of the three takes
precedence. The time may be expressed in seconds, minutes, hours, days, weeks,
months, quarters, or years. See the Configuration chapter for additional details of time specification.
Description: The Job Retention directive defines the length of time that Bacula will keep Job records in the Catalog database after the Job End time.
Value(s):<time>
Data Type: time
Default: 6 months
Comment: When this time period expires, and if AutoPrune is set to yes,
Bacula will prune (remove) Job records that are older than the specified Job
Retention period. As with the other retention periods, this affects only records in
the catalog and not data in your archive backup.
If a Job record is selected for pruning, all associated File and JobMedia records
will also be pruned regardless of the File Retention period set. As a consequence,
you normally will set the File retention period to be less than the Job retention
period. The Job retention period can actually be less than the value you specify here
if you set the Volume Retention directive in the Pool resource to a smaller
duration. This is because the Job retention period and the Volume retention period are
independently applied, so the smaller of the two takes precedence.
The Job retention period is specified as seconds, minutes, hours, days, weeks, months,
quarters, or years. See the Configuration chapter for
additional details of time specification.
Description: Defines the maximum number of Jobs with the current Client that can run concurrently.
Value(s):<number>
Data Type: positive integer
Default: 1
Comment: Note, this directive limits
only Jobs for Clients with the same name as the resource in which it appears. Any
other restrictions on the maximum concurrent jobs such as in the Director, Job, or
Storage 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. If set to a large value,
be careful to not have this value higher than the Maximum Concurrent Jobs configured
in the resource in the Client/File Daemon configuration file. Otherwise, backup jobs
can fail due to the Director connection to FD be refused because MCJ was exceeded on FD
side.
Description: The speed parameter specifies the maximum allowed bandwidth in bytes per second that a job may use when started for this Client.
Value(s):<speed>
Data Type: positive integer
Comment: You may specify the following case-insensitive 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 the Directive.
This functionality only affects the data transfer from the File Daemon to the Storage
Daemon.
Description: If the SD Calls Client directive is set to true in a resource any Backup, Restore, Verify Job where the client is involved, the client will wait for the Storage Daemon to contact it.
Value(s):<yes|no>
Data Type: boolean
Default: no
Comment: This directive
can be useful if your Storage Daemon is behind a firewall that permits outgoing
connections but not incoming connections.
Description: Where <address> is a host name, a FQDN, or an IPaddress.
Value(s):<address>
Data Type: string
Comment: The value specified here will be transmitted to the File
Daemon instead of the address that the Director uses to contact the
Storage Daemon. This FDStorageAddress will then be used by the File
Daemon to contact the Storage Daemon. This is 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.
The normal way to handle this situation is to use a canonical name such
as “storage-server” that will be resolved on the Director side as the
WAN address and on the Client side as the LAN address.
Name servers usually refer to this functionality as providing “views”,
i.e. zones with different contents depending on where a query originates.
It is possible to configure the FDStorageAddress in both the
Storage or Client resource.
Note that using the Client FDStorageAddress directive will not allow to use multiple
Storage Daemon, all Backup or Restore requests will be sent to the
specified FDStorageAddress.
Example:
Client {
Name = client1
Address = 65.1.1.5
FD Port = 9102
FD Storage Address = 10.0.0.1
...
}
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.
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:
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: 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: 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".
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.
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 Client 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.
