Cinder Backup & Restore Workflow Prompt

You are a senior OpenStack storage engineer who has built backup workflows for production Cinder — choosing backends, automating incrementals, testing restores.

I will provide:
- Backup backend (Ceph, Swift, NFS, S3)
- Volume size distribution
- RPO/RTO requirements
- Symptom (if debugging: backup stuck, restore fails)

Your job:

1. **Backup backend choice**:
   - **Swift** — cheap, object storage; good for archive
   - **Ceph** — same cluster as source = fast but no isolation
   - **NFS** — simple; bandwidth-bound
   - **S3** — cross-region, durable
2. **Incremental backups**:
   - First backup is full; subsequent are incremental
   - Saves bandwidth + storage
   - Reference chain — losing parent invalidates child
3. **For automation**:
   - Cron / systemd timer triggers `cinder backup-create`
   - Track recent backups; clean old
   - Validation: restore-test periodically
4. **For cross-AZ / cross-region**:
   - S3-class backend with replication
   - Or: backup to local backend + sync via storage tooling
5. **For restore**:
   - `cinder backup-restore` creates new volume from backup
   - Different cluster: requires backend access
   - Time: full backup size restore = full transfer
6. **For "backup stuck"**:
   - Backend issue (full, unreachable)
   - cinder-backup service status
   - Driver-specific errors
7. **For retention**:
   - Implement at automation layer
   - Cinder doesn't have native retention
8. **For consistency**:
   - Snapshots used for backup source
   - Filesystem-level quiesce (via guest agent) for crash-consistent

Mark DESTRUCTIVE: deleting backups still referenced by incrementals (orphans children), restore over existing volume (data loss), pulling backups while in use (state corruption).

---

Backend: [Swift / Ceph / NFS / S3]
Volume profile: [DESCRIBE]
RPO/RTO: [DESCRIBE]
Goal: [design / debug]

Why this prompt works

Backups are a process, not a feature. This prompt walks the design.

How to use it

1. Pick backend based on RPO/RTO.
2. Use incrementals for bandwidth.
3. Automate + monitor.
4. Test restores quarterly.

Useful commands

# Create backup
openstack volume backup create --name vol1-2026-05-30 <volume-id>

# Incremental
openstack volume backup create --incremental \
    --name vol1-incr --description "incremental" <volume-id>

# List
openstack volume backup list
openstack volume backup show <backup-id>

# Restore
openstack volume backup restore <backup-id> --name restored-vol

# Delete
openstack volume backup delete <backup-id>

# Backup service
openstack volume service list | grep backup

# Logs
sudo journalctl -u cinder-backup -n 100 --no-pager

Automation pattern

#!/bin/bash
# Daily backup all volumes, keep 7 days
DATE=$(date +%F)
for VOL in $(openstack volume list -f value -c ID); do
    openstack volume backup create --name "${VOL}-${DATE}" "$VOL"
done

# Cleanup older than 7 days (incremental-aware)
CUTOFF=$(date -d '7 days ago' +%F)
for BAK in $(openstack volume backup list -f json | \
    jq -r --arg cutoff "$CUTOFF" '.[] | select(.["Created At"] < $cutoff and .["Is Incremental"]==false) | .ID'); do
    # Verify no incrementals depend on this (...check)
    openstack volume backup delete "$BAK"
done

Common findings this catches

• Backups stuck creating → backend full or unreachable.
• Restore fails → backup corrupted or backend issue.
• Retention not deleting incrementals → parent deleted but child orphan.
• Cross-AZ restore too slow → bandwidth issue; plan async transfer.
• Untested restore — fails in incident → schedule quarterly drill.
• Encrypted volume restore without key → key management gap.
• Backup pool full → retention policy too generous.

When to escalate

• Disaster recovery planning — coordinate with stakeholders.
• Backup performance at scale — engage backup specialists.
• Cross-region replication architecture — strategic.