Skip to main content
IMHCloud Logo
Back to support home

Creating and Managing Volume Backups in OpenStack

Volume backups are one of the most reliable safeguards you can put in place for persistent data in OpenStack. While snapshots give you quick point-in-time copies stored alongside your volume, backups go a step further: they write volume data to object storage, giving you durable, independent copies that survive volume deletion and can be restored to entirely new volumes.

This guide covers everything you need to create, monitor, restore, and manage volume backups using OpenStack Horizon and the CLI.

How OpenStack Volume Backups Work

Volume backups in OpenStack are managed by the Cinder service (Block Storage) and stored in Swift (Object Storage). When you trigger a backup, Cinder reads the volume data and writes it to a Swift container in your project. This separation is significant: even if the original volume is deleted, the backup remains intact in object storage.

Backups support two modes:

  • Full backup: Copies the entire volume from scratch. Safe and self-contained, but uses more storage.
  • Incremental backup: Copies only the data changed since the last backup. Faster and more storage-efficient, but depends on a valid previous full backup in the chain.

Incremental backups chain together. If any backup in the chain is deleted, restores that depend on it will fail. This is a critical consideration when managing backup retention.

Prerequisites

Before creating volume backups, confirm the following:

  • Your OpenStack project has access to object storage (Swift). Backups cannot proceed without it.
  • The Cinder backup service is running in your environment. On InMotion Cloud, this is enabled by default.
  • You have sufficient object storage quota to hold your backup data.
  • The volume you want to back up exists and is either available or attached to an instance.

Note on volume state: Cinder can back up volumes that are in an "in-use" (attached) state, but this is not recommended for databases or applications with active write operations. For consistency, detach the volume first or quiesce writes before starting a backup.

How to Create a Volume Backup in Horizon Dashboard

Full Backup

  1. Log into the Horizon dashboard and navigate to Project > Volumes > Volumes
  2. Locate the volume you want to back up
  3. Click the dropdown arrow in the Actions column for that volume
  4. Select Create Backup from the menu
  5. In the Create Volume Backup dialog:
  • Backup Name: Enter a descriptive name (e.g., db-vol-backup-2026-02-24)
  • Description (optional): Add context, such as the purpose of this backup
  • Container (optional): Leave blank to use the default Swift container, or specify a custom container name
  • Incremental: Leave unchecked for a full backup
  • Force: Check this box only if the volume is currently attached and you accept consistency risk
  1. Click Create Volume Backup

The volume will appear in the backups list with a status of "creating". Backup time depends on volume size.

Incremental Backup

Follow the same steps above, but check the Incremental checkbox in step 5. OpenStack will locate the most recent backup for this volume and copy only the changed blocks since that backup was created.

If no previous backup exists, OpenStack will automatically perform a full backup even if incremental is selected.

How to Create a Volume Backup Using OpenStack CLI

Full Backup

1openstack volume backup create --name "db-vol-backup-2026-02-24" VOLUME_NAME_OR_ID

To back up an in-use (attached) volume, add the --force flag:

1openstack volume backup create --name "db-vol-backup-2026-02-24" --force VOLUME_NAME_OR_ID

Incremental Backup

1openstack volume backup create --name "db-vol-incremental-2026-02-24" --incremental VOLUME_NAME_OR_ID

Custom Swift Container

To store the backup in a specific Swift container:

1openstack volume backup create --name "db-vol-backup-2026-02-24" --container "my-backup-container" VOLUME_NAME_OR_ID

Monitoring Backup Progress and Status

Backups are asynchronous. After initiating a backup, you need to monitor its status to confirm it completes successfully.

In Horizon

Navigate to Project > Volumes > Backups. The list shows all backups with their current status:

  • creating: Backup is in progress
  • available: Backup completed successfully and is ready for restore
  • error: Backup failed; check logs for details
  • deleting: Backup is being removed

Using the CLI

List all backups and their statuses:

1openstack volume backup list

To view detailed information about a specific backup, including size and creation time:

1openstack volume backup show BACKUP_NAME_OR_ID

Poll for status changes on a specific backup:

1openstack volume backup show BACKUP_NAME_OR_ID -f value -c status

If a backup enters an error state, check the Cinder logs on your controller node for root cause details. Common causes include insufficient Swift quota, Swift service unavailability, or network interruptions during the backup write.

How to Restore a Volume Backup

Restoring a backup creates a new volume populated with the backup's data. The original volume is not modified.

Restore in Horizon

  1. Navigate to Project > Volumes > Backups
  2. Locate the backup you want to restore
  3. Click Restore Backup in the Actions column
  4. In the Restore Volume Backup dialog:
  • Select Volume: Choose New Volume to create a fresh volume from this backup (recommended), or select an existing volume to overwrite it
  • Volume Name (if creating new): Enter a descriptive name for the restored volume
  1. Click Restore Volume Backup

The restore process creates a new volume and writes backup data into it. Monitor the new volume's status under Project > Volumes > Volumes until it shows "available".

Restore Using the CLI

To restore to a new volume:

1openstack volume backup restore BACKUP_NAME_OR_ID NEW_VOLUME_NAME

To restore into an existing volume (destructive operation, overwrites all existing data):

1openstack volume backup restore --volume EXISTING_VOLUME_NAME_OR_ID BACKUP_NAME_OR_ID

Once the restore completes, attach the volume to an instance as you would any other Cinder volume.

Managing Backup Retention

Without a retention policy, backups accumulate indefinitely and consume object storage quota. Managing retention is essential to control costs and maintain a clean backup inventory.

Deleting Backups in Horizon

  1. Navigate to Project > Volumes > Backups
  2. Select the checkbox next to the backup(s) you want to remove
  3. Click Delete Backups and confirm

Deleting Backups Using the CLI

1openstack volume backup delete BACKUP_NAME_OR_ID

To delete multiple backups at once:

1openstack volume backup delete BACKUP_1 BACKUP_2 BACKUP_3

Incremental Backup Chain Caution

When deleting older backups in an incremental chain, always delete from the newest backward. Deleting a parent backup (an earlier full or incremental backup in the chain) breaks the restore chain for any incremental backups that depended on it. Those child backups will become unrestorable.

A safe rule: before deleting any backup that is not the most recent in a chain, verify no incremental backups reference it.

Backup Limitations

Understanding the constraints of OpenStack volume backups helps you design a strategy that avoids surprises:

  • Object storage dependency: Backups require Swift. If your environment does not have Swift configured, backups will fail at creation.
  • In-use volume consistency: Backups of attached volumes may capture inconsistent data if applications are writing actively. Always quiesce writes or use application-level backup agents for databases.
  • No cross-project backup restoration: Backups are scoped to the project that created them. Restoring a backup into a different project requires manual Swift-level operations.
  • Quota impact: Each backup consumes object storage quota proportional to the volume data. Monitor your Swift quota to avoid failed backups due to quota exhaustion.
  • Incremental chain integrity: Restoring an incremental backup requires the entire chain from the base full backup to be present. Missing any link in the chain makes the incremental backup unrestorable.

Best Practices for Backup Schedules

A practical backup strategy for OpenStack volumes balances recovery point objectives (how much data you can afford to lose) against storage costs:

Weekly full backups with daily incrementals works well for most workloads. This keeps the incremental chain short (maximum seven links), limits full backup storage overhead, and gives you daily restore points.

Automate using cron and the OpenStack CLI. A simple cron job that runs openstack volume backup create --incremental daily and a weekly job for full backups keeps your schedule consistent without manual intervention.

Label backups systematically. Use names that include the volume name, backup type, and date, such as db-vol-full-2026-02-24. This makes it far easier to identify the correct restore point when you need it urgently.

Test restores regularly. A backup that has never been tested is a backup you cannot trust. Periodically restore a backup to a scratch volume, mount it, and verify data integrity. This validates both the backup process and your restore procedure before a real emergency.

Retain at minimum one verified full backup at all times. Before deleting an older full backup, confirm the newer full backup completed successfully and is in an "available" state.

Monitor backup status after each run. Backups that silently enter an error state provide no protection. Integrate backup status checks into your monitoring pipeline using openstack volume backup list and alert on any backup not reaching "available" status within a reasonable window.

Next Steps

Once your backup strategy is in place, consider pairing it with volume snapshots for faster recovery of recent changes. Snapshots are stored within the Cinder backend rather than object storage, making them quicker to create and restore, though they are not as durable as backups for long-term retention.

For critical volumes, you may also want to explore consistency groups if your workload spans multiple volumes that must be backed up atomically. Reach out to InMotion Cloud support if you need help designing a backup architecture that fits your specific recovery requirements.