

The Catalog management is directly related to keeping backup Jobs data available, and it is often automatically triggered by finishing Jobs.
The second reason for carefully choosing the File Retention Period is because the database File records typically use the most storage space in the database. As a consequence, you must ensure that regular “pruning” of the database file records is done to keep your database from growing too big.
It is, however, possible to submit commands to Bacula to purge specific information, which will not respect configured retention periods. Naturally, this is something that should only be done with the greatest care.
Bacula itself does not have the concept of users or administrators, but has “Consoles” (see section (here)) that are designed to allow some users to have limited permissions regarding Bacula. However the BWeb Management Suite, the Bacula Enterprise Web-based tool for management and configuration, includes the concepts of users, groups and permissions.
The current Bacula Console comes in multiple versions:
Since the Console btool interacts with the Director through the network, the Console and Director btools do not necessarily need to run on the same machine. In fact, in an installation containing a single tape drive, a certain minimal knowledge of the Console btool may be needed in order for Bacula to be able to write on more than one Volume, because when Bacula requests a new one, it waits until the user, via the Console btool, indicates that the new Volume is mounted or labeled to be used.
Each daemon has its own configuration consisting of a set of Resource definitions. These resources are very similar from one service to another, but may contain different Directives (records) depending on the service. For example, in the Director's resource file, the Director directive resource defines the name of the Director, a number of global parameters and the password needed to access it from a Console. In the File Daemon configuration file, the Director directive resource specifies which Directors are permitted to use the File Daemon.
Director {
Name = the-name-of-the-director-dir
DIRport = 9101
QueryFile = "/opt/bacula/scripts/query.sql"
WorkingDirectory = "/opt/bacula/working"
PidDirectory = "/opt/bacula/working"
Maximum Concurrent Jobs = 10
Password = "password-for-the-console-to-access-the-director"
Messages = Daemon
Heartbeat Interval = 10
}
A Schedule definition to specify one full backup on the Sunday of the 2nd week of every second month starting in January, one differential on each Sunday except the Full's ones and an incremental backup six days a week:
Schedule {
Name = "NightlyCycle"
Run = Full jan,mar,may,jul,sep,nov 2nd sunday at 21:00
Run = Differential feb,apr,jun,aug,oct,dec 2nd sunday at 21:00
Run = Differential 1st,3rd-5th sunday at 21:00
Run = Incremental mon-sat at 21:00
}
FileSet definition, backing up /etc, /opt, /home, etc. excluding some directories
FileSet {
Name = "fs-websites"
Include {
Options {
Signature = MD5
Compression = GZIP
}
File = /etc
File = /opt
File = /root
File = /home
File = /var/log
}
Exclude {
File = /home/websites/tmp
File = /home/websites/www/tmp/cache
File = /opt/bacula/working
File = /opt/bacula/archive
File = /.journal
File = /.fsck
}
}
A Storage definition, as required by the Director, i.e. a name, an address, a port, and a media type. The director does not know about the hardware, only the storage daemon does:
Storage {
Name = Remote-Disk-Storage
Address = sd.bacula6.org
SDPort = 9103
Password = "password-for-the-director-to-access-the-storage"
Device = disk-autochanger
Media Type = da-mt
Maximum Concurrent Jobs = 50
Autochanger = Remote-Disk-Storage
}
A client to back up:
Client {
Name = client-to-back-up-fd
Address = client.bacula6.org
FDPort = 9102
Catalog = BaculaCatalog
Password = "password-for-the-director-to-access-the-client"
File Retention = 10 days
Job Retention = 25 days
AutoPrune = no
}
A pool definition:
Pool {
Name = the-pool-name
Pool Type = Backup
Recycle = yes
AutoPrune = no
Volume Retention = 30 days
Label Format = "pooldef-"
Maximum Volume Bytes = 8G
Maximum Volumes = 6
Storage = Remote-Disk-Storage
}
A JobDef to handle common definitions for several Jobs:
JobDefs {
Name = "common-job-definitions"
Type = Backup
Level = Incremental
Messages = Standard
Schedule = NightlyCycle
Priority = 10
#
# The following setting saves some time sending
# all the metadata at the end of the job
Spool Attributes = yes
#
# A way to keep all of your BSR (bootstrap) files
# in one place with the same naming conventions
Write Bootstrap = "/opt/bacula/bsr/%c_%n.bsr"
}
And then a Job using the above JobDefs:
Job {
Name = "back-up-job"
JobDefs = "common-job-definitions"
#
# The storage is defined inside the Pool Resource
# this is a best practice.
Pool = the-pool-name
Client = client-to-back-up-fd
FileSet = "fs-websites"
Schedule = NightlyCycle
#
# Below you have an example of how to include a file
# notice the "@" sign as first character
@/opt/bacula/etc/included-configuration-file.conf
}
Director {
Name = the-name-of-the-director-dir
Password = "password-for-the-director-to-access-the-client"
}
which authorizes the Director the-name-of-the-director-dir, knowing the client password to access to the client below
FileDaemon {
Name = client-to-back-up-fd
FDport = 9102
WorkingDirectory = /opt/bacula/working
Pid Directory = /opt/bacula/working
Maximum Concurrent Jobs = 20
}
Director {
Name = the-name-of-the-director-dir
Password = "password-for-the-director-to-access-the-storage"
}
authorizes the Director the-name-of-the-director-dir, knowing the storages password to access the storage daemon
Storage { # definition of myself
Name = bacula-storage-daemon-definition-sd
SDPort = 9103 # Director's port
WorkingDirectory = "/opt/bacula/working"
Pid Directory = "/opt/bacula/working"
Maximum Concurrent Jobs = 200
Heartbeat Interval = 10
}
and therefore to use the devices defined on the Storage Daemon side for example
#
# This is a two drive autochanger definition
Autochanger {
Name = disk-autochanger
Device = drive1, drive2
# No changer command needed for virtual autochangers
Changer Command = ""
# No changer device needed either
Changer Device = "/dev/null"
}
#
# Drive 1 definition
Device {
Name = drive1
Archive Device = /bacula/da1
Media Type = da-mt
Drive Index = 0
Label Media = yes
Random Access = yes
AutomaticMount = yes
RemovableMedia = no
AlwaysOpen = no
Maximum Concurrent Jobs = 20
}
#
# Drive 2 is pretty much the same in this case
Device {
Name = drive2
#
# This is the same archive device as in drive1 definition
Archive Device = /bacula/da1
Media Type = da-mt
# Another drive, another drive index
Drive Index = 1
Label Media = yes
Random Access = yes
AutomaticMount = yes
RemovableMedia = no
AlwaysOpen = no
Maximum Concurrent Jobs = 20
}
Director {
Name = the-name-of-the-director-dir
DIRport = 9101
address = localhost
Password = "password-for-the-console-to-access-the-director"
}
Figure (here) presents an example of a conf.d directory organization while the following is a tree representation of the same example.
conf.d/
|--- Console
| `-- v8-dir
| |--- bconsole.conf
| `-- Director
| `-- v8-dir.cfg
|--- Director
| `-- v8-dir
| |--- bacula-dir.conf
| |--- Catalog
| | `-- MyCatalog.cfg
| |--- Client
| | |--- v8-c1-fd.cfg
| | |--- v8-c2-fd.cfg
| | `-- v8-c3-fd.cfg
| |--- Console
| | `-- v8-mon.cfg
| |--- Director
| | `-- v8-dir.cfg
| |--- Fileset
| | |--- Catalog.cfg
| | |--- fs-postgres.cfg
| | `-- fs-tls.cfg
| |--- Job
| | |--- job-catalog.cfg
| | |--- job-postgres.cfg
| | |--- job-RestoreFiles.cfg
| | `-- job-tls.cfg
| |--- JobDefs
| | |--- defaultjob.cfg
| | `-- common.cfg
| |--- Messages
| | |--- Daemon.cfg
| | `-- Standard.cfg
| |--- Pool
| | |--- Dedup.cfg
| | |--- File.cfg
| | |--- common.cfg
| | `-- Scratch.cfg
| |--- Schedule
| | |--- FiveDays.cfg
| | |--- WeeklyCycleAfterBackup.cfg
| | `-- WeeklyCycle.cfg
| `-- Storage
| |--- Remote-Disk-Storage.cfg
| `-- File.cfg
|--- FileDaemon
| |--- v8-c1-fd
| | |--- bacula-fd.conf
| | |--- Director
| | | `-- v8-dir.cfg
| | |--- FileDaemon
| | | `-- v8-c1-fd.cfg
| | | `-- v8-mon.cfg
| | `-- Messages
| | `-- Standard.cfg
| |--- v8-c2-fd
| | |--- bacula-fd.conf
| | |--- Director
| | | |--- v8-dir.cfg
| | | `-- v8-mon.cfg
| | |--- FileDaemon
| | | `-- v8-c2-fd.cfg
| | `-- Messages
| | `-- Standard.cfg
| `-- v8-c3-fd
| |--- bacula-fd.conf
| |--- Director
| | `-- v8-dir.cfg
| |--- FileDaemon
| | `-- v8-c3-fd.cfg
| `-- Messages
| `-- Standard.cfg
`-- Storage
`-- v8-sd
|--- Autochanger
| `-- disk-autochanger.cfg
|--- bacula-sd.conf
|--- Device
| |--- drive1.cfg
| |--- drive2.cfg
| `-- File.cfg
|--- Director
| |--- v8-dir.cfg
| `-- v8-mon.cfg
|--- Messages
| `-- Standard.cfg
`-- Storage
`-- v8-sd.cfg
Both Data and Transport Encryption make use of industry-standard x509 Public Key Infrastructure, but the requirements differ a bit. In general, Data Encryption needs a minimum of infrastructure and configuration, while Transport Encryption may require much more effort of the Backup Administrator.
The client machine owner or administrator can be the only person responsible for the key files, which implies that additional tasks come into their realm of responsibility.
It is important to be aware that, while data itself is encrypted, metadata that is stored in the Catalog remains unencrypted - file and path names, in particular, are easily visible to third parties with access to the network or the catalog database.
The overhead to operate and set up such an environment can be considerable and is, in general, not an area of expertise for backup and storage administrators. However, if a maximum of security is desired, it provides industry-standard protection against any sort of unauthorized data snooping and as such is particularly important when backups are done through insecure networks like the internet.
Bacula can also use certificate-based authentication of its components, which is particularly useful if there are already certificates deployed for the involved computers.