Client Resource
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.
Client (or FileDaemon) Start of the Client directives.
Name = <name> The client name which will be used in the Job resource directive
or in the console run command. This directive is required.
Enabled = <yes|no> This directive allows you to enable or disable the resource.
If the resource is disabled, the Client will not be used.
Address = <address> 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. This directive is required.
FDPort = <port-number> Where the <port-number> is a port number at which the
Bacula File server daemon can be contacted. The default is 9102.
AllowFDConnections = <yes|no> 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. The Director will no longer use the Address to contact the
File Daemon. This configuration is useful if the Director cannot contact the File Daemon
directly. See the ConnectToDirector directive in the
client configuration for more information. The default value is no.
Catalog = <Catalog-resource-name> This specifies the name of the catalog resource
to be used for this Client. This directive is required.
Password = <password> This is the password to be used when establishing a
connection with the File services, so 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.
SnapshotRetention = <time-period-specification> The Snapshot Retention directive
defines the length of time that Bacula will keep Snapshots in the Catalog database
and on the Client after the Snapshot creation. 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.
FileRetention = <time-period-specification> The File Retention directive 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. 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.
The default is 60 days.
JobRetention = <time-period-specification> The Job Retention directive defines the
length of time that Bacula will keep Job records in the Catalog database after the
Job End time. 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.
The default is 180 days.
AutoPrune = <yes|no> If AutoPrune is set to yes (default), Bacula will
automatically apply the File retention period and the Job retention period for the
Client at the end of the Job. If you set AutoPrune=no, pruning will not be done,
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).
MaximumConcurrentJobs = <number> where <number> is the maximum number of
Jobs with the current Client that can run concurrently. 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.
MaximumBandwidthPerJob = <speed> The speed parameter specifies the maximum
allowed bandwidth in bytes per second that a job may use when started for this Client.
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.
Priority = <number> The number specifies the priority of this client relative to
other clients that the Director is processing simultaneously. The priority can range
from 1 to 1000. The clients are ordered such that the smaller number priorities are
performed first (not currently implemented).
SDCallsClient = <yes|no> 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. By default this directive is set to
false, and the Client will call the Storage daemon as it always has. This directive
can be useful if your Storage Daemon is behind a firewall that permits outgoing
connections but not incoming connections.
FDStorageAddress = <address>**
Where <address> is a host name, a FQDN, or an
IP address. 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.
Client {
Name = client1
Address = 65.1.1.5
FD Port = 9102
FD Storage Address = 10.0.0.1
...
}
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.
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.
The following is an example of a valid Client resource definition:
Client {
Name = bacula-fd
Address = bacula-client.example.com
Catalog = BaculaCatalog
Password = strong_password
}
See also
Go back to:
Go to:
Go back to the Director Resource Types page.
Go back to the Technical Reference for Director.