Our team has recently returned from the OpenStack Summit in Austin. While there were many hot topics, we discovered people fell within two camps when it comes to backup and recovery: those who understand why a native OpenStack solution is required, and those who question why legacy backup and recovery won’t fit the bill.

Horizontal Scale

OpenStack does not come with the maximum capacity that it can grow into. The architecture is inherently scalable without any theoretical boundaries; it can be deployed in a single box or it can scale to thousands of nodes.

Contrast this with existing backup solutions that always have some predefined capacity, whether it is number of applications it can back up or the amount of backup storage capacity that it can manage. So essentially you have a forever scalable architecture, tied to a backup solution with a limit on capacity.

Multi-Tenancy

Multi-tenancy is an integral part of OpenStack cloud. The tenancy is different than supporting multiple active directory users in a backup application. Active directory users are typically OS users, whereas cloud tenancy usually represents individual organizational units with in a bigger organization. So there is a mismatch on how existing backup solutions are created versus how OpenStack multi-tenancy works.

One way to make existing solutions work with OpenStack is to deploy a backup application for each tenant and make that tenant responsible for managing its own instance of the backup application. This means each tenant has to manage the application and any storage that is provisioned to save backup images.

Self-Service Portal

Some backup applications provide an aspect of a self-service portal for individual users to manage their own backup policies. Backup applications use host agents on either virtual machines, or on servers to back up files and provide a portal to restore a backup copy in place through its agent infrastructure. This kind of self-service portal is, again, in contrast to what an OpenStack self-service portal is—it provides the ability to provision virtual resources.

File-Level Backups

Existing backup solutions are only good at doing file-level backups. Yes, they have evolved to do virtual machine (VM) backups for VMware, but vCenter is not a cloud platform, and the mechanism to do a VM backup on VMware platforms is totally different from doing VM backups in OpenStack. Anyone trying to retrofit existing backup solutions for OpenStack will only have their file-level backup feature to rely on.

File-level backups only back up bits and pieces of your application. File-level backups are the legacy of backing up scale-up systems, where huge databases are confined to a beefed-up single host. But cloud applications are lot more distributed. Instead of provisioning one beefed-up server to host a large database, cloud applications are deployed as multiple VMs, with each VM performing discrete functionality. The data in these applications are also are distributed to multiple VMs. File-level backups will not ensure consistent backups. They are notoriously insufficient to restore an entire application environment and may seriously affect your recovery time.

Infrastructure-Aware Backup Solutions

File-level backups are not well-suited to address cloud application needs. Instead, a backup application that is aware of cloud infrastructure provides a perfect solution for your cloud applications. Since cloud applications are distributed, your backup should include not only the data but also the application context to successfully recover the application.

An application context includes the VMs, flavors of the VMs, network settings and all the volumes attached to those VMs. Let’s not forget that all of the aforementioned will be tweaked and will evolve over time to suit that moment in time. So only backup solutions that can provide a single snapshot that includes all the VMs, storage volumes mapped to each VM, network settings and the meta data associated with each VM and its resources at that point in time are suited for OpenStack backup needs. Since such backup solutions capture the entire application environment, recovery with this backup solution is very deterministic and reliable, irrespective of the size and complexity of application.

Solutions that are aware of the infrastructure also can back up applications into one availability zone/region and restore into a different zone/region. Beyond speed of recovery, this now empowers data protection (or backup) with resource management capabilities.

DevOps

DevOps is an integral part of OpenStack cloud deployment and management. Your choice of backup solution should play with your cloud DevOps scripts. For example, if you standardize on Ansible playbooks to manage your cloud deployments, the backup application should play into your DevOps strategy so you can reduce the TCO of your backup application.

Other Use Cases

In traditional IT, the data management functions such as backup and recovery, disaster recovery and application migration require different applications. However, your backup solution for OpenStack should be more than just a backup and restore of the files. A backup solution that is well-designed for OpenStack is a re-orchestration from a point-in-time and should be able to provide additional uses cases such as:

File(s) restore
VM/volume restore
Intra/inter-cloud application migration
Disaster recovery
Instant restore of point in time for application validity checks, network scanner and other forensics
Archival
Environmental restore during cloud upgrades

OpenStack offers an operating model that warrants a completely new thinking around backup solutions. Retrofitting existing solutions not only is inadequate in protecting your applications, it also increases your TCO. So do yourself a favor and look for solutions that are purpose-built for OpenStack. That will provide the best data protection possible, decrease your TCO and simplify recovery.