Bacula Enterprise Edition Documentation text image transdoc

Main

Client/File daemon Configuration

The Client (or File Daemon) Configuration is one of the simpler ones to specify. Generally, other than changing the Client name so that error messages are easily identified, you will not need to modify the default Client configuration file.

For a general discussion of configuration file and resources including the data types recognized by Bacula, please see the Configuration chapter of this manual. The following Client Resource definitions must be defined:

Client - to define what Clients are to be backed up.
Director - to define the Director's name and its access password.
Messages - to define where error and information messages are to be sent.

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

Client (or FileDaemon)

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

Name = <name>

The client name that must be used by the Director when connecting. 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. This directive is required.

Working Directory = <Directory>

This directive is mandatory and specifies a directory in which the File daemon may put its status files. This directory should be used only by Bacula, but may be shared by other Bacula daemons provided the daemon names on the Name definition are unique for each daemon. This directive is required.

On Win32 systems, in some circumstances you may need to specify a drive letter in the specified working directory path. Also, please be sure that this directory is writable by the SYSTEM user otherwise restores may fail (the bootstrap file that is transferred to the File daemon from the Director is temporarily put in this directory before being passed to the Storage daemon).

Pid Directory = <Directory>

This directive is mandatory and 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 Bacula from running simultaneously. This record is required. Standard shell expansion of the <Directory> 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.

Dedup Index Directory = <Directory>

This directive is deprecated and replaced by “Client Rehydration”.

This directive is optional and specifies a directory in which the File Daemon may put a index cache of all blocks read during a Backup job.

Standard shell expansion of the <Directory> is done when the configuration file is read so that values such as $HOME will be properly expanded.

ClientRehydration = <Directory>

This directive is optional and allows to try to do rehydration using existing local data on the Client at restore time. In some cases, the use of this directive permits to transfer less data over the network during a restore. The default value is no.

Heartbeat Interval = <time-interval>

This record 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. The default interval is 300s. This feature is particularly useful if you have a router such as 3Com 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.

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. This is a known problem with NVidia NForce 3 drivers (4.4.2 17/05/2004), or try the following workaround suggested by Thomas Simmons for Win32 machines:

Browse to: Start → Control Panel → Network Connections

Right click the connection for the nvidia adapter and select properties. Under the General tab, click “Configure...”. Under the Advanced tab set “Checksum Offload” to disabled and click OK to save the change.

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 = <number>

where <number> is the maximum number of Jobs that should run concurrently. 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. If set to a large value, please be careful to have this value higher than the Maximum Concurrent Jobs configured in the Client 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 FD side.

FDAddresses = <IP-address-specification>

Specify the ports and addresses on which the File daemon listens for Director connections. Probably the simplest way to explain is to show an 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.

FDPort = <port-number>

This specifies the port number on which the Client listens for Director connections. It must agree with the FDPort specified in the Client resource of the Director's configuration file. The default is 9102.

FDAddress = <IP-Address>

This record is optional, and if it is specified, it will 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. If this record is not specified, the File daemon will bind to any available address (the default).

FDSourceAddress = <IP-Address>

This record is optional, and if it is specified, it will 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. If this record is not specified, the kernel will choose the best address according to the routing table (the default).

SDConnectTimeout = <time-interval>

This record defines an interval of time that the File daemon will try to connect to the Storage daemon. The default is 30 minutes. If no connection is made in the specified time interval, the File daemon cancels the Job.

Maximum Network Buffer Size = <bytes>

where <bytes> 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. Please use care in setting this value since if it is too large, it will be trimmed by 512 bytes until the OS is happy, which may require a large 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 = <speed>

The speed parameter specifies the maximum allowed bandwidth in bytes per second that a job may use. 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 interfer with the value set with the Directive.

CommCompression = <yes|no>

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.

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.

DisableCommand = <cmd>

The Disable Command adds security to your File daemon by disabling certain commands globally. 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 Disable Command directive line. Note: the commands must be written exactly as they appear above.

TLS Enable = <yes|no>

Enable TLS support. 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 PSK Enable = <yes|no>

Enable or Disable automatic TLS PSK support. 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 Require = <yes|no>

Require TLS or TLS-PSK encryption. 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 Authenticate = <yes|no>

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.

If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.

TLS Certificate = <Filename>

The full path and filename of a PEM encoded TLS certificate. 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.

Example:

File Daemon configuration file (bacula-fd.conf), Director 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
  }

Having TLS Verify Peer = no, means the File Daemon, server context, will not check Directorâs public certificate, client context. There is no need to specify TLS Certificate File neither TLS Key directives in the Client resource, director configuration file. We can have the below client configuration in bacula-dir.conf:

  Client {
    Name = client1-fd
    Address = client1.example.com
    FDPort = 9102
    Catalog = MyCatalog
    Password = "password"
    ...
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem
  }

TLS Key = <Filename>

The full path and filename of a PEM encoded TLS private key. It must correspond to the TLS certificate.

TLS Verify Peer = <yes|no>

Verify peer certificate. Instructs server to request and verify the client's X.509 certificate. 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 TLSAllowed CN onfiguration directive 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 = <string list>

Common name attribute of allowed peer certificates. 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). 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".

TLS CA Certificate File = <Filename>

The full path and filename specifying a PEM encoded TLS CA certificate(s). 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 CA Certificate Dir = <Directory>

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.

TLS DH File = <Directory>

Path to PEM encoded Diffie-Hellman parameter file. 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

PKI Cipher

This directive is optional and if specified will configure the data encryption to use a specific cipher. The default cipher is AES 128 CBC.

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

PKI Digest

This directive is optional and if specified will configure the data encryption to use a specific digest algorithm. The default cipher is SHA1 or SHA256 depending on the version of OpenSSL.

The following digest are available: md5, sha1, sha256.

PKI Encryption

See the Data Encryption chapter of this manual.

PKI Signatures

See the Data Encryption chapter of this manual.

PKI Keypair

See the Data Encryption chapter of this manual.

PKI Master Key

See the Data Encryption chapter of this manual.

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

Client {                              # this is me
  Name = rufus-fd
  WorkingDirectory = $HOME/bacula/bin/working
  Pid Directory = $HOME/bacula/bin/working
}

The Director Resource

The Director resource defines the name and password of the Directors that are permitted to contact this Client.

Director

Start of the Director records. There may be any number of Director resources in the Client configuration file. Each one specifies a Director that is allowed to connect to this Client.

Name = <name>

The name of the Director that may contact this Client. This name must be the same as the name specified on the Director resource in the Director's configuration file. Note, the case (upper/lower) of the characters in the name are significant (i.e. S is not the same as s). This directive is required.

Password = <password>

Specifies the password that must be supplied for a Director to be authorized. This password must be the same as the password specified in the Client resource in the Director's configuration file. This directive is required.

DirPort = <number>

Specify the port to use to connect to the Director. This port must be identical to the DIRport specified in the Director resource of the Director's configuration file. The default is 9101 so this directive is not normally specified.

Address = <address>

Where the address is a host name, a fully qualified domain name, or a network address used to connect to the Director. This directive is required when ConnectToDirector is enabled.

ConnectToDirector = <yes|no>

When the ConnectToDirector directive is set to true, the Client will contact the Director according to the Schedule rules. The connection initiated by the Client will be then used by the Director to start jobs or issue bconsole commands. If the Schedule directive is not set, the connection will be initiated when the file daemon starts. The connection will be reinitialized every ReconnectionTime. This directive can be useful if your File Daemon is behind a firewall that permits outgoing connections but not incoming connections.

ReconnectionTime = <time>

When the Director resource of the FileDaemon is configured to connect the Director with the ConnectToDirector directive, the connection initiated by the FileDeamon to the Director will be reinitialized at a regular interval specified by the ReconnectionTime directive. The default value is 40 mins.

Schedule = <sched-resource>

The Schedule directive defines what schedule is to be used for Client to connect the Director if the directive ConnectToDirector is set to true.

This directive is optional, and if left out, the Client will initiate a connection automatically at the start of the daemon. Although you may specify only a single Schedule resource for any Director resource, the Schedule resource may contain multiple Connect directives, which allow you to initiate the Client connection at many different times, and each Connect directive permits to set the the Max Connect Time directive.

Maximum Bandwidth Per Job = <speed>

The speed parameter specifies the maximum allowed bandwidth in bytes per second that a job may use when started from this Director. 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).

DisableCommand = <cmd>

The Disable Command adds security to your File daemon by disabling certain commands for the current Director. More information about the syntax can be found on (here).

Monitor = <yes|no>

If Monitor is set to no (default), this director will have full access to this Client. If Monitor is set to yes, this director will only be able to fetch the current status of this Client.

Please note that if this director is being used by a Monitor, we highly recommend to set this directive to yes to avoid serious security problems.

TLS Enable = <yes|no>

Enable TLS support. 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 PSK Enable = <yes|no>

TLS Require = <yes|no>

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 Authenticate = <yes|no>

If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.

TLS Certificate = <Filename>

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), Director 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
  }

  Client {
    Name = client1-fd
    Address = client1.example.com
    FDPort = 9102
    Catalog = MyCatalog
    Password = "password"
    ...
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem
  }

TLS Key = <Filename>

The full path and filename of a PEM encoded TLS private key. It must correspond to the TLS certificate.

TLS Verify Peer = <yes|no>

TLS Allowed CN = <string list>

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

TLS CA Certificate File = <Filename>

TLS CA Certificate Dir = <Directory>

TLS DH File = <Directory>

To generate the parameter file, you may use openssl:

openssl dhparam -out dh4096.pem -5 4096

Thus multiple Directors may be authorized to use this Client's services. Each Director will have a different name, and normally a different password as well.

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

#
# List Directors who are permitted to contact the File daemon
#
Director {
  Name = HeadMan
  Password = very_good                # password HeadMan must supply
}
Director {
  Name = Worker
  Password = not_as_good
  Monitor = Yes
}

The Schedule Resource

The Schedule resource provides a means of automatically scheduling the connection of the Client to the Director. Each Director resource can have a different Schedule resource.

Schedule

Start of the Schedule directives. No Schedule resource is required. If no Schedule is used, the Client will connect automatically to the Director at the startup.

Name = <name>

The name of the schedule being defined. The Name directive is required.

Enabled = <yes|no>

This directive allows you to enable or disable the Schedule resource.

Connect = <Connect-overrides> <Date-time-specification>

The Connect directive defines when a Client should connect to a Director. You may specify multiple Connect directives within a Schedule resource. If you do, they will all be applied (i.e. multiple schedules). If you have two Connect directives that start at the same time, two connections will start at the same time (well, within one second of each other). It is not recommended to have multiple connections at the same time.

Connect-options are specified as: keyword=value where the keyword is MaxConnectTime and the value is as defined on the respective directive formats for the Job resource. You may specify multiple Connect-options on one Connect directive by separating them with one or more spaces or by separating them with a trailing comma. For example:

MaxConnectTime=<time-spec>: specifies how much time the connection will be attempt and active.

The <Date-time-specification> is similar to what exists for Job scheduling. See (here) for more information.

An example schedule resource that is named WeeklyCycle and connects a director each Sunday at 2:05am and an on Monday through Saturday at 2:05am is:

Schedule {
  Name = "WeeklyCycle"
  Connect = MaxConnectTime=2h sun at 2:05
  Connect = MaxConnectTime=2h mon-sat at 2:05
}

In this example, the Job for this client should be schedule to start between 2:05 and 4:05 during the week. The Bacula administrator will be able to use commands such as status client or estimate betwen 2:05 and 4:05.

The Message Resource

Please see the Messages Resource Chapter of this manual for the details of the Messages Resource.

There must be at least one Message resource in the Client configuration file.

The Statistics Resource

The Statistics Resource defines the statistic collector function that can send information to a Graphite instance, to a CSV file or to bconsole with the statistics command (See (here) for more information).

Statistics

Start of the Statistics resource. Statistics directives are optional.

Name = <name>

The Statistics directive name is used by the system administrator. This directive is required.

Description = <string>

The text field contains a description of the Statistics resource that will be displayed in the graphical user interface. This directive is optional.

Interval = <time-interval>

The Intervall directive instructs the Statistics collector thread how long it should sleep between every collection iteration. This directive is optional and the default value is 300 seconds.

Type = <CSV|Graphite>

The Type directive specifies the Statistics backend, which may be one of the following: CSV or Graphite. This directive is required.

CSV is a simple file level backend which saves all required metrics with the following format to the file: “<time>, <metric>, <value>\n”

Where <time> is a standard Unix time (a number of seconds from 1/01/1970) with local timezone as returned by a system call time(), <metric> is a Bacula metric string and <value> is a metric value which could be in numeric format (int/float) or a string "True" or "False" for boolean variable. The CSV backend requires the File = parameter.

Graphite is a network backend which will send all required metrics to a Graphite server. The Graphite backend requires the Host = and Port = directives to be set.

If the Graphite server is not available, the metrics are automatically spooled in the working directory. When the server can be reached again, spooled metrics are despooled automatically and the spooling function is suspended.

Metrics = <metricspec>

The Metrics directive allow metric filtering and <metricspec> is a filter which enables to use * and ? characters to match the required metric name in the same way as found in shell wildcard resolution. You can exclude filtered metric with ! prefix. You can define any number of filters for a single Statistics. Metrics filter is executed in order as found in configuration. This directive is optional and if not used all available metrics will be saved by this collector backend.

Example:

# Include all metric starting with "bacula.jobs"
Metrics = "bacula.jobs.*"

# Exclude any metric starting with "bacula.jobs"
Metrics = "!bacula.jobs.*"

Prefix = <string>

The Prefix allows to alter the metrics name saved by collector to distinguish between different installations or daemons. The prefix string will be added to metric name as: “<prefix>.<metric_name>” This directive is optional.

File = <filename>

The File is used by the CSV collector backend and point to the full path and filename of the file where metrics will be saved. With the CSV type, the File directive is required. The collector thread must have the permissions to write to the selected file or create a new file if the file doesn't exist. If collector is unable to write to the file or create a new one then the collection terminates and an error message will be generated. The file is only open during the dump and is closed otherwise. Statistics file rotation could be executed by a mv shell command.

Host = <hostname>

The Host directive is used for Graphite backend and specify the hostname or the IP address of the Graphite server. When the directive Type is set to Graphite, the Host directive is required.

Host = <number>

The Port directive is used for Graphite backend and specify the TCP port number of the Graphite server. When the directive Type is set to Graphite, the Port directive is required.

Example Client Configuration File

An example File Daemon configuration file might be the following:

#
# Default  Bacula File Daemon Configuration file
#
#  For Bacula release 1.35.2 (16 August 2004) -- gentoo 1.4.16
#
# There is not much to change here except perhaps to
#   set the Director's name and File daemon's name
#   to something more appropriate for your site.
#
#
# List Directors who are permitted to contact this File daemon
#
Director {
  Name = rufus-dir
  Password = "/LqPRkX++saVyQE7w7mmiFg/qxYc1kufww6FEyY/47jU"
}
#
# Restricted Director, used by tray-monitor to get the
#   status of the file daemon
#
Director {
  Name = rufus-mon
  Password = "FYpq4yyI1y562EMS35bA0J0QC0M2L3t5cZObxT3XQxgxppTn"
  Monitor = yes
}
#
# "Global" File daemon configuration specifications
#
FileDaemon {                          # this is me
  Name = rufus-fd
  WorkingDirectory = $HOME/bacula/bin/working
  Pid Directory = $HOME/bacula/bin/working
}
# Send all messages except skipped files back to Director
Messages {
  Name = Standard
  director = rufus-dir = all, !skipped
}