Implementing OpenStack Cinder Volume Backups for Disaster Recovery

The Problem: Volume Persistence vs. Disaster Recovery

In OpenStack, a volume snapshot is a point-in-time copy of a volume that typically resides on the same storage backend as the original data. If the storage array fails or the backend is corrupted, both the volume and its snapshots are lost. To ensure true disaster recovery, you must offload this data to a separate storage domain—a process known as a Cinder Volume Backup.

The primary takeaway is that Cinder backups are distinct from snapshots; they move data from the block storage backend (e.g., Ceph or LVM) to an object storage target (e.g., Swift), providing a durable recovery point independent of the primary storage hardware.

Prerequisites

• OpenStack Installation: A functional OpenStack environment (Yoga or newer recommended) with Cinder and an object store (Swift or Ceph RGW) deployed.
• Administrative Access: Root or sudo privileges on the controller/storage nodes to modify cinder.conf.
• Storage Backend: A primary storage backend that supports snapshots, as Cinder creates a temporary snapshot to ensure data consistency before the backup transfer.

Configuring the Backup Target

Cinder uses a driver-based architecture to communicate with the backup destination. You must define the backup driver in the Cinder configuration file to tell the service where to send the data.

1. Modify cinder.conf

On the controller node (and any nodes running cinder-backup), edit /etc/cinder/cinder.conf. For a standard Swift implementation, use the following configuration:

[DEFAULT]
# Define the driver for the backup target
backup_driver = cinder.volume.drivers.swift.SwiftBVDriver

[DEFAULT]
# Swift authentication details
backup_storage_api_version = 1
backup_swift_username = cinder_backup_user
backup_swift_auth_url = http://controller:5000/v3
backup_swift_tenant_name = cinder_backup_project
backup_swift_password = your_secure_password

2. Restart Services

Apply the changes by restarting the Cinder volume and backup services:

# Run on the controller/backup nodes as root
systemctl restart cinder-volume
systemctl restart cinder-backup

Executing and Verifying Backups

Backups can be triggered via the CLI. This process creates a snapshot, uploads the data to the object store, and then deletes the temporary snapshot.

Creating a Backup

Run the following command as a project member with the volume role:

# Replace <volume-id> with the ID of the target volume
openstack volume backup create --volume <volume-id> my-recovery-backup

Verifying the Result

Check the status of the backup to ensure it has moved from QUEUED to AVAILABLE:

openstack volume backup list

If the status remains ERROR, inspect the cinder-backup logs on the controller node to identify network timeouts or authentication failures with the Swift API:

# Check logs for transfer errors
tail -f /var/log/cinder/cinder-backup.log

Restoring Data from Backup

Restoring a backup does not overwrite the existing volume. Instead, it creates a new volume based on the backup data. This prevents accidental data loss during the recovery process.

# Create a new volume from a specific backup ID
openstack volume create --backup <backup-id> restored-volume-01

Once the volume is created, attach it to an instance to verify the data integrity of the recovered files.

Operational Considerations

Performance and Network Load

Because Cinder backups transfer the entire volume data over the network to the object store, high-volume backups can saturate the management network. If you are backing up multi-terabyte volumes, ensure the cinder-backup service is running on a node with high-bandwidth access to both the storage backend and the Swift API.

Storage Bloat and Lifecycle Management

A critical limitation of Cinder is that deleting a volume does not delete its backups. To prevent the object store from filling up with orphaned data, you must manually manage the backup lifecycle:

# Delete an obsolete backup to reclaim object storage space
openstack volume backup delete <backup-id>

Comparison: Snapshots vs. Backups

Feature	Cinder Snapshot	Cinder Backup
Storage Location	Same backend as volume	External Object Store (Swift/Ceph)
Recovery Speed	Fast (local pointer)	Slower (network download)
Failure Domain	Shared with primary volume	Independent
Typical Use Case	Quick rollbacks/updates	Disaster Recovery / Archiving

Rollback Procedure

If the backup configuration causes service instability or authentication loops, revert the cinder.conf changes:

1. Remove the backup_driver and associated Swift credentials from /etc/cinder/cinder.conf.
2. Restart cinder-volume and cinder-backup.
3. Note: This will not delete existing backups in Swift, but it will prevent new backups from being created or existing ones from being restored.