OpenStack Cinder Backup. How to Backup OpenStack Cinder Volumes with Bacula?

More and more organizations rely on cloud infrastructure for many of their daily tasks, putting a lot of pressure on these systems from the continuity standpoint. The importance of regular backups with substantial security levels is difficult to overestimate, especially in enterprise-grade environments with complex platforms. Such combinations of use cases tend to demand the highest possible level of availability and data integrity at all times.

OpenStack Cinder is one of many examples of such valuable environments – a core component of the cloud environment under the same name, providing persistent block storage for both containers and virtual machines when necessary. It provides persistent storage to running instances by managing and provisioning block storage resources, such as creating, attaching, and managing volumes.

Cinder allows users to leverage a variety of storage backends (such as LVM, Ceph, and NFS) and integrates with OpenStack’s other components, like Nova (the compute service), to facilitate efficient data storage and retrieval across different cloud environments. It supports features like snapshots, volume backups, and multi-tenant storage management, making it a key component in cloud infrastructure.

Our goal in this article is to showcase the topic of OpenStack Cinder and its backup capabilities in terms of both built-in and third-party solutions.

Definition of OpenStack Cinder

OpenStack Cinder (or Block Storage service) is an essential element of the cloud computing platform called OpenStack. Its primary purpose is to offer persistent block-level storage devices in OpenStack’s computing instances – containers, VMs, etc. Similar to many other elements of OpenStack, Cinder is designed to store resources in a specific fashion that makes them accessible for consumption for another element – OpenStack Compute (Nova).

Other notable features of OpenStack Cinder include:

• Volume management, including creation and deletion.
• API support for extensive management tasks.
• Volume snapshot creation.
• Ability to attach and detach volumes to and from instances.
• Flexibility to support different storage back-ends.

Even though OpenStack Cinder is technically a module of a larger OpenStack environment, it is also comprises a number of important modules, such as cinder-api, cinder-scheduler, cinder-volume, and cinder-backup.

• cinder-api is the module responsible for processing API requests before routing them to other Cinder modules. It works both with regular APIs of OpenStack and a separate API for administrative purposes.
• cinder-scheduler is a module responsible for dispatching block storage requests by using a configurable scheduler. The point of this scheduler is to determine the storage node that would have to handle that specific request.
• cinder-volume is used to manage block storage devices’ lifecycles, relying on driver architecture to interact with different storage providers.
• cinder-backup is another component that can be used to create Cinder backups and transfer them to certain backup storage providers (optional).

All four of these modules operate together in order to deliver a scalable and versatile block storage solution in OpenStack deployments.

The necessity to backup OpenStack Cinder environments

Cinder is an important factor when it comes to storing many different forms of valuable information, such as databases, essential application data, operating system volumes, and more. The lack of a proper backup strategy for this data brings a lot of potential risks to light, including:

• Issues with application data consistency across backups; it is essential for the success of data recovery efforts.
• Absence of demonstrable data protection capabilities; most regulations demand comprehensive data security systems in action for all companies that operate in a specific field or industry.
• Higher potential for data loss; the inability to recover from software bugs, hardware failures, or human errors is a massive downside for any business.
• Lack of disaster recovery capabilities; an extension of the previous point delegated to the most problematic issues that may result in all of the business data being corrupted or deleted without backups in place.

An abundance of potential risks is the main reason why backup and recovery measures are heavily recommended for every OpenStack Cinder environment. In this context, a lot of users would resort to built-in capabilities of OpenStack itself for the sake of convenience. However, these backup capabilities have their fair share of issues that we are going to discuss below.

Built-in OpenStack Cinder backup capabilities

There are two primary backup features in OpenStack Cinder that can be used for backup purposes – native OpenStack Cinder snapshots and Cinder Backup Service.

Native OpenStack Cinder snapshots

Point-in-time volume copies of Cinder volumes in the form of snapshots can be created with ease using a native OpenStack Cinder snapshot feature. The capability is tightly integrated with OpenStack itself, creating a convenient short-term backup with no real redundancy capabilities.

The most noteworthy advantages of such snapshots are:

• Miniscule impact on instances and operations in the infrastructure.
• Tight-knit integration with the rest of the OpenStack environment.
• High performance for both backup and restoration processes.

At the same time, these snapshots have a lot of major shortcomings, including limited retention capabilities, no regard for storage space consumption, and the fact that snapshots are stored in the same environment as the original data.

Cinder Backup Service

Cinder Backup Service is, to a certain degree, an extension of the snapshot capability, allowing for the backups to be stored in separate storage systems (such as OpenStack Swift or other object storage environments).

The advantages of Cinder Backup Service are rather useful in certain situations, including:

• Integration with OpenStack at the workflow and API levels.
• Ability to restore backups as new volumes.
• Customizable backup storage location for better redundancy.
• The choice between incremental and full backup types to save storage space.

With that being said, this service lacks most advanced backup capabilities such as encryption or deduplication, the offsite backups are still not supported, and are highly unlikely to meet most of the enterprise-grade security requirements

The native OpenStack backup capabilities in both cases are very limited and can rarely offer the necessary level of protection to its users. As such, most companies and businesses choose to use third-party backup solutions as the only remaining alternative to protect sensitive OpenStack Cinder data.

Third-party OpenStack Cinder backup methods

Before we go over the complete instances of third-party software for backups, we have to cover the topic of custom scripting.

OpenStack’s API support works in favor of such endeavors, but it is not as easy or convenient as it might seem at first. The practice of creating custom-tailored programs or scripts to interact directly with OpenStack API to manage backups in different ways. The reason why this approach is treated as a third-party backup method is because these scripts are developed by people who are not related to OpenStack in the first place.

The most obvious advantages of custom scripting for OpenStack Cinder backups are:

• Cost-effectiveness. Custom scripting can be relatively cheap in comparison with existing third-party backup solutions, but only in specific circumstances.
• Precise control. Extensive customization provided by custom scripts makes it possible to create a large selection over backup and recovery processes, including their retention policies, timings, volume selection, and so on.
• Feature flexibility. Design capabilities for custom scripting have a lot of potential options, and the range of capabilities usually depends on the skills of the script author. It is possible to use scripts to introduce data verification, encryption, compression, extensive integration with other services, fine-grained automation, and many others.

With that being said, the number of potential shortcomings with such an approach is a lot bigger in comparison:

• Learning curve. Custom scripting for purposes such as backups often demands a deep understanding of both the system itself and its scripting languages, which might facilitate dedicated hiring or training processes and substantial resource spending.
• Demanding maintenance. Ongoing maintenance to support newer versions of Cinder API while also addressing any potential issues or bugs with the script can be very time-consuming and draining.
• Knowledge transfer. The lack of official documentation makes maintenance and feature improvements that much more difficult if the original script creator no longer works with the company.
• Absence of official support. The lack of any kind of official support from OpenStack makes every single issue several times more challenging to troubleshoot and resolve.
• Potential for errors or missing features. If the script’s development and feature set were not thought through beforehand – it can be easy to miss some valuable capabilities in the development process, such as instant recovery or deduplication. The same could be said for the errors and bugs in the script that might happen if the script in question was not tested properly beforehand.
• Security issues. As a consequence of a non-standardized development process, most custom scripts can easily spawn numerous vulnerabilities in the backup process if not thoroughly planned and tested beforehand.

Custom scripting is a much more viable option for companies with internal development teams and limited requirements for their backup and recovery operations in OpenStack. This combination is one of the few examples where the usage of custom scripts over third-party software would make any kind of financial sense.

Of course, custom scripting is not the only alternative to Cinder’s built-in backup measures since there is also an entire market for third-party backup software. The most prominent examples of this market are going to be elaborated upon in a list below, with four primary solutions on display: Veeam, Commvault, TrilioVault, and Bacula Enterprise.

Veeam

Veeam is a popular platform for data protection and other similar features that support an abundance of storage types and operating environments. Backup and recovery are just a few examples of Veeam’s comprehensive capabilities, although it is at its finest when working with VM-related backup and recovery workflows. Veeam’s OpenStack-oriented capabilities include support for backing up and recovering Cinder volumes. Its in-depth integration with OpenStack APIs can also offer a decent degree of control and customization to these backup processes when necessary.

The advantages of Veeam:

• Extensive selection of advanced features not only for backup tasks but also in recovery and testing workflows.
• Convenient integration with a multitude of storage types and environment variations.
• Simplified process management is made possible by the convenience of a centralized dashboard.
• Impressive security-related capabilities, with one of the most noteworthy features being app-aware backups.

The shortcomings of Veeam:

• The total licensing costs of Veeam are significantly higher than the market average.
• Deploying and configuring Veeam as a platform can be a long and daunting process.
• Most of the capabilities of the platform can be treated as unnecessary if they are only needed for OpenStack Cinder backups and nothing else.
• Veeam’s security capabilities may not be high enough for some organizations
• Veeam is limited in its scalability.

Commvault

Commvault can offer a centralized data management platform with vast backup capabilities. It can be used to manage information across different environment types, and support for many infrastructure variations, such as OpenStack, adds to its versatility. Scalability and efficiency are the primary points of Commvault’s focus in OpenStack backups, offering a selection of capabilities with little to no impact on system performance.

The advantages of Commvault:

• Extensive task automation suitable for sophisticated backup plans.
• Numerous data management capabilities outside of backup and recovery processes.
• A high degree of scalability for the most enormous environments with petabytes of data.
• Large selection of data security features like ransomware protection and data immutability.

The shortcomings of Commvault:

• Complex licensing model with high price points.
• Sophisticated setup process and lengthy configuration.
• Can be overkill for smaller OpenStack deployments.

TrilioVault

TrilioVault is a cloud-native solution for data protection, the only example of a purpose-built OpenStack backup solution on this list. One of its biggest advantages is deep integration with OpenStack (including Cinder) to provide efficient and scalable backups for cloud workloads. Tenant-level self-service and policy-based management are just a few examples of TrilioVault’s capabilities in cloud environments.

The advantages of TrilioVault:

• Tenant-aware operations and a multitude of other features made to work specifically in OpenStack environments.
• Agentless backup capabilities for lower overhead and easier deployment.
• Multiple backup types, including incremental forever for cloud workloads.

The shortcomings of TrilioVault:

• Effectively useless outside of OpenStack environments, requiring additional investments to secure data from non-OpenStack storage of the same company.
• A lot fewer general-purpose features compared with most alternatives.

Bacula Enterprise

Bacula Enterprise is a comprehensive backup and recovery solution that offers a wide choice of integration approaches and supported platforms through a system of modules. Its scalable and flexible approach to data protection makes it a versatile solution despite its apparent large selection of features and capabilities. Bacula excels in handling large and multifaceted corporate infrastructures, and its support for OpenStack Cinder backups is only one example of such a situation.Possibly the most important quality of Bacula is its especially high levels of security.

The advantages of Bacula:

• Extensive compression and deduplication capabilities to lower storage space usage.
• Compatibility with different platforms and environment types, works well in hybrid cloud setups.
• The licensing model is not dependent on the data volume, making it surprisingly cost-effective in the context of the competition’s prices.
• An unusually large selection of supported storage options to choose from, including tape, cloud, and many others.
• Especially high security capabilities. Bacula is relied on by large organizations such as NASA, and is trusted by the largest defense organization in the West.

The shortcomings of Bacula:

• A moderately steep learning curve because of the sheer feature variety, although the existence of extensive documentation does make it easier.
• BWeb, Bacula’s GUI, while especially powerful, is not as modern in appearance as with some other solutions.
• Users need to have at least basic Linux knowledge, although this is an unlikely issue, as most OpenStack users tend to be accomplished IT technicians..

OpenStack Cinder backup with Bacula Enterprise

There is a substantial selection of third-party solutions for OpenStack Cinder environments, and each solution has its own approach to backup and recovery processes. In that light, we would like to go over the process of creating backups for OpenStack Cinder environments with one of the aforementioned alternatives – Bacula Enterprise:

1. Install Bacula Enterprise. Bacula Director, Storage Daemon, and Console should be deployed on a VM or a dedicated server. The initial configuration to let Bacula communicate with the OpenStack environment also goes here.
2. Set up Bacula FDs (File Daemons). They should be installed on Cinder nodes to allow for volume backups and configured to communicate with the Bacula Director.
3. Configure the OpenStack plugin. The plugin should be installed in the Bacula Director, with the OpenStack API endpoint configuration following afterward.
4. Create backup jobs. They should target Cinder volumes, with all the schedules, storage locations, and retention policies being configured, as well.
5. Enable and configure security measures. This includes offsite or cloud storage for redundancy, encryption for both data transit and data at rest, etc.
6. Optimize storage usage. Both deduplication and compression capabilities should offer improvements in terms of transfer speeds and general storage usage.
7. Schedule backup tasks. Future backup schedules should align with RPOs and RTOs that your business finds acceptable. These backup windows can be reduced with incremental and other backup types when necessary.
8. Set up alerting and monitoring. Properly configured alerts should notify about backup failures and other issues, while Bacula’s monitoring capabilities offer easy tracking for backup status at any time.

This process covers all the necessary steps in creating OpenStack Cinder backups with the help of Bacula Enterprise and its vast feature set.

Best practices for OpenStack Cinder backups

The exact set of recommendations for performing backups of OpenStack Cinder volumes would differ depending on the software used in the process, but it would be fair to say that there are at least some general pieces of advice that we can offer to practically any such environment:

• Configure tiered retention policies to find a balance between storage cost and recovery needs.
• Research cloud and offsite storage for backups to secure information against large-scale natural disasters and outages.
• Review backup job logs on a regular basis to resolve issues and inconsistencies.
• Conduct regular backup and recovery process tests to ensure the integrity and validity of the results.
• Use a smart approach to snapshots as a quick but storage-heavy copy of the volume.
• Secure backup data from tampering with immutability, encryption, and other features.
• Implement automation for your backup processes to reduce the possibility of human error and improve backup consistency.

These are just a few examples of how OpenStack Cinder backups can be improved in terms of reliability and efficiency with the correct approach.

Conclusion

Data integrity and business continuity are some of the most important goals of OpenStack Cinder backups. Unfortunately, OpenStack’s own tools are rarely capable of providing enough flexibility and security to satisfy the needs of larger businesses, which is why many of these companies use third-party backup solutions instead.

Among these features, Bacula Enterprise stands tall as a solid option for organizations of different sizes looking for a comprehensive backup platform with an abundance of capabilities. OpenStack Cinder is one of dozens of different environments and infrastructure types that Bacula can work with, making it extremely versatile and suitable for practically any environment type. The added advantage of this compatibility breadth is that organizations are able to back up their entire IT environments – OpenStack included – with single-pane-of-glass control and high security.

In the context of OpenStack Cinder backups, third-party solutions are our definitive recommendations in most cases, with solutions such as Bacula being far more versatile and customizable than anything OpenStack itself has to offer. Information is an invaluable element of any modern company’s business, which is why limiting data protection budgets is an extremely unreasonable step that should not be taken in any situation.

Frequently Asked Questions

Is it possible to perform incremental backups for Cinder volumes?

Not only do most third-party solutions support incremental backups, but Cinder’s own Backup Service also comes with such a feature, making it possible to save storage space and reduce backup time even when you work with nothing but OpenStack’s built-in capabilities.

How often should a company back up its Cinder volumes?

The exact time frames for any backup, including Cinder volumes, would differ dramatically depending on the value of the data in question, resource availability, RPOs, and other factors. Generally speaking, most companies use daily incremental backups and weekly full backups or snapshots as a baseline. However, there are some environments that would have a lot shorter backup time frames, such as daily full backups and hourly incremental ones.

Are there any size limits for Cinder backup jobs?

There is no definitive size limit for volume backups in Cinder, but creating volumes bigger than a few terabytes at a time is generally not recommended for multiple reasons, including backup storage availability, strain on general network performance, and potential time constraints.

Can Cinder volumes be backed up when they are in active use?

Cinder does allow for volume backups to be performed when in use and attached to instances, but the combination of considerations around data consistency and performance impact makes this approach not particularly advisable, especially when handling highly sensitive information.