OpenStack backup and recovery is built directly into the platform through a set of native tools that let you protect volumes, instances, images, and databases without leaving the ecosystem. Using Cinder for block storage backups, Nova for instance snapshots, Glance for image management, and Horizon for a graphical path, you can meet defined Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) with commands you already have access to. This guide walks through the exact CLI and GUI procedures for each layer, then covers the control plane components that are easy to overlook, so your disaster recovery plan actually works when you need it.
OpenStack backup and recovery landscape
OpenStack is not a single backup target but a collection of services that each hold a piece of your workload. Cinder manages block storage volumes, which are the persistent disks attached to instances. Nova handles the compute layer, including instance definitions and their current state. Glance stores the images used to launch new instances, and Horizon provides the web-based dashboard where you can trigger snapshots without touching a terminal. Trove, when deployed, extends database-as-a-service backups. Because these components are modular, a complete backup strategy must address each one individually, and the native tools give you a different command or menu for every layer. The practical implication is that you cannot rely on a single backup of the whole environment; you need to know which service holds which data and apply the appropriate backup method to each.
How to back up Cinder volumes using the command line
Cinder is the primary tool for backing up block storage volumes, and it works entirely through the OpenStack CLI. To create a basic backup of a volume, you need the volume ID, which you can find with `openstack volume list`. The core command is `openstack volume backup create `, which produces a full backup of the volume’s contents. For volumes that are currently attached to a running instance, you must add the `--force` flag to the command: `openstack volume backup create --force `. This flag tells Cinder to proceed even though the volume is in use, and the result is a crash-consistent backup, meaning the data is captured as it exists at that moment, without waiting for the application to flush its state. Crash-consistent backups are acceptable for many workloads, but if you need application-consistent data, you should stop the instance or quiesce the application before running the backup.
Incremental backups are supported, but they have a strict prerequisite: you must create a full backup first. Once a full backup exists, you can run `openstack volume backup create --incremental ` to capture only the changes since the last backup. This approach reduces storage consumption and backup time for frequently changed volumes, but it creates a dependency chain, so you must keep the full backup and all subsequent incrementals in the same backup location. Restoring a volume is equally straightforward: `openstack volume backup restore `. The backup ID is returned when you create the backup, and the volume ID can be an existing volume or a new one you create beforehand. If you restore to a new volume, Cinder will overwrite its contents with the backup data, so make sure the target volume is the correct size and is not attached to a running instance.
How to create instance snapshots with the Horizon dashboard
For administrators who prefer a graphical interface, Horizon provides a direct way to snapshot an entire instance. Navigate to Project > Compute > Instances in the dashboard, find the instance you want to protect, and click the "Create Snapshot" action. Horizon will prompt you for a snapshot name, and once confirmed, it captures the instance’s current state, including its metadata, configuration, and attached volumes if the instance is volume-backed. The snapshot is stored in Glance as an image, which means you can later launch a new instance from that snapshot using the standard "Launch Instance" workflow. This method is ideal for quick, manual backups of a single instance before a risky change, but it does not provide incremental capability, and the snapshot is a point-in-time copy, not a continuous backup. For regular, automated protection, you would combine Horizon snapshots with Cinder volume backups, since the snapshot captures the instance definition while Cinder captures the underlying data.
Protecting the control plane: databases and configuration files
The data plane is only half of the backup equation. OpenStack’s control plane relies on relational databases, typically MariaDB or MySQL, to store state for every service, including Nova, Cinder, Glance, and Keystone. Without a database backup, you cannot restore the platform even if you have all your volumes and images intact. For deployments using Kolla Ansible, the `mariadb_backup` utility creates a consistent copy of all OpenStack service databases in one operation. You should run this backup regularly and store the output in an external S3-compatible service, not on the same infrastructure you are protecting. Storing database backups externally ensures that a catastrophic failure affecting the internal cloud environment, such as a hardware failure or a ransomware attack on the control plane, does not destroy your recovery point along with the live data.
Configuration files are equally critical. The directories `/etc/nova`, `/etc/glance`, `/etc/swift`, and, for OpenStack-Ansible deployments, `/etc/openstack_deploy/`, contain the settings that define how your cloud operates. Backing up these files is a simple file copy operation, but it must be done consistently and stored alongside the database backups. Without the correct configuration, a restored database or volume will not be usable because the services will not know how to connect to each other or to the underlying storage. One common mistake is attempting to back up `/var/lib/nova/instances` on compute nodes, which contains KVM images of running instances. This directory is generally not recommended for backup because restoring a live VM from these files often leads to boot issues, as the instance state is not guaranteed to be consistent. Instead, rely on instance snapshots and volume backups for compute data, and limit file-level backups to the configuration directories.
Essential best practices for a reliable recovery strategy
Before you run any backup command, define your RPO and RTO. RPO tells you how much data you can afford to lose, measured in time, and RTO tells you how quickly you need to be back online after a failure. These two numbers drive every decision about backup frequency, storage location, and restore procedure. For example, an RPO of one hour means you need to run incremental backups at least hourly, while an RTO of four hours means your restore process must be tested and documented to complete within that window. Setting these targets is not a technical task alone; it requires input from business stakeholders who understand the cost of downtime and data loss.
Regularly testing restores is non-negotiable. A backup that has never been restored is a guess, not a guarantee. Schedule periodic restore drills that include full instance and volume restores, not just database restores, to confirm that your backup files are intact and that your procedures are accurate. During these tests, verify that the restored instances can boot, that the volumes attach correctly, and that the databases contain the expected data. If a restore fails, fix the procedure and re-test until it passes consistently.
Finally, back up the entire environment, not just the data. This means including the control plane databases, configuration files, and any orchestration templates or heat stacks you use to deploy workloads. A common failure scenario is restoring a volume successfully but then discovering that the instance definition is missing, or that the network configuration has changed, leaving the restored instance unreachable. By backing up the full stack, you avoid these dependency issues and ensure that a restore brings back a working cloud, not just a collection of isolated components. When you evaluate third-party tools, look for those that integrate with Cinder, Nova, Glance, and the database layer, and compare their feature sets against your RPO and RTO requirements. The native tools are sufficient for many environments, but for larger deployments with strict recovery targets, a dedicated solution that automates the entire backup and restore workflow can save significant time and reduce the risk of human error.
