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.