Skip to main content

Overview

Xloud Block Storage backups are managed by the cinder-backup service, which stores volume backup data in a configurable backend. The backup backend is independent of the volume backend — backups from any volume backend (Ceph, NetApp, LVM) can be stored in any backup backend (Ceph, Swift, NFS, S3). Selecting the right backup backend depends on your recovery time objectives, storage capacity, and existing infrastructure.
Administrator Access Required — This operation requires the admin role. Contact your Xloud administrator if you do not have sufficient permissions.
Prerequisites
  • The cinder-backup service must be deployed and running
  • The backup backend must be network-accessible from the backup service nodes
  • Credentials and endpoint configuration must be available before deployment

Supported Backup Backends

BackendDriverTransportUse Case
Ceph RBDcephRBD protocolNative XAVS — incremental backups, fast restores
SwiftswiftHTTP/SBuilt-in object storage, multi-node replication
NFSnfsNFSShared NAS appliances, on-premises tape replacement
S3-compatibles3HTTPSAWS S3, Ceph RGW, MinIO, Dell ECS, any S3 endpoint
Google Cloud StoragegoogleHTTPSOff-site cloud backup to GCS buckets
IBM Spectrum Protect (TSM)tsmTSM APIMainframe-connected enterprise backup with TSM

Backend Configuration

All backup backend settings are placed in the [DEFAULT] section of cinder.conf. Only one backup backend is active at a time.
The Swift backup driver stores backup data as objects in a Swift container. Each backup chunk is stored as a separate object. This backend benefits from Swift’s built-in replication for durability.
cinder.conf — Swift backup backend
[DEFAULT]
backup_driver = cinder.backup.drivers.swift.SwiftBackupDriver
backup_swift_url = http://10.0.1.71:8080/v1/AUTH_
backup_swift_auth = per_user
backup_swift_auth_version = 3
backup_swift_user = cinder
backup_swift_key = <swift-key>
backup_swift_container = volumes_backup
backup_swift_object_size = 52428800
backup_swift_retry_attempts = 3
backup_swift_retry_backoff = 2
backup_compression_algorithm = zlib
The NFS backup driver mounts a remote NFS share and writes backup files to the mount point. It is suitable for organizations with existing NAS infrastructure.
cinder.conf — NFS backup backend
[DEFAULT]
backup_driver = cinder.backup.drivers.nfs.NFSBackupDriver
backup_mount_point_base = /var/lib/cinder/backup_nfs
backup_share = 10.0.10.100:/export/cinder-backup
backup_file_size = 1999999999
backup_sha_block_size_bytes = 32768
backup_enable_progress_timer = true
The NFS share must be exported with write permissions for the cinder-backup service account. Add the export to /etc/exports on the NFS server:
NFS server — /etc/exports
/export/cinder-backup  10.0.0.0/8(rw,sync,no_subtree_check,no_root_squash)
The S3 backup driver works with any S3-compatible endpoint including AWS S3, Ceph RADOS Gateway, MinIO, Dell ECS, and Wasabi. Set backup_s3_endpoint_url for non-AWS endpoints.
cinder.conf — S3-compatible backup backend
[DEFAULT]
backup_driver = cinder.backup.drivers.s3.S3BackupDriver
backup_s3_endpoint_url = https://s3.example.com
backup_s3_store_access_key = <access-key>
backup_s3_store_secret_key = <secret-key>
backup_s3_store_bucket = cinder-backups
backup_s3_object_size = 52428800
backup_s3_retry_attempts = 3
backup_s3_retry_backoff = 2
backup_compression_algorithm = zlib
backup_s3_ssl_insecure = false
For AWS S3 without a custom endpoint, omit backup_s3_endpoint_url and set the region:
cinder.conf — AWS S3 backend
[DEFAULT]
backup_driver = cinder.backup.drivers.s3.S3BackupDriver
backup_s3_store_access_key = <aws-access-key>
backup_s3_store_secret_key = <aws-secret-key>
backup_s3_store_bucket = my-cinder-backups
backup_s3_store_region = ap-south-1
backup_compression_algorithm = zlib
The GCS backup driver stores backups in a Google Cloud Storage bucket. Authentication uses a service account credentials file.
cinder.conf — Google Cloud Storage backend
[DEFAULT]
backup_driver = cinder.backup.drivers.google.GoogleBackupDriver
backup_gcs_bucket = my-cinder-backups
backup_gcs_object_size = 52428800
backup_gcs_block_size = 32768
backup_gcs_retry_attempts = 3
backup_gcs_retry_backoff = 2
backup_gcs_credential_file = /etc/cinder/gcs-credentials.json
backup_compression_algorithm = zlib
The service account must have storage.buckets.get, storage.objects.create, storage.objects.get, and storage.objects.delete permissions on the target bucket.
The TSM backup driver integrates with IBM Spectrum Protect (formerly Tivoli Storage Manager) for enterprise tape and disk backup workflows.
cinder.conf — TSM backup backend
[DEFAULT]
backup_driver = cinder.backup.drivers.tsm.TSMBackupDriver
backup_tsm_volume_prefix = cinder
backup_tsm_password = <dsm-password>
backup_tsm_compression = true
The TSM client (dsmc) must be installed and configured on the backup service node, and the DSMI_CONFIG environment variable must point to the active dsm.sys configuration file.

Apply Backup Backend Configuration

In XAVS deployments, backup backend settings are configured through XDeploy and applied via Ansible. Do not edit cinder.conf directly.
Apply backup configuration changes
xavs-ansible deploy --tags cinder
After deployment, verify the backup service is running:
Check backup service status
openstack volume service list --service cinder-backup

Verify a Backup

Create a test backup

Navigate to Project → Volume → Volumes, select a volume, and click Actions → Create Backup.Set a name and leave the snapshot field empty for a full backup.

Monitor backup status

Navigate to Project → Volume → Backups. The backup transitions through creating to available.

Restore the backup

Click Actions → Restore Backup to restore to a new volume. Confirm the restored volume matches the original in size and status.
Backup created and restored successfully — backend is operational.

Next Steps

Backups (User Guide)

End-user guide for creating, managing, and restoring volume backups

Storage Backends

Configure primary volume backends for block storage

External Storage

Connect to NetApp, Pure Storage, Dell, and HPE enterprise arrays

Encryption

Encrypt volumes at rest — works independently of backup backend