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.
Director Start of the Director resource. One and only one director resource must be supplied.
Description: The director name used by the system administrator.
Value(s):
<name>Data Types: string
Default: N/A
Required: Yes
Options: None
Description = <text> The text field contains a description of the Director
that will be displayed in the graphical user interface. This directive is optional.
Password = <UA-password> Specifies the password that must be supplied for the
default Bacula Console to be authorized. 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.
MalwareDatabaseCommand = <Command> Specifies the command used to update the Malware
database. The default Malware database handler uses abuse.ch (get_malware_abuse.ch).
The database is synchronized automatically when an update is available.
Messages = <Messages-resource-name> The messages resource specifies where to
deliver Director messages that are not associated with a specific Job. 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. This
directive is required.
Plugin Directory = <Directory> 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. 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.
WorkingDirectory = <Directory> This directive is mandatory and specifies a
directory in which the Director may put its status files. This directory should be
used only by Bacula but may be shared by other Bacula daemons. However,
please note, 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.
PidDirectory = <Directory> This directive is mandatory and specifies a directory
in which the Director may put its process Id file. 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. This directive is required.
ScriptsDirectory = <Directory> This directive is optional and, if defined,
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. 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.
QueryFile = <Path> This directive is mandatory and specifies a directory and
file in which the Director can find the canned SQL statements for the query
command of the Console. Standard shell expansion of the 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.
HeartbeatInterval = <time-interval> This directive is optional and if specified
will cause the Director to set a keepalive interval (heartbeat) in seconds on each
of the sockets it opens for the Client resource. This value will override any specified
at the Director level. It is implemented only on systems (Linux, …) that provide
the setsockopt TCP_KEEPIDLE function. The default value is 300s.
MaximumConcurrentJobs = <number> where <number> is the maximum number of
total Director Jobs that should run concurrently. 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.
Description: Defines the maximum number of reload requests 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 Types: integer
Default:
32Required: Yes/No
Options: None
Comment: Increasing the default value should be considered carefully, as the operational consequences can be considerable.
Example:
Director { Name = localhost-dir Maximum Reload Requests = 64 ... }
FDConnectTimeout = <time> where <time> is the 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. The default is 3 minutes.
SDConnectTimeout = <time> where is <time> the 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. The default is 30 minutes.
DirAddresses = <IP-address-specification> Specify the ports and addresses on which
the Director daemon will listen for Bacula Console connections. Probably the
simplest way to explain this is to show an 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.
Note
If you use the DirAddresses directive, you must not use either a DirPort or a DirAddress directive in the same resource.
DirPort = <port-number> Specify the port (a positive integer) on which the
Director daemon will listen for Bacula Console connections. 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.
DirAddress = <IP-Address> This directive is optional, but if it is specified,
it will cause the Director server (for the Console program) to 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. If this directive is not specified, the Director will
bind to any available address (the default). Note, 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.
DirSourceAddress = <IP-Address> This record is optional, and if it is specified,
it will cause the Director server (when initiating connections to a storage or file
daemon) to source its connections from the specified address. Only a single IP
address may be specified. If this record is not specified, the Director server will
source its outgoing connections according to the system routing table (the default).
EventsRetention = <time> The Events Retention directive defines the length
of time that Bacula will keep events records in the Catalog database. When this
time period expires, and if the user runs the command 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.
The default is 1 month.
Statistics Retention = <time> The Statistics Retention directive defines the
length of time that Bacula will keep statistics job records in the Catalog database
after the Job End time (JobHistory table). 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.
Theses 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.
The default is 5 years.
AutoPrune = <yes|no> Normally, pruning of Files from the Catalog is specified on
a Client by Client basis in the resource with the AutoPrune directive. It is also
possible to overwrite the Client settings in the resource used by jobs, with the
AutoPrune, PruneFiles and PruneJobs directives.
If this directive is specified (not normally) and the value is no, it will override the value specified in all the other resources. The default is yes.
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.
CustomerId = <string> where <string> is an identifier which can be used for
support purpose.
VerId = <string> where <string> is an identifier which can be used for
support purpose. This string is displayed using the version command.
MaximumConsoleConnections = <number> where <number> is the maximum number of
Console Connections that could run concurrently. The default is set to 20, but
you may set it to a larger number.
FIPSRequire = <yes|no> Require FIPS cryptographic module to start the daemon.
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.
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.
See also
Go to:
Go back to the Director Resource Types page.
Go back to the Technical Reference for Director.