Autonomous Actions

CommunityEnterprise

This section provides a detailed explanation of the decisions the plugin makes automatically based on the environment variables and context in which it runs.

Auto-Skip of PVCs

The plugin automatically skips PVCs that are in Pending or Terminating state. It also ignores PVCs associated with other Bacula jobs.

Auto-Detection of Filesystem Format

Before starting a backup in snapshot or cloning mode, when the Persistent Volume Claim (PVC) is compatible with snapshot or cloning, the plugin checks whether the file systems of the Persistent Volume (PV) and the StorageClass match. If it cannot detect the file system on either resource or if they differ, the plugin records a warning in the job log but does not change the selected backup mode. Then, it proceeds with the originally chosen mode, though the backup may be highly prone to failure if the file systems are incompatible.

Regeneration of XFS UUID

In Snapshot and Clone backup modes, a full clone of the Persistent Volume Claim is created, including the volume’s UUID. This can cause issues when using file systems that are sensitive to duplicate UUIDs, such as XFS.

When this situation is detected, the plugin automatically performs the necessary actions to generate a new UUID for the cloned device, preventing potential conflicts.

Note

These actions are only triggered if the file system of the defined StorageClass is XFS and the longhorn_url parameter is defined.

Direct Selection of Backup StorageClass

In certain situations, it is advisable to perform the backup using a StorageClass different from the one defined for the original PVC.

If the plugin detects StorageClasses named bacula-backup-xfs and bacula-backup-ext4 in the environment, it will automatically use them. The selection depends on the file system used by the Persistent Volume.

Note

This is only useful when performing the backup in Clone or Snapshot mode.

Direct Node Selection when Attaching the Longhorn Cloned PVC

During backup operations Clone or Snapshot mode, if the provisioner is Longhorn, the plugin automatically detects the PVC’s access mode and determines on which node he cloned volume must not be attached.

If the access mode is RWO, the plugin avoids mounting the cloned volume on the same node as the PVC being backed up.

For other access modes, the plugin avoids mounting the cloned volume on the same node as the share-manager pod, which Longhorn uses to enable multi-access.

Using a StorageClass with Binding Mode “WaitForFirstConsumer”

When cloning a PVC in Clone or Snapshot mode, the StorageClass used for the backup may be configured with the binding mode “WaitForFirstConsumer” mode.

In this case, the plugin detects this situation and launches a simple Job to perform the binding. Once the PVC is available for backup, the plugin launches the Bacula backup pod.

Retry Standard Backup if Clone Backup Fails

When a PVC is cloned during a clone-based backup, the provisioner of the StorageClass may not be compatible and might create a clone without the content of the original PVC. During this operation, no error is reported.

To detect this situation, the plugin scans the cloned PVC after backup to verify that files are present. If no files are found, the plugin automatically retries the backup using the Standard backup method.