Backup and Restore Strategies
This article presents information regarding backup and restore strategies of the OpenStack Plugin.
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
Accurate backups
Additionally, various other plugins are available.
Instance Backup with OpenStack Plugin
With the instance backup strategy, the Bacula Enterprise OpenStack Plugin will save the instance volumes at the raw level within the OpenStack context.
The Bacula OpenStack Plugin will query the guest servers via the OpenStack API to read and save the content of server volumes by employing snapshots and the native Openstack Filesystem. During backups, the OpenStack Plugin will ensure the integrity of volume images and the configurations of guest servers, facilitating the restores with their original parameters.
All those operations are handled by an additional proxy server, which is described in the next section.
Proxy Server
To handle backup and restore operations in the OpenStack environment,it is essential to establish a proxy server. This particular server handles most of the operations (such as snapshot management, IO, etc.) during backup and restore. These operations will be discussed in more detail in the subsequent sections.
The proxy server must have the following characteristics:
Linux-based operating system
Bacula File Daemon installed (
bacula-enterprise-client package
) and running, configured as a Client Resource on the Bacula DirectorOpenStack Plugin (
bacula-enterprise-openstack-plugin package
) installedNetwork access to the OpenStack REST API.
Ingestion
The ingestion of a single virtual volume is a specific protocol which takes the following steps:
The proxy server generates a snapshot of the current volume.
The snapshot is then mounted as a new volume on the proxy server.
The list of modified block regions, along with their corresponding hashes and raw volume images, is exported to a Bacula Storage Daemon.
The volume is then detached from the proxy server.
Finally, the volume and its associated snapshot are deleted.
Backups can be executed for a guest server regardless of its power state (running or halted). Backups can be performed on any volume available in the Cinder block storage.
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
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 backup will create the following files 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 are important for Incremental backups. They contain the list of blocks and their checksum. In the next Incremental backup, if the checksum differs, the block is included in the backup.
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 |
+----------------------------------------------------------------------------------------------------------+
See also
Previous articles:
Next articles:
Go back to: OpenStack Plugin.