☁️ OpenStack Error: Cinder Backup Failed / Stuck in error State

Exact Error Message

$ openstack volume backup create --name db-backup 4d9c1b2a-...
$ openstack volume backup show db-backup -c status -c fail_reason
+-------------+--------------------------------------------------------------+
| Field       | Value                                                        |
+-------------+--------------------------------------------------------------+
| status      | error                                                        |
| fail_reason | Connection to swift failed: [Errno 111] Connection refused   |
+-------------+--------------------------------------------------------------+

In the cinder-backup log the underlying failure looks like:

ERROR cinder.backup.manager [req-...] Backup service cinder-backup does not support verify.
ERROR cinder.backup.drivers.swift Error in swift, retrying: ClientException: ...
ERROR cinder.backup.manager Backup id 7c2f... failed: Connection to swift failed

You may also see a backup wedged mid-flight:

$ openstack volume backup list
| 7c2f...  | db-backup | creating |

What It Means

cinder-backup is a separate service from cinder-volume. When you create a backup, cinder-backup reads the volume and streams it to a configured object store (Swift, Ceph/RBD, NFS, or S3). A backup lands in error when that pipeline breaks — most often because the backup service is down, the backup driver is misconfigured, or the object store is unreachable or unauthenticated.

The fail_reason field on the backup, plus the cinder-backup log, tells you which stage failed. A backup stuck in creating usually means the service died mid-transfer and nothing moved it to a terminal state.

Common Causes

• The cinder-backup service is down or not running on any node (openstack volume service list shows it down).
• The backup driver is misconfigured (backup_driver points at Swift but the store is Ceph, or credentials/container are wrong).
• The object store is unreachable — Swift proxy down, Ceph mon quorum lost, NFS export not mounted.
• Authentication failure to the backup store (bad service account, expired credentials, wrong backup_swift_auth).
• Full backend / quota on the object store, or the source volume is not in a backup-eligible state.
• The service crashed mid-backup, leaving the backup stuck in creating.

Diagnostic Commands

Check the backup status and the reason first:

openstack volume backup show db-backup -c status -c fail_reason -c size

Confirm the backup service is actually up:

openstack volume service list --service cinder-backup

Inspect the configured driver and target:

grep -E "backup_driver|backup_swift_url|backup_ceph_pool|backup_share" /etc/cinder/cinder.conf

Read the backup log around the failure:

sudo journalctl -u cinder-backup --since "-20min" --no-pager
sudo tail -n 200 /var/log/cinder/cinder-backup.log | grep -i <backup-id>

Test reachability of the store directly (Swift example):

openstack container list
openstack object store account show

Step-by-Step Resolution

1. Read fail_reason. It usually names the failing stage — connection refused (store down), 401/403 (auth), or driver mismatch — which decides the branch below.

2. Make sure the backup service is running. If openstack volume service list shows cinder-backup as down, start it and read why it died:

sudo systemctl status cinder-backup
sudo systemctl restart cinder-backup
sudo journalctl -u cinder-backup -n 100 --no-pager

3. Verify the driver matches your actual object store. A common mistake is a Swift backup_driver on a Ceph deployment (or vice versa):

# /etc/cinder/cinder.conf
[DEFAULT]
backup_driver = cinder.backup.drivers.ceph.CephBackupDriver
backup_ceph_conf = /etc/ceph/ceph.conf
backup_ceph_pool = backups
backup_ceph_user = cinder-backup

Restart cinder-backup after any change.

4. If fail_reason is a connection or auth error, test the store from the backup host. For Swift, confirm the proxy answers and credentials work; for Ceph, confirm mon quorum and the pool:

openstack container list                 # Swift reachability + auth
sudo ceph -s                             # Ceph health / quorum
sudo rados -p backups ls | head          # Ceph pool access

5. Fix the identified problem — start the Swift proxy, restore Ceph quorum, mount the NFS export, or correct credentials — then create a fresh backup to confirm the pipeline works end to end:

openstack volume backup create --name db-backup-retry 4d9c1b2a-...
openstack volume backup show db-backup-retry -c status

6. Clean up the failed record. A backup in error can be deleted normally; one stuck in creating after a service crash needs a state reset first (only after confirming no transfer is in progress):

openstack volume backup set --state error 7c2f...   # move stuck 'creating' to a deletable state
openstack volume backup delete 7c2f...

Prevention

• Run cinder-backup as a monitored, highly-available service and alert when it reports down.
• Keep backup_driver and its store settings in configuration management so the driver always matches the deployed object store.
• Health-check the backup target (Swift proxy, Ceph mons, NFS mount) independently so store outages are caught before a backup window.
• Alert on backups that stay in creating/error; they indicate a crashed service or a broken store, not a one-off.
• Rotate and validate the backup service account credentials before they expire.

Related Errors

• Connection to swift failed: Connection refused — the object store (Swift proxy) is down or unreachable from the backup host.
• volume detach fails 'device is busy' — a related Cinder operational issue on the attach/detach path.
• driver initialization failed — the cinder-volume backend driver failing to start, which can also block backup reads.
• You are not authorized to perform the requested action (HTTP 403) — an RBAC/policy failure when creating or listing backups.

Frequently Asked Questions

Why is my backup stuck in creating and not error? The cinder-backup service almost certainly crashed or was restarted mid-transfer, so nothing moved the backup to a terminal state. Reset it to error with volume backup set --state error, then delete it.

The service is up but every backup fails — what now? Check fail_reason and the log for the store: a mismatched backup_driver, an unreachable Swift/Ceph endpoint, or bad credentials are the usual culprits. Backups are only as healthy as the object store behind them.

Is a failed backup safe to delete? Yes. A backup in error deletes normally and does not affect the source volume. Just make sure no valid backup shares the same name before you retry.

Can I generate a backup-recovery runbook for my store? Yes — describe your backup_driver and object store in the DevOps AI prompt library to get a tailored diagnosis and retry checklist.

Where can I find more Cinder troubleshooting? See the full OpenStack guides for related volume, attach, and backup fixes.