Bacula Enterprise Edition Documentation text image transdoc

Main

New Features in 13.0.0

Kubernetes Plugin

The Bacula Kubernetes plugin will save all the important Kubernetes resources which make up the application or service. The plugin has the following features:

Kubernetes cluster resources configuration backup
Ability to restore single Kubernetes configuration resource
Ability to restore Kubernetes resource configuration to local directory
Kubernetes Persistent Volumes data backup and restore
Ability to restore Kubernetes Persistent Volumes data to local directory
Ability to use new Kubernetes CSI driver snapshot features to perform Persistent Volume data backup
Ability to execute user defined commands on required Pod containers to prepare and clean data backup
Configure Kubernetes workload backup requirements directly with Pod annotations

More information about the Kubernetes plugin can be found on (here).

Storage Group

It is now possible to configure more than one Storage resource for each Job/Pool. Storage can be specified as a comma separated list of Storage resources to use.

Along with specifying a Storage list it is now possible to specify a Storage Group Policy which will be used for determining which Storage will be used for the Job. If no policy is specified, Bacula tries to use the first available Storage from the list.

If the first few storage daemons are unavailable due to network problems; broken or unreachable for some other reason, Bacula will use the first one from the list (sorted according to the policy used) which is network reachable and healthy.

Currently supported policies are:

ListedOrder: - This is the default policy. It uses the first available storage from the list provided
LeastUsed: - This policy scans all storage daemons from the list and chooses the one with the least number of Jobs currently running

Storage Groups may be used as follows (as a part of Job and Pool resources):

Job {
   ...
   Storage = File1, File2, File3
   ...
}

Pool {
   ...
   Storage = File4, File5, File6
   StorageGroupPolicy = LeastUsed
   ...
}

When a Job or Pool with a Storage Group is used, the user will observe some messages related to the choice of Storage such as:

messages
31-maj 19:23 VBox-dir JobId 1: Start Backup JobId 1, Job=StoreGroupJob.2021-05-31_19.23.36_03
31-maj 19:23 VBox-dir JobId 1: Possible storage choices: "File1, File2"
31-maj 19:23 VBox-dir JobId 1: Storage daemon "File1" didn't accept Device "FileChgr1-Dev1" because: 3924 Device "FileChgr1-Dev1" not in SD Device resources or no matching Media Type or is disabled.
31-maj 19:23 VBox-dir JobId 1: Selected storage: File2, device: FileChgr2-Dev1, StorageGroupPolicy: "ListedOrder"

New Accurate Option to Save Only File's Metadata

The new 'o' Accurate directive option for a Fileset has been added to save only the metadata of a file when possible.

The new 'o' option should be used in conjunction with one of the signature checking options (1, 2, 3, or 5). When the 'o' option is specified, the signature is computed only for files that have one of the other accurate options specified triggering a backup of the file (for example an inode change, a permission change, etc...).

In cases where only the file's metadata has changed (ie: the signature is identical), only the file's attributes will be backed up. If the file's data has been changed (hence a different singature), the file will be backed up in the usual way (attributes as well as the file's contents will be saved on the volume).

For example:

  Job {
    Name = JobTest
    JobDefs = DefaultJob
    FileSet = TestFS
    Accurate = yes
  }

  FileSet {
    Name = TestFS
    Options {
      Signature = MD5
      Accurate = pino5
    }
    File = /
  }

The backup job will compare permission bits, inodes, number of links and, if any of it changes, it will also compute file's signature to verify if only the metadata must be backed up or if the full file must be saved.

External LDAP Console Authentication

The new Bacula Plugable Authentication Module (BPAM) API framework introduced in Bacula 13.0 comes with the first plugin which handles user authentication against any LDAP Directory Server (including OpenLDAP and Active Directory). To enable the build of the LDAP Console Authentication plugin, add the ldap options to your ./configure command line as shown below:

./configure --with-ldap --enable-ldap-bpam [... other options]

# bconsole
*status director
...
 Plugin: ldap-dir.so
...

When the LDAP plugin is loaded you can configure a named console resource to use LDAP to authenticate users. BConsole will prompt for a User and Password and it will be verified by the Director. TLS PSK (activated by default) is recommended. To use this plugin, you have to specify the PluginDirectory Director resource directive, and add a new console resource directive Authentication Plugin as shown below:

Director {
  ...
  Plugin Directory = /opt/bacula/plugins
}

Console {
   Name = "ldapconsole"
   Password = "xxx"

   # New directive
   Authentication Plugin = "ldap:<parameters>"
   ...
}

where parameters are the space separated list of one or more plugin parameters:

url: - LDAP Directory service location, i.e. "url=ldap://10.0.0.1/"
binddn: - DN used to connect to LDAP Directory service to perform required query
bindpass: - DN password used to connect to LDAP Directory service to perform required query
query: - A query performed on the LDAP Directory serice to find user for authentication The query string is composed as <basedn>/<filter>. Where `<basedn> is a DN search starting point and <filter> is a standard LDAP search object filter which support dynamic string substitution: %u will be replaced by credential's username and %p by credential's password, i.e. query=dc=bacula,dc=com/(cn=%u).
starttls: - Instruct the BPAM LDAP Plugin to use the **StartTLS** extension if the LDAP Directory service supports it and fallback to no TLS if this extension is not available.
starttlsforce: - Does the same as the `starttls` setting does but reports error on fallback.

Working configuration examples:

bacula-dir.conf - Console resource configuration for BPAM LDAP Plugin with OpenLDAP authentication example.

Console {
 Name = "bacula_ldap_console"
 Password = "xxx"

 # New directive (on a single line)
 Authentication Plugin = "ldap: url=ldap://ldapsrv/ binddn=cn=root,dc=bacula,dc=com
                          bindpass=secret query=dc=bacula,dc=com/(cn=%u) starttls"
   ...
}

bacula-dir.conf - Console resource configuration for BPAM LDAP Plugin with Active Directory authentication example.

Console {
 Name = "bacula_ad_console"
 Password = "xxx"

 # New directive (on a single line)
 Authentication Plugin = "ldap: url=ldaps://ldapsrv/
       binddn=cn=bacula,ou=Users,dc=bacula,dc=com bindpass=secret
       query=dc=bacula,dc=com/(&(objectCategory=person)(objectClass=user)(sAMAccountName=%u))"
   ...
}

New Baculum features

The following features were introduced in version 11.0.6

New Advanced Schedule Settings

The schedule function has been reworked to support all possible schedule settings. Now it can be configured in five different ways: hourly, daily, weekly, monthly, and also custom for various uncommon settings.

New Copy and Migrate Job Wizards

Using the new wizards it is possible to easily create new copy and migrate jobs. The Wizard's steps are prepared and optimized to make the process as easy as possible.

New Director Page

This new page provides two major functions: The Director status and the Director configuration. The first one is for displaying in a graphical and textual way the Director status. The second one is for configuring all Director resources (Jobs, Clients, Pools, Storage ...etc.). From one place users can configure various Director resources.

Bulk Delete Volumes Action

This feature is available on the media page. Apart from prune and purge bulk actions, now users are also able to bulk delete volumes. It is possible by selecting volumes in the volume table and using this new delete volumes action.

Loading Pages Optimization

Pages have been optimized to faster loading. The entire Baculum Web interface works faster.

Directive Documentation

In all Bacula component configurations, for almost all directives, official Bacula documentation has been added. It is available directly within the web interface.

Tag Support

It is now possible to assign custom Tags to various catalog records in Bacula such as:

Volume
Client
Job

*tag
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
Available Tag operations:
     1: Add
     2: Delete
     3: List
Select Tag operation (1-3): 1
Available Tag target:
     1: Client
     2: Job
     3: Volume
Select Tag target (1-3): 1
The defined Client resources are:
     1: 127.0.0.1-fd
     2: test1-fd
     3: test2-fd
     4: test-rst-fd
     5: test-bkp-fd
Select Client (File daemon) resource (1-5): 1
Enter the Tag value: test1
1000 Tag added

*tag add client=127.0.0.1-fd name=#important"
1000 Tag added

*tag list client
+--------------+----------+--------------+
| tag          | clientid | client       |
+--------------+----------+--------------+
| #tagviamenu3 |        1 | 127.0.0.1-fd |
| test1        |        1 | 127.0.0.1-fd |
| #tagviamenu2 |        1 | 127.0.0.1-fd |
| #tagviamenu1 |        1 | 127.0.0.1-fd |
| #important   |        1 | 127.0.0.1-fd |
+--------------+----------+--------------+

*tag list client name=#important
+----------+--------------+
| clientid | client       |
+----------+--------------+
|        1 | 127.0.0.1-fd |
+----------+--------------+

It is possible to assign Tags to a Job record with the new 'Tag' directive in a Job resource.

  Job {
    Name = backup
    ...
    Tag = "#important", "#production"
  }

*tag list job
+--------------+-------+-------------+
| tag          | jobid | job         |
+--------------+-------+-------------+
| #important   |     2 | backup      |
| #production  |     2 | backup      |
+--------------+-------+-------------+

The Tags are also accessible from various BWeb Management Suite screens. (See (here)).

Support for SHA256 and SHA512 in FileSet

The support for strong signature algorithms SHA256 and SHA512 has been added to Verify Jobs. It is now possible to check if data generated by a Job that uses an SHA256 or SHA512 signature is valid.

  FileSet {
    Name = Linux-Etc
    Options {
      Signature = SHA512
      Verify = pins3
    }
    File = /etc
  }

In the FileSet Verify option directive, the following code has been added:

3: for SHA512
2: for SHA256

Windows Installer Silent Mode Enhancement

The following command line options may be used to control the regular Bacula installer values in silent mode:

-ConfigClientName
-ConfigClientPort
-ConfigClientPassword
-ConfigClientMaxJobs
-ConfigClientInstallService
-ConfigClientStartService
-ConfigStorageName
-ConfigStoragePort
-ConfigStorageMaxJobs
-ConfigStoragePassword
-ConfigStorageInstallService
-ConfigStorageStartService
-ConfigDirectorName
-ConfigDirectorPort
-ConfigDirectorMaxJobs
-ConfigDirectorPassword
-ConfigDirectorDB
-ConfigDirectorInstallService
-ConfigDirectorStartService
-ConfigMonitorName
-ConfigMonitorPassword

The following options control the components that will be installed:

-ComponentFile
-ComponentStorage
-ComponentTextConsole
-ComponentBatConsole
-ComponentTrayMonitor
-ComponentAllDrivesPlugin
-ComponentWinBMRPlugin
-ComponentCDPPlugin

Example

  bacula-win64-13.0.0.exe /S -ComponentFile \
      -ConfigClientName foo -ConfigClientPassword bar

Will install only file deamon with bacula-fd.conf configured.

  bacula-win64-13.0.0.exe /S -ComponentStorage \
     -ComponentFile-ConfigClientName foo \
     -ConfigClientPassword bar -ConfigStorageName foo2 \
     -ConfigStoragePassword bar2

Will install the Storage Deamon plus File Deamon with bacula-sd.conf and bacula-fd.conf configured.

New Message Identification Format

We are starting to add unique message indentifiers to each message (other than debug and the Job report) that Bacula prints. At the current time only two files in the Storage Daemon have these message identifiers and over time with subsequent releases we will modify all messages.

The message identifier will be kept unique for each message and once assigned to a message it will not change even if the text of the message changes. This means that the message identifier will be the same no matter what language the text is displayed in, and more importantly, it will allow us to make listing of the messages with in some cases, an additional explanation or instructions on how to correct the problem. All this will take several years since it is a lot of work and requires some new programs that are not yet written to manage these message identifiers.

The format of the message identifier is:

   [AAnnnn]

where A is an upper case character and nnnn is a four digit number, where the first character indicates the software component (daemon); the second letter indicates the severity, and the number is unique for a given component and severity.

For example:

   [SF0001]

The first character representing the component at the current time one of the following:

   S      Storage daemon
   D      Director
   F      File daemon

The second character representing the severity or level can be:

   A      Abort
   F      Fatal
   E      Error
   W      Warning
   S      Security
   I      Info
   D      Debug
   O      OK (i.e. operation completed normally)

So in the example above [SF0001] indicates it is a message id, because of the brackets and because it is at the beginning of the message, and that it was generated by the Storage Daemon as a fatal error.

As mentioned above it will take some time to implement these message ids everywhere, and over time we may add more component letters and more severity levels as needed.