Backup and Restore Strategies

Enterprise

Bacula Enterprise Only

This solution is only available for Bacula Enterprise. For subscription inquiries, please reach out to sales@baculasystems.com.

This article presents information regarding backup and restore strategies of the OpenStack Plugin.

There are two primary approaches:

  • Install the Bacula Client on each Nova instance

  • Use the Bacula Enterprise OpenStack Plugin to back up and restore instances and volumes

These approaches address different recovery needs and can be used independently or together, depending on the required restore granularity, operational model, and recovery objectives.

Installing Bacula Client on Each Guest

This strategy involves the installation of a Bacula Enterprise File Daemon on each server, treating them as if they were standard physical clients. In order to optimize the I/O usage of servers hosted on the Nova compute service, the user will use Bacula’s Schedules, Priorities, and Maximum Concurrent Jobs to distribute backup jobs over the backup window. Given that all servers may share the same storage on Cinder block storage, running all backup jobs simultaneously could lead to a bottleneck on the volume/network subsystem, as Bacula will walk through all filesystems to open, read, close and stat files.

Installing a Bacula Enterprise File Daemon on each server allows for the management of virtual servers in the same manner as physical servers, while also enabling the use of all features offered by Bacula Enterprise, such as:

  • Quick restores of individual files

  • Checksums of individual files for Virus and Spyware detection

  • Verify Jobs

  • File/Directory exclusion (such as swap or temporary files)

  • File level compression

  • Additionally, various other plugins are available.

Instance, Volume and Image Backup with the OpenStack Plugin

The Bacula Enterprise OpenStack Plugin provides an infrastructure-level backup strategy.

With this approach, backups are performed through OpenStack rather than from inside each guest operating system. The plugin uses the OpenStack APIs to protect Nova instances, Cinder volumes, and related OpenStack image information at the infrastructure level. During backup, the plugin saves instance metadata and associated volume or image data so that instances, volumes, or images can be restored according to the supported OpenStack recovery workflow.

This approach is recommended when you need:

  • Instance-level, volume-level, or image-level protection

  • Backup of Nova instances without installing a Bacula Client inside every guest

  • Protection of Cinder volumes and OpenStack images

  • Recovery of an entire instance, volume, or image

The OpenStack Plugin is especially useful for disaster recovery and infrastructure-level recovery scenarios. It can protect complete virtual machine volumes and OpenStack configuration information without requiring direct access to the guest operating system.

However, because this strategy operates at the instance or volume level, it is not a replacement for in-guest backups when application-aware recovery is required.

The OpenStack Plugin allows two types of authentication to keystone:

  • Password: A project, username and password are used to identify the user. It allows to specify the OS_* variables or use an

OpenStack RC file containing the required variables. - Application Credential: with application credentials, the plugin uses the application credential ID and the application credential secret string which is not the user’s password.

Choosing a Strategy

The two strategies are complementary.

Use the Bacula Client inside each Nova instance when the main requirement is to protect and restore data from inside the operating system. This is the preferred method for application-aware backup, and workload-specific protection.

Use the OpenStack Plugin when the main requirement is to protect OpenStack instances, Cinder volumes, and related OpenStack metadata at the infrastructure level. This is the preferred method for whole-instance recovery, volume recovery, and centralized protection without installing a Bacula Client in every instance.

In many environments, the best practice is to combine both approaches:

  • Use the OpenStack Plugin for full instance or volume recovery.

  • Use the Bacula Client inside selected Nova instances for application-level recovery.

This combined strategy provides both infrastructure-level recovery and guest-level recovery, allowing administrators to restore either a complete instance or specific data inside the instance, depending on the incident.

All those operations are handled by an additional proxy server, which is described in the next section.

Proxy Server

OpenStack Plugin backup and restore operations are performed through a dedicated proxy server.

The proxy server is a Linux server where the Bacula Enterprise File Daemon and the Bacula Enterprise OpenStack Plugin are installed. It acts as the operational bridge between Bacula Enterprise and the OpenStack environment. The Bacula Director runs the backup or restore job against this proxy server, and the proxy server communicates with the OpenStack APIs to manage the required operations.

The proxy server handles most OpenStack-side backup and restore tasks, including snapshot management, volume attachment and detachment, data reading, and restore preparation. Because these operations may generate significant I/O and network activity, the proxy server should be sized appropriately for the expected number of protected instances, volumes, and concurrent jobs.

The proxy server must have:

  • A supported Linux operating system

  • The Bacula Enterprise File Daemon installed, running, and configured as a Bacula Client resource

  • The Bacula Enterprise OpenStack Plugin installed

  • Network access to the OpenStack REST APIs

  • Sufficient access rights in OpenStack to query instances, manage snapshots, attach and detach volumes, and perform restore operations

  • Adequate CPU, memory, network, and temporary working space for the expected backup and restore workload

In most deployments, the proxy server is not itself the backup target. Instead, it is the execution point from which Bacula Enterprise coordinates OpenStack backup and restore operations.

There are two possible approaches of using the Proxy Server:

  • Have one Proxy Server per OpenStack tenant/project to backup the instances, images and volumes in this specific project.

  • Have a single Proxy Server to backup instances, images and volumes in any tenant/project in the OpenStack cloud.

When using a single Proxy Server to backup and restore any instance, image or volume in any tenant/project, it’s required to use username/password authentication as application credentials are specfic to a project.

Minimum Requirements for the Proxy Server

The following minimum requirements apply to a proxy server running one OpenStack backup job:

  • 2 vCPUs

  • 4 GB RAM

  • disk space: only the .bmp and .sha files required for Incremental and Differential backups are stored on the Bacula proxy server.

  • the proxy server can be Ephemeral Disk Instances (Boot from Image) or Volume-Backed Instances (Boot from Volume). However, it should have at least one volume attached. This volume can be empty.

The .bmp and .sha files are working files used by the OpenStack Plugin to support Incremental and Differential backups. These files are small, but the total disk space required depends on the backup schedule and on the number of OpenStack jobs configured.

The files do not need to be retained after a new Full backup has run. However, each OpenStack job stores its own .bmp and .sha files, so environments with multiple jobs or long Full plus Incremental or Differential backup cycles will require more space.

Note

It is recommended that the /opt/bacula/working directory, which stores the .bmp and .sha files, is included in a plain text backup job. See more details in OpenStack Best Practices.

As a planning guideline, reserve approximately 500 KB per job run for both the .bmp and .sha files together. For example, if an environment keeps metadata for 100 job runs before the next Full backup, approximately 50 MB of proxy server disk space should be reserved for these files.

For concurrent OpenStack Instance backup jobs, increase the proxy server resources as follows:

  • Add approximately 500 MB of RAM per concurrent VM job.

  • Add 1 additional vCPU for every 2 to 3 concurrent jobs.

These values are minimum sizing guidelines. Larger environments, higher concurrency, slow storage backends, or heavy OpenStack API activity may require additional CPU, memory, network throughput, and temporary working capacity on the proxy server.

Ingestion

Ingestion is the process used by the OpenStack Plugin to read OpenStack volume data and send it to the Bacula Storage Daemon.

For each protected virtual volume, the plugin uses the proxy server to coordinate the ingestion workflow. In general, the process is as follows:

  1. The proxy server requests a snapshot of the current volume.

  2. The snapshot is made available as a temporary volume.

  3. The temporary volume is attached to the proxy server.

  4. The plugin reads the volume data from the proxy server.

  5. The plugin identifies the relevant data regions and associated checksums.

  6. The selected data blocks and metadata are sent to the Bacula Storage Daemon.

  7. The temporary volume is detached from the proxy server.

  8. The temporary volume and its associated snapshot are removed.

This process allows Bacula Enterprise to back up OpenStack volumes without requiring a Bacula Client inside the guest operating system.

Backups can be performed for Nova instances regardless of whether the guest is running or halted, provided the required OpenStack snapshot and volume operations are supported by the environment. The plugin can also protect Cinder volumes that are not attached to a Nova instance.

During backup, Bacula creates metadata and data files that describe the protected instance or volume. These files may include the instance name and UUID, instance configuration, block region maps, checksum information, and raw volume data. This information is used during restore to reconstruct the protected instance, volume, or image according to the selected restore workflow.

The backup will create the following backup files for each guest server:

  • A name file that associates the guest server name with its UUID: /@Openstack/nova/server/<serverUuid>_<serverName>.name

  • The configuration file of the guest server: /@Openstack/nova/server/<serverUuid>/<serverUuid>.conf

  • A list of data regions for each virtual volume: /@Openstack/nova/server/<serverUuid>/<volumeUuid>.bmp

  • A file to reconstruct data regions and their hashes for each virtual volume /@Openstack/nova/server/<serverUuid>/<volumeUuid>.bmpsha

  • A raw data file for each virtual volume: /@Openstack/nova/server/<serverUuid>/<volumeName>_<volumeUuid>.bvmdk

  • For image backed up server: /@Openstack/nova/server/<serverUuid>/<imageSnapshotName>_<imageSnapshotId>.img.bvmdk

  • For cross project server backup: /@Openstack/nova/server/<serverUuid>/OpenstackServerProjectMap.proj

The backup will also create the following backup files for each volume not attached to a server:

  • A list of data regions for each virtual volume: /@Openstack/cinder/volume/<volumeUuid>.bmp

  • A file to reconstruct data regions and their hashes for each virtual volume: /@Openstack/cinder/volume/<volumeUuid>.bmpsha

  • A raw data file for each virtual disk: /@Openstack/cinder/volume/<volumeName>_<volumeUuid>.bvmdk

Note

It is possible for a volume to have no name. In that case only their UUID will be displayed.

The plugin also creates working files on the proxy server that are used to support Incremental backups.

The following files are created in the /opt/bacula/working/openstack directory:

# ls -l
total 32
-rw-r-----. 1 root bacula  4609 Apr 30 15:54 openstack-cirros-instance1-job.2025-05-28_14.01.01_37_c4d13b99-5bdc-4b45-b673-bb6a81e443a1.bmp
-rw-r-----. 1 root bacula 21314 Apr 30 15:54 openstack-cirros-instance1-job.2025-05-28_14.01.01_37_c4d13b99-5bdc-4b45-b673-bb6a81e443a1.sha

These files contain block and checksum information from previous backups.

Note

These files should not be deleted. If the list of blocks and their checksum are not available, the plugin needs to rebuild this list, resulting in a backup all blocks. Then, a subsequent Incremental level backup will backup all the blocks, as the plugin lacks the information about the changed blocks.

At restore time the user can identify the guest server by using the UUID to mark the corresponding files:

+----------------------------------------------------------------------------------------------------------+
| filename                                                                                                 |
+----------------------------------------------------------------------------------------------------------+
| /@openstack/nova/flavor/ds1G_d2                                                                          |
| /@openstack/nova/server/22d27bdf-1cdb-461e-8f61-a641e36f9ed7_almalinux9-instance1.name                   |
| /@openstack/nova/server/22d27bdf-1cdb-461e-8f61-a641e36f9ed7/eafffb4a-634c-4751-93e2-aa75778b8e5b.bvmdk  |
| /@openstack/nova/server/22d27bdf-1cdb-461e-8f61-a641e36f9ed7/eafffb4a-634c-4751-93e2-aa75778b8e5b.bmpsha |
| /@openstack/nova/server/22d27bdf-1cdb-461e-8f61-a641e36f9ed7/eafffb4a-634c-4751-93e2-aa75778b8e5b.bmp    |
| /@openstack/nova/server/22d27bdf-1cdb-461e-8f61-a641e36f9ed7/22d27bdf-1cdb-461e-8f61-a641e36f9ed7.conf   |
+----------------------------------------------------------------------------------------------------------+

Note

When performing a cross project restore, the instance volume(s) are restored to the same project as the proxy VM, as they need to be attached to it for the restore. After the volume is restored, the volume is transferred to the same project as the restored instance.

2026-06-26 16:45:12 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Could not setup openstack client at default ENDPOINT=http://10.0.100.40/identity CAUSE=Not Found STATUS=404 Openstack client setup on alternative endpoint SUCCESS
2026-06-26 16:45:12 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Openstack client setup SUCCESS
2026-06-26 16:45:13 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: All volumes listed on proxy-server bacula-proxy-vm-rocky9 were located in the plugin environment : plugin location confirmed
2026-06-26 16:45:13 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Starting new server restore for "69a71d47-4087-4dde-95e0-4e940f0b560d"
2026-06-26 16:45:13 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Restoring cinder volume "3f0949ed-416e-4455-9797-119a47113436" from server "69a71d47-4087-4dde-95e0-4e940f0b560d"
2026-06-26 16:45:13 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Adding volume restore "3f0949ed-416e-4455-9797-119a47113436" to server restore "69a71d47-4087-4dde-95e0-4e940f0b560d"
2026-06-26 16:52:19 am-r9-bee-bweb-openstack-tst-sd JobId 1116: Elapsed time=00:07:20, Transfer rate=48.82 M Bytes/second
2026-06-26 16:52:32 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Creating volume from configuration to restore
2026-06-26 16:52:32 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Attach restore volume to proxy server
2026-06-26 16:52:32 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Finding device path
2026-06-26 16:52:32 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: MSG=Could not find truncated ID=49edf70c-c256-45c7-a in ID/Device map RETRY_NB=0 TOTAL_RETRY=15 INTERVAL=40
2026-06-26 16:52:32 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Found device PATH=/dev/vdb volumeId=49edf70c-c256-45c7-a1fa-228492584fa3
2026-06-26 16:52:32 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Volume creation and attach for restore SUCCESS
2026-06-26 16:52:32 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Restoring volume "3f0949ed-416e-4455-9797-119a47113436" as "49edf70c-c256-45c7-a1fa-228492584fa3"
2026-06-26 16:52:36 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Cinder volume restore SUCCESS
2026-06-26 16:52:37 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Finalizing server restore
2026-06-26 16:52:37 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Starting pairing between server restore and unmatch volumes
2026-06-26 16:52:37 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: After unmatch volume pair all there are still 0 volumes without a match
2026-06-26 16:52:37 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Detach all restored volume from proxy server
2026-06-26 16:52:38 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Restore volume detach SUCCESS
2026-06-26 16:52:53 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Restoring nova server "rocky9-instance2 (69a71d47-4087-4dde-95e0-4e940f0b560d)" 1 volumes to attach
2026-06-26 16:52:54 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Start server restore for "rocky9-instance2 (69a71d47-4087-4dde-95e0-4e940f0b560d)" as "rocky9-instance2-1"
2026-06-26 16:52:54 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Orignal flavor lookup success
2026-06-26 16:52:54 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Server build
2026-06-26 16:52:54 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Cross project found for server ID=69a71d47-4087-4dde-95e0-4e940f0b560d PROJECT=serverId=69a71d47-4087-4dde-95e0-4e940f0b560d projectName=demo2 projectId=5d66e7a2c4894ef9841883393fbe1b18
2026-06-26 16:52:54 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Start volume transfer volume=49edf70c-c256-45c7-a1fa-228492584fa3
2026-06-26 16:52:55 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Start 1 volume volume migration to org.openstack4j.openstack.identity.v3.domain.KeystoneProject{id=5d66e7a2c4894ef9841883393fbe1b18, description=, name=demo2, links={self=http://10.0.100.40/identity/v3/projects/5d66e7a2c4894ef9841883393fbe1b18}, parentId=default, enabled=true}
2026-06-26 16:52:55 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Trying to get OSClient for endpoint=http://10.0.100.40/identity user=admin password=********** domain=Default project=demo2
2026-06-26 16:52:55 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Trying to setup client connection with alternative endpoint http://10.0.100.40/identity/v3/
2026-06-26 16:52:55 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Trying to get OSClient for endpoint=http://10.0.100.40/identity/v3/ user=admin password=********** domain=Default project=demo2
2026-06-26 16:52:55 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Could not setup openstack client at default ENDPOINT=http://10.0.100.40/identity CAUSE=Not Found STATUS=404 Openstack client setup on alternative endpoint SUCCESS
2026-06-26 16:52:55 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Openstack client setup SUCCESS
2026-06-26 16:52:57 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Volume cross transfer ID=0efda2d8-4793-4e38-bbd8-4bd66f0acdd8 VOLUME=49edf70c-c256-45c7-a1fa-228492584fa3 ACCEPTED
2026-06-26 16:52:57 bacula-proxy-vm-rocky9-fd JobId 1116: openstack: Volume transfer VOLUME=49edf70c-c256-45c7-a1fa-228492584fa3 SUCCESS

See also

Previous articles:

Next articles:

Go back to: OpenStack Plugin.