Volume Snapshots vs Backups: What's the Difference?

OpenStack provides two distinct mechanisms for protecting volume data: snapshots and backups. Both preserve the state of a Cinder volume, but they differ significantly in how they store data, where that data lives, how fast they operate, and what failure scenarios they protect against.

Choosing the wrong tool for the job leads to real consequences. A snapshot-only strategy can leave you exposed if the underlying storage fails. A backup-only approach can leave you without a fast recovery path during incidents. Understanding both gives you a more complete data protection posture.

What Is a Cinder Snapshot?

A Cinder snapshot is an incremental, point-in-time copy of a volume stored within the Cinder block storage backend itself. When you create a snapshot, OpenStack records only the blocks that have changed since the volume was created (or since the last snapshot). This makes snapshot creation fast and storage-efficient for typical use cases.

Key characteristics of snapshots:

Storage location: Stays within the Cinder backend (same storage pool as the source volume)
Dependency: Snapshots are dependent on the source volume; the original volume must exist for the snapshot to be usable
Speed: Near-instant creation and fast restore operations
Incremental: Only changed blocks are stored after the first snapshot
Use case: Short-term recovery, pre-change safety checkpoints, cloning volumes

Because snapshots live in the same storage pool as the source volume, they do not protect against backend storage failures, data center outages, or accidental deletion of the source volume. A snapshot is a fast recovery tool, not a disaster recovery tool.

What Is a Cinder Backup?

A Cinder backup is a full copy of volume data exported to an external object storage system, typically OpenStack Swift. Unlike snapshots, backups are fully independent of the source volume. Even if the original volume and its entire storage pool are destroyed, the backup remains intact and restorable.

Key characteristics of backups:

Storage location: External object storage (Swift), separate from Cinder
Independence: Fully independent of the source volume; restores work even if the source is gone
Speed: Slower to create and restore due to the volume of data transferred to object storage
Durability: Higher durability because data is stored in a separate, replicated object store
Use case: Long-term retention, disaster recovery, cross-environment restoration

Backups are incremental after the first full backup (OpenStack tracks changed blocks between backup cycles), which reduces storage consumption and transfer time for subsequent backup operations. However, the initial backup and any full restore remain significantly slower than snapshot operations.

Snapshot vs Backup Comparison

| Attribute | Snapshot | Backup |
|---|---|---|
| Storage location | Cinder backend (same pool) | Object storage (Swift) |
| Source volume dependency | Required | Not required |
| Creation speed | Fast (seconds to minutes) | Slow (minutes to hours) |
| Restore speed | Fast | Slow |
| Protects against storage failure | No | Yes |
| Incremental | Yes | Yes (after first full backup) |
| Long-term retention | Not recommended | Recommended |
| Disaster recovery | No | Yes |
| Cross-environment restore | Limited | Yes |
| Storage cost | Lower (incremental deltas) | Higher (full volume data in object store) |

When to Use Snapshots

Snapshots are the right tool when you need a fast, reversible checkpoint and the underlying storage is healthy. Common scenarios include:

Before a risky operation: Snapshot a volume before running a database migration, kernel upgrade, or configuration change. If something breaks, you revert in minutes.
Short-term recovery windows: Keep snapshots for 24 to 72 hours as rollback points during active development or deployment cycles.
Volume cloning: Create a new volume from a snapshot to spin up a copy of an environment for testing or debugging without affecting production.
Consistent application state: Quiesce your application (flush writes, pause I/O) before snapshotting to capture a crash-consistent or application-consistent point in time.

Snapshots are not a substitute for backups. They exist in the same failure domain as the source volume, meaning a hardware failure or storage corruption event can take out both the volume and all of its snapshots simultaneously.

When to Use Backups

Backups are the right tool when you need durable, independent copies that survive infrastructure failures. Common scenarios include:

Disaster recovery: If your Cinder backend experiences a catastrophic failure, only backups in object storage will be recoverable.
Long-term retention: Regulatory or compliance requirements often mandate retaining data copies for 30, 90, or 365 days. Backups are purpose-built for this.
Cross-environment restoration: Restore a volume in a different project, region, or cloud environment. Backups in Swift can be accessed independently of the original Cinder environment.
Infrequent but critical recovery: Production database volumes, configuration stores, or persistent application data that does not change frequently but must be recoverable under any failure condition.

The tradeoff with backups is time. Restoring a large volume from Swift can take significantly longer than reverting a snapshot, so backups are not the right choice for fast rollbacks during active deployments.

Performance and Cost Tradeoffs

Snapshot performance is generally excellent for both creation and restore. Because snapshots use copy-on-write semantics within the same storage backend, the initial snapshot captures almost instantly. However, as you accumulate many snapshots of an active volume, the copy-on-write overhead can affect I/O performance of the source volume. Keep snapshot chains short and prune old snapshots regularly.

Backup performance depends on volume size, object storage throughput, and network bandwidth between Cinder and Swift. A 500GB volume with active data could take 30 minutes or more for an initial backup. Incremental backups are faster, but restores always reconstruct the full volume, which takes time proportional to the total data.

Cost considerations:

Snapshots consume Cinder storage quota. Each block stored in a snapshot counts against your block storage allocation.
Backups consume object storage capacity in Swift, which is typically billed separately at a lower per-GB rate than block storage.
For infrequently changed volumes, backups can be more cost-effective for long-term retention than keeping a chain of snapshots.

A Practical Data Protection Strategy

A well-designed strategy uses both tools in combination:

Snapshots for operational safety: Take snapshots before deployments, upgrades, or any change that modifies volume data. Retain these for 24 to 72 hours and delete them once the change is confirmed stable.
Scheduled backups for durability: Automate daily or weekly backups of critical volumes to Swift. Retain backups for 30 to 90 days depending on your recovery point objective (RPO) requirements.
Test your restores: A backup or snapshot has no value if the restore process fails or takes longer than acceptable. Periodically validate recovery by restoring a backup to a test volume and confirming data integrity.

This layered approach gives you fast rollback capability for day-to-day operations and durable, independent recovery for serious failure events.

Summary

Snapshots and backups serve different but complementary roles in an OpenStack data protection strategy. Snapshots are fast and efficient for short-term recovery within the same storage environment. Backups are durable and independent, suitable for long-term retention and disaster recovery scenarios where the source volume itself may not be recoverable.

Use snapshots to move quickly and safely during active work. Use backups to ensure your data survives failures you cannot predict. For critical volumes, use both.

If you need help configuring backup policies or snapshot schedules for your InMotion Cloud volumes, contact our support team.