Instant Restore for OpenStack: Recover VMs Fast

When an OpenStack instance goes down, the recovery time that matters is how long until it is running again — not how long the copy takes to move. Traditional recovery restores data back into the environment before the instance can boot, and for large volumes that means hours. Storware’s Instant Restore for OpenStack removes that wait: the instance boots directly from backup storage while it is still there, so recovery is measured in minutes.

What Instant Restore does

Instant Restore recovers an OpenStack instance directly from the backup destination, without first copying all its data back into production storage. Storware presents the backup data to Cinder as an NFS-backed volume type; the instance boots from it immediately, and I/O is served transparently by Storware Backup and Recovery. From OpenStack’s point of view, nothing unusual happens — the instance simply starts. (docs: OpenStack — Instant Restore)

Why it matters for RTO

Recovery time objective (RTO) is where this feature earns its place. Because the instance runs before the full data set is relocated, RTO drops from hours to minutes — the difference between an outage users feel and one they barely notice. It also simplifies the recovery path: fewer manual steps, less coordination, and a predictable route back to service. (For the broader RTO/RPO planning picture, see our Disaster Recovery page.)

How Instant Restore works

The mechanism is a transparent redirection of storage I/O:

The backup destination is exposed to Cinder as a dedicated NFS-backed volume type.
After inventory synchronization detects that volume type, you map it to your node(s).
On restore, the instance’s volumes are backed by data in the backup destination rather than freshly restored copies.
The instance boots and runs from that path; Storware serves the I/O in the background, so no full restore is required before the workload is available.

Configuration overview

Setup happens on the storage side. In outline:

On a dedicated node, create and export an NFS share for restores, e.g.:

  /vprotect_data/instant_restore/ *(fsid=0,no_subtree_check,rw,sync,no_root_squash,insecure)

Add an NFS backend to /etc/cinder/cinder.conf pointing at that share:

  volume_backend_name = nfs-instant-restore
  volume_driver = cinder.volume.drivers.nfs.NfsDriver
  nfs_shares_config = /etc/cinder/nfs_shares

Run inventory synchronization, then in the Node edit window select the storage with the NFS backend and complete the volume-type mapping.

Instant Restore uses the current Cinder disk-attachment transfer strategy (Ceph RBD direct is the other current path); the deprecated Libvirt/SSH transfer is not used.

Limitations and when to use it

Two constraints matter in planning:

A dedicated node is required for the Instant Restore NFS backend — it cannot double up with other roles.
Ephemeral disks are not supported — only persistent (Cinder) volumes are eligible.

Use Instant Restore when RTO is the priority: production outages, DR failover tests, or spinning a workload back up fast. When you need the instance to end up permanently on production storage, follow the boot with a migration of the volumes to your production backend.

Where it fits your OpenStack data protection

Instant Restore is one capability inside Storware’s #1 Backup & DR for OpenStack — native, storage-agnostic protection built for OpenStack at scale. It empowers teams to hit demanding recovery objectives without over-provisioning restore storage, and keeps Data Protection Continuity from backup through to a running instance.