Introduction
OpenStack backup is not VMware backup with a different logo. Three structural facts determine which products work: no native changed block tracking, state split across independent service databases, and a Cinder backup service that ships with no driver enabled by default.
This guide explains what OpenStack is, why it needs protection, and how its backup model differs from VMware and Hyper-V, then sets out nine selection criteria.
What is OpenStack?
OpenStack is a set of software components that provide common services for cloud infrastructure. It controls large pools of compute, storage and networking resources through APIs or a dashboard. More than 180 OpenStack-powered public cloud data centres operate worldwide.
For backup planning, the essential point is that OpenStack is not a single hypervisor. It is a collection of services, each owning its own state and its own database. Six of them shape how data protection has to work.
| Service | Role | Backup impact |
|---|
| Nova | Compute and instance lifecycle | Instance root and ephemeral disks |
| Cinder | Block storage | Volumes, snapshots, and the backup service |
| Glance | Image registry | Destination for Nova instance snapshots |
| Neutron | Networking | Tenant topology and security groups |
| Keystone | Identity and projects | Multi-tenancy boundaries |
| Swift | Object storage | A common backup destination |
Why You Need to Back Up OpenStack
Failures in OpenStack rarely look like a dead disk. Because state is distributed across services, one unhealthy control-plane component can isolate workloads that are otherwise perfectly healthy, and if a central database or the messaging bus becomes unavailable, running instances can become orphaned.
Five scenarios are worth planning for:
Human error — a tenant deletes a volume, an instance, or a shared image.
Storage corruption — integrity problems in the backend hosting volumes or objects.
Control-plane damage — failures that leave healthy instances unreachable.
Failed change — an upgrade or reconfiguration that cannot be rolled back cleanly.
Malicious encryption and compliance — ransomware, plus retention obligations.
One distinction gets blurred constantly: a snapshot is not a backup. Snapshots share the source volume's storage backend, placing them in the same failure domain, and they consume block storage quota.
A volume backup is written by the Cinder backup service to a separate repository and metered against its own quota. Snapshots give you rollback; backups give you survival. A credible OpenStack backup solution treats them as complementary, not interchangeable.
How OpenStack Backup Works
The Cinder backup path
Volume backups run on the cinder-backup service, which writes to whichever backend is set through backup_driver in cinder.conf. One detail surprises most teams: no backup driver is enabled by default. The capability exists, but it must be deployed and operated deliberately.
OpenStack ships seven backup drivers: Ceph, GlusterFS, NFS, POSIX file systems, Swift, Google Cloud Storage, and S3.
By default, cinder backup-create takes a full backup. Incremental backups need at least one existing backup, and OpenStack documents incremental support as complete on NFS, Swift, and Ceph repositories. One caveat is skipped: the volume's data must still be read and checksummed for every full and incremental backup. Without change tracking, there is no cheaper reference.
Metadata is a second dependency. The backup_service and backup_url values live in the Cinder database; lose that database without an export and the backups become unrestorable.
The instance and image path
Nova instance snapshots are written to Glance as an image that can launch a replacement instance. At the host layer, OpenStack's own migration guidance separates two approaches: disk-attachment uses a helper instance to mount volume snapshots and read through the Cinder abstraction, while host-level transfer reads QCOW2 chains or Ceph RBD devices directly — the only route to Nova ephemeral disks.
That guidance is explicit that OpenStack does not natively track changed blocks. Vendors compensate with the Ceph RBD snapshot-diff API, chunk checksum comparison, or full backups combined with deduplication.
Where the platforms diverge
| Dimension | OpenStack | VMware vSphere | Microsoft Hyper-V |
|---|
| Change tracking | None native; Ceph RBD diff, checksums, or full backups | CBT, a VMkernel feature, queried via VADP | RCT, built into Server 2016 and later |
| Backup interface | Separate REST APIs plus cinder-backup | One protection API: VADP | Hyper-V WMI plus VSS writers |
| Consistency | Crash-consistent by default | Snapshot plus redo log, then consolidate | Production checkpoints call guest VSS writers |
| Metadata | Split across service databases | Centralised in vCenter inventory | Host and cluster inventory |
9 Criteria for Choosing the Best OpenStack Backup Software
Native integration with core OpenStack APIs
The first filter is integration depth. A product should discover instances, volumes and images by calling the Nova, Cinder and Glance APIs, not by importing a static inventory. It should authenticate through Keystone v3, respect project boundaries, and read Neutron for tenant topology.
Coverage scope — what exactly gets protected
Decide what needs protection before comparing products. A complete OpenStack VM backup scope includes instance root and data disks, Nova ephemeral storage, Glance images, and metadata such as flavour, key pair, and IP address. Tenant network topology and security groups are often forgotten until a restore is attempted.
Backup method and its performance envelope
This is the highest-weight criterion. Disk-attachment reads through a helper instance and works across most backends, but consumes compute resources. Host-level transfer reads QCOW2 chains or Ceph RBD devices directly and can reach Nova ephemeral disks. Since OpenStack lacks change tracking, ask which substitute product uses and whether it supports LAN-free transfer.
Restore granularity and tenant-level recovery
Recovery is where selection projects are won or lost. Confirm whether single-file, single-volume, whole-instance and whole-tenant restores are supported, and whether restored instances regain their IP addresses, key pairs, flavours and security groups — rebuilding those by hand is where RTO quietly expands.
RPO/RTO fit and the incremental model
Define recovery objectives before comparing features, not after. Then ask how full, incremental and differential backups combine, and what happens when a valid backup chain is missing. Retention requirements such as GFS policies belong in the same conversation, and instant recovery is only worth paying for if your RTO needs it.
Storage efficiency and target flexibility
Backup targets should not lock you in. Look for NFS, CIFS, S3-compatible object storage, Swift, Ceph, FC SAN and iSCSI support, ideally in one product. Deduplication and compression matter more here than elsewhere, because full backups remain the only fallback when change tracking is absent.
Security, immutability and ransomware resilience
Assume production credentials will eventually be compromised. Encryption in transit and at rest, with password verification on restore, is the baseline. Look for backup storage that actively rejects unauthorised modification rather than merely logging it, plus role-based access control and audit logs.
Scale, multi-tenancy and quota behaviour
Test at your real scale, not lab scale. Ask how many concurrent jobs the product sustains, and whether it supports rolling execution windows and throughput throttling. Then examine the quieter cost: backup traffic competes with production for Cinder backup quota and object storage bandwidth.
TCO, licensing model and ecosystem fit
Licensing models differ enough to change the answer. Per-socket, per-VM, per-capacity and subscription pricing each favour a different deployment shape. Ask whether the product protects anything other than OpenStack, because a single-purpose tool means buying a second system for VMware, Hyper-V or H3C CAS/UIS workloads.
Common Mistakes When Choosing OpenStack Backup Software
Treating Cinder snapshots as long-term backups. Snapshots share a failure domain with the source volume and consume block storage quota, which is metered separately — so swapping one for the other distorts both cost and protection.
Ignoring backup metadata and the control plane. Cinder stores the backup URL in its database; lose it without an export and the backups become unrestorable, however intact the data may be.
Assuming --force yields application-consistent backups. Backing up a volume in use without quiescing the workload produces a crash-consistent copy, which OpenStack documents explicitly. Database workloads need more.
Assuming incremental backups are always cheap. Every incremental still reads and checksums the whole volume. Benchmark incremental duration on real data rather than trusting the label.
Skipping restore rehearsals. A backup that has never been restored is not a protection capability. It is an assumption.
Common OpenStack Backup Software
This section reviews three widely adopted OpenStack backup tools: two are open-source solutions while the other is commercial software. Organizations may select the suitable backup platform according to their infrastructure size, protection goals and operational needs.
OpenStack Freezer
Freezer is the OpenStack project's distributed backup service: a Horizon web UI, a job scheduler, and a stateless agent that must run on each protected host. It backs up file systems, MySQL and MongoDB databases and Cinder volumes, using GNU Tar or rsync differentials, AES-256-CFB encryption, and Swift, S3, SSH or local targets. Your team runs the agents.
The built-in Cinder backup service
OpenStack's native option needs no new software, only configuration. The cinder-backup service writes volumes to one of seven backup drivers, and no driver is enabled by default. The constraints persist: incrementals still read and checksum the whole volume, --force yields a crash-consistent copy, and the backup URL lives in the Cinder database — lose it and the backups become unrestorable.
Vinchin Backup & Recovery
Vinchin starts where those two stop: it protects instances rather than files or volumes. It discovers resources through the OpenStack APIs and backs up whole instances agentlessly, with image-based incrementals and LAN-free transport over SAN. Deduplication, compression, GFS retention, AES-256 encryption and anti-ransomware storage protection are built in, and file-level restore recovers a single file without rebuilding the instance.
How the three compare
| Capability | OpenStack Freezer | Built-in Cinder backup | Vinchin |
|---|
| Backup scope | Files, databases, volumes | Cinder volumes | Whole instances, volumes, files |
| Method | Agent on every protected host | Service plus a driver you enable | Agentless through OpenStack APIs |
| Incrementals | Tar or rsync differentials | Whole volume re-read and checksummed | Documented CBT alternative |
| Recovery | Files and volumes | A new volume by default | File-level and instant recovery |
| Retention and protection | Policy-based retention | No policy engine | GFS, encryption, anti-ransomware |
| Platforms managed | OpenStack plus heterogeneous hosts | OpenStack only | Fifteen-plus platforms |
The pattern is consistent: both open-source options work, and both leave you the operational burden. Freezer needs an agent on every protected host; Cinder backup needs a driver chosen, deployed and driven by your own tooling. Neither restores an instance with its metadata, network topology and security groups intact — which is the gap the next section addresses.
Why Vinchin Is the Best OpenStack Backup Software
Solving Core Limitations of Native OpenStack Backup
Most built-in and open-source OpenStack backup tools lack reliable changed block tracking mechanisms, resulting in inefficient full-volume scanning, slow incremental jobs, and unnecessary resource overhead. Vinchin addresses this fundamental architectural gap by delivering a mature CBT alternative for OpenStack environments, fixing the root cause of poor backup performance instead of merely mitigating surface-level issues.
Agentless, High-Performance Backup Architecture
Vinchin Backup & Recovery provides fully agentless protection for OpenStack instances through native API integration. It supports image-based incremental backups with flexible daily, weekly, and monthly scheduling, eliminating manual command-line scripting. The built-in LAN-free backup offloads backup traffic to the SAN network, avoiding production network congestion and significantly shortening backup windows for large-scale cloud environments.
Optimized Storage Efficiency & Application Consistency
To minimize storage consumption, Vinchin integrates inline deduplication, compression, and BitDetector technology. After deduplication, compression can reduce instance backup size by more than 50%, greatly lowering long-term storage costs. Beyond disk-level protection, it delivers application-aware backup for mainstream databases including MySQL, MS SQL Server, and Oracle, ensuring database consistency for enterprise-critical workloads.
Enterprise-Grade Retention, Security and Ransomware Defense
Vinchin supports standard GFS retention policies, onsite/offsite replica copies, cloud archiving, and tape storage integration to meet diverse long-term data retention and compliance demands. All backup data is protected with AES-256 encryption, while intelligent backup storage protection blocks unauthorized data modification via real-time I/O monitoring, effectively defending against ransomware and human tampering. The latest v9.0 further adds automated backup verification and malware scanning, ensuring all recovery points are pre-validated for reliable emergency restoration.
Fast, Flexible Recovery Capabilities
The platform delivers dual recovery modes for different business scenarios: granular file-level restore for quick single-file retrieval without full instance recovery, and industry-leading instant recovery that boots up VMs of any size within 15 seconds, minimizing business downtime during failures.
Unified Multi-Platform Management & Market Recognition
Vinchin unifies backup management for more than 15 virtualization and cloud platforms — including VMware, Hyper-V, and H3C CAS/UIS — eliminating isolated backup systems for OpenStack and simplifying overall data protection operations. Backed by stable enterprise performance, Vinchin has been listed as a Strong Performer in the 2026 Gartner Peer Insights Voice of the Customer for Backup and Data Protection Platforms, earning consistent industry recognition for two consecutive years.
Compliance with Enterprise Backup Evaluation Criteria
Vinchin fully meets enterprise-level data protection benchmarks across core evaluation dimensions: agentless API integration, CBT alternative with LAN-free acceleration, flexible granular and instant recovery, high-efficiency deduplication and compression, end-to-end encryption and anti-ransomware protection, and unified multi-platform management, making it a fully qualified enterprise-grade backup solution for production OpenStack clouds.
FAQ
Q1: Does OpenStack have built-in backup?
A1: Yes, but with conditions. The cinder-backup service handles volume backups, and no backup driver is enabled by default. You choose, configure, and operate the driver yourself.
Q2: Is OpenStack Freezer still maintained?
A2: Yes. A Technical Committee resolution in January 2025 confirmed Freezer as active again and included it in the 2025.1 release, and it is published as production-ready on PyPI.
Q3: What is the difference between a Cinder snapshot and a backup?
A3: A snapshot is a point-in-time copy sharing the source volume's storage backend and failure domain. A backup is an independent copy written to a separate repository and metered against a separate quota.
Q4: Can OpenStack VMs be backed up without installing agents?
A4: Yes. Agentless backup uses either disk-attachment, where a helper instance mounts volume snapshots, or host-level access, which reads QCOW2 chains or Ceph RBD devices directly.
Conclusion
OpenStack differs greatly from conventional virtualization platforms in data protection. It lacks native changed block tracking, adopts a distributed architecture, and disables default backup services. As a result, native and open-source OpenStack backup tools are limited in efficiency, consistency, and recoverability, making feature-only comparisons insufficient for enterprise selection.
Vinchin Backup & Recovery effectively fixes these OpenStack backup limitations. It delivers agentless incremental backup with a CBT alternative and LAN-free transport, together with verified recovery points, ransomware protection, flexible restore options, and multi-platform unified management, providing a reliable enterprise-grade data protection solution for OpenStack clouds.
