OpenStack Backup & Disaster Recovery

Deliver backup and disaster recovery as an integrated OpenStack service. Ferry by OSIE protects instances and volumes with centrally managed policies, immutable retention, and recovery across regions. Enable tenant self-service through the OSIE portal, Horizon, and CLI while retaining control over protection standards.

Restore an instance in one command.

Recover your OpenStack instance and its disks from a backup.

openstack backup restore create --point <backup-id> --mode instance --name web-01 --flavor <flavor> --networks <network>

Requires the backup CLI extension and an available instance backup.

Request a DemoRead the documentation
backup.mycompany.com/overview
Ferry protection overview showing protected resources, backup history, and available recovery points
Data protection

Whole-instance backups

Capture the root disk, attached volumes, and the instance configuration required for recovery, including flavor, networks, key pair, and security groups. With the QEMU guest agent, Ferry coordinates disk snapshots within a single filesystem freeze to maintain filesystem consistency across volumes.

  • Recover a complete instance in one operation
  • Select a different flavor or target network
  • Restore individual disks as standalone volumes
  • Require explicit selection for in-place overwrite
web-01Instance backup
Root disk
Attached volumes
Flavor
Networks
Key pair
Security groups
Coordinated snapshots across instance disks
Recovery

Cross-region disaster recovery

Restore instances and volumes in a recovery region using an accessible backup repository. Recovery operates without connectivity to the source region, supporting workload restoration during a regional outage.

Region A
Production
Scheduled instance and volume backups
Repository
S3, replica, or secondary copy
Backup data accessible to the recovery region
Region B
Recovery
Imports new recovery points every five minutes

Recovery project bindings

Map each protected instance or volume to a project in the recovery region. Existing and subsequent backups become available in that project through the standard restore workflow.

Warm standbys

Apply new backups to standby volumes in the recovery region, reducing the volume of data that must be restored during failover.

Recovery profiles

Map flavors, networks, security groups, and volume types between regions. Validate recovery configuration with a dry run before an incident.

Policy-defined recovery targets

Specify the recovery site and RPO and RTO targets in the backup policy. Recovery point availability reflects the backup schedule and the time required to transfer and import backups.

Secondary backup copies

Maintain a copy of each backup in a secondary repository with independent retention, outside the primary repository's failure domain.

Self-service regional recovery

After recovery bindings are configured, tenants can restore instances in the target region through the OSIE portal, Horizon, or the CLI.

Operations

Backup security and service controls

Establish consistent protection standards across projects with measurable recovery objectives, enforced retention, encryption, and usage reporting.

Define and monitor recovery objectives

Define backup schedules, retention, and RPO and RTO targets in each policy. Per-plan RPO compliance reporting and scheduled backup verification provide visibility into protection status and support service-level reporting.

Protect backups with immutable retention

Use S3 Object Lock in compliance mode to prevent deletion or overwrite during the retention period, including by tenants and operators. Ferry also flags changes in backup data that may indicate ransomware activity.

Enforce retention and audit legal holds

Set retention centrally and prevent tenants from reducing it. Apply legal holds to individual backups, protection plans, or entire projects to preserve data beyond its retention period, with the reason recorded in the audit log.

Integrate with your key management service

Encrypt backups before they leave the cloud using Barbican or HashiCorp Vault, with keys scoped to a repository or protection plan. Master keys remain in your key management service and are never persisted in the Ferry database or on node disks.

Reduce backup storage and I/O

Incremental-forever backups, compression, and deduplication reduce storage consumption. On Ceph, Ferry reads only blocks changed since the previous backup. Each recovery point remains independently restorable.

Meter usage and enforce quotas

Integrate per-project protected and stored byte metrics into billing or internal chargeback through the API. Project and domain quotas control consumption while allowing already accepted backup operations to complete.

Tenant experience

Self-service backup and recovery

Give tenants control over routine protection and recovery tasks through the OSIE portal, Horizon, the openstack backup CLI, and the API. Tenants select resources and approved policies, create on-demand backups, and restore workloads. Configured recovery bindings extend the same workflow to another region, reducing reliance on operator intervention.

  • Integrated with the OSIE portal, Horizon, and CLI
  • Visibility into resource protection status
  • Flexible restore targets and instance configuration
  • Self-service recovery across regions

Tenants select an operator-defined policy and create an instance protection plan.

openstack backup policy list -c name -c sentence

openstack backup plan create shop-servers \
  --resource-kind instance \
  --resource <server-id> \
  --policy nightly-7d-immutable \
  --consistency filesystem
Governance

Centralized backup policies

Define policies for scheduling, retention, repository selection, and recovery objectives, then assign them by project or domain. Enforce mandatory policies and prevent tenants from reducing retention. A deletion grace period supports recovery of deleted backups, while per-project coverage reports identify unprotected resources and the reasons for protection gaps.

  • Mandatory policies enforced across tenant projects
  • Resource quotas at project and domain level
  • Usage and RPO compliance metrics through the API

Define a mandatory policy with scheduling, retention, and recovery targets, then assign it to a domain.

openstack backup policy create gold \
  --description "Nightly, a month of dailies, a year of monthlies" \
  --every 24h --at 22:00 \
  --window-start 21:00 --window-end 05:00 \
  --keep-all 168h --keep-daily 30 --keep-monthly 12 \
  --backup-repository primary-locked \
  --recovery-site <site-id> --recovery-rung warm \
  --rpo-target 24h --rto-target 1h \
  --mandatory

openstack backup policy assign gold --domain <domain-id>
Deployment

Deploy Ferry in your cloud

Use your existing deployment tooling to connect Ferry to OpenStack and your storage backends.

Explore deployment documentation

kolla-ansible

2025.1 and later

Add Ferry to the deployment workflow that manages your OpenStack services.

  • Keystone service registration and Kolla HAProxy integration
  • Logs in OpenSearch and metrics in Prometheus
  • SAN fabric reads and Ceph RGW bucket protection

For OpenStack clouds managed with kolla-ansible 2025.1 or later.

Helm

Kubernetes-based deployments

Deploy a single Helm chart with presets for your OpenStack distribution.

  • OpenStack-Helm 2025.1 and later
  • Red Hat OpenStack Services on OpenShift (RHOSO) 18.0
  • Additional distribution-specific presets

Additional presets: Atmosphere, Genestack, StarlingX, MOSK, and Yaook.

Juju

Charmed OpenStack and Sunbeam

Integrate Ferry with your cloud through Juju charms and service relations.

  • Two machine charms: ferry and ferry-compute
  • Relations for MySQL Router, Keystone, and Ceph
  • Automatic backup service registration in the catalog

For Charmed OpenStack and Sunbeam environments.

Built for day-to-day operations

Runtime requirements: OpenStack with libvirt and KVM; MariaDB 10.6+ or MySQL 8.0.16+.

Scale service capacity

Run multiple manager replicas without leader election and scale data movers horizontally.

Control storage impact

Set backup I/O limits, with automatic pauses when Ceph is unhealthy.

Recover the catalog

Rebuild the backup catalog from the repository when service metadata must be recovered.

No guest-side Ferry agent

No Ferry agent is installed in guests. Filesystem-consistent backups use the QEMU guest agent.

Protected storage

Source backends for instance, volume, and object backups.

  • Ceph RBD volumes and Nova disks
    Incremental reads of changed blocks
  • SAN arrays over iSCSI or NVMe/TCP
    Pure, PowerStore, PowerMax, Unity, 3PAR, Nimble, Hitachi VSP, OceanStor, Storwize, Infinidat
  • NetApp ONTAP over NFS, IBM GPFS
    Full source reads with deduplicated uploads
  • Cinder LVM, Nova qcow2 and raw disks
    Hypervisor-based disk reads
  • Ceph RADOS Gateway buckets
    Object-level backup

Backup repositories

Storage targets for retention, recovery, and secondary copies.

  • S3-compatible object storage
    Immutable retention on repositories configured with S3 Object Lock
  • Ceph pool
    Direct RADOS writes
  • Mounted filesystem
    POSIX filesystem paths
  • Instant-restore tier
    Ceph-backed storage for rapid volume recovery
  • Secondary repository
    Additional backup copies with independent retention
FAQ

Frequently asked questions

Technical considerations for operating Ferry in an OpenStack environment. Refer to the documentation for configuration and deployment details.

Operators define backup policies and provision the underlying repositories. Tenants create protection plans, select available policies, and perform on-demand backups and restores through the OSIE portal, Horizon, or the openstack backup CLI. Authorization is controlled by oslo.policy rules and Keystone roles, keeping self-service within operator-defined permissions.

Ferry in the recovery region needs access to the backup repository, and protected instances or volumes must be bound to target projects. Recovery profiles map infrastructure settings such as flavors and networks between regions. Once configured, tenants can restore available backups in the target project without access to the source region. Backup policies identify the recovery site and recovery targets.

Repositories configured with S3 Object Lock in compliance mode prevent backup deletion or overwrite before retention expires, including by tenants and operators. Ferry also flags unusual changes in compressibility or extensive disk rewrites that may indicate encryption activity. These signals support investigation, while retained recovery points provide options for recovery.

With the QEMU guest agent available, Ferry coordinates a filesystem freeze while snapshotting the root disk and attached volumes to produce a filesystem-consistent backup. Without the guest agent, backups are crash-consistent and labeled accordingly. Filesystem consistency does not imply application consistency. Ferry does not install its own agent inside the guest.

The API and openstack backup CLI expose protected and stored bytes per project, together with RPO compliance per protection plan. Usage figures are attributable to each project's backups and do not depend on other projects' data. Cloud management and billing platforms can consume these metrics for service billing or internal chargeback.

Ferry is developed by the OSIE team, which also builds the OSIE dashboard and billing platform for OpenStack operators.

Plan backup and disaster recovery for your cloud

Discuss your storage architecture, tenant protection requirements, and recovery objectives with the OSIE team. Explore the documentation for deployment details.

Schedule a DemoDocumentation