> For the complete documentation index, see [llms.txt](https://docs.storware.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.storware.eu/protecting-virtual-machines/virtual-machines/openstack.md). # OpenStack ## Overview Storware Backup & Recovery protects virtual machines running in OpenStack. It discovers instances and their attached volumes, creates backups, and allows you to restore protected data when needed. You can configure backup policies for selected instances and manage protection from the Storware Backup & Recovery interface. ### Supported versions
Disk attachment to proxy (full)Disk attachment with generic incremental
Supported versions2023.1 Antelope, 2024.1 Caracal, 2025.1 Epoxy, 2025.2 Flamingo, 2026.1 Gazpacho

Red Hat OpenStack Platform: 17.1, 18.0

Canonical OpenStack: 2024.1 LTS (Sunbeam), 2024.1 (Charmed)

WindRiver Openstack 25.09, WindRiver Cloud Platform 26.03		2023.1 Antelope, 2024.1 Caracal, 2025.1 Epoxy, 2025.2 Flamingo, 2026.1 Gazpacho

Red Hat OpenStack Platform: 17.1, 18.0

Canonical OpenStack: 2024.1 LTS (Sunbeam), 2024.1 (Charmed)

WindRiver Openstack 25.09, WindRiver Cloud Platform 26.03
The last snapshot is kept on the hypervisor for incremental backupsYesNo
Access to hypervisor OS requiredNoNo
Proxy VM requiredYesYes
Full backupSupportedSupported
Incremental backupNot supportedSupported
Synthetic backupsSupportedSupported
Secondary backup destinationNot supportedSupported
File-level restoreSupportedSupported
VM disk exclusionSupportedSupported
Quiesced snapshotsNot supportedNot supported
Snapshots managementSupported (Without snapshot revert)Supported (Without snapshot revert)
Pre/post command executionSupportedSupported
Access to VM disk backup over iSCSISupportedSupported
VM name-based policy assignmentSupportedSupported
VM tag-based policy assignmentSupportedSupported
Power-on VM after restoreNot supported (always on)Not supported (always on)
### Network requirements #### Disk attachment with generic incremental **Connection URL:** `https://KEYSTONE_HOST:5000/v3` | Source | Destination | Ports | Description | | ------ | --------------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Node | Keystone, Nova, Glance, Cinder, Neutron | ports that were defined in endpoints for OpenStack services | API access to the OpenStack management services - using endpoint type that has been specified in hypervisor manager details | #### Disk attachment to proxy VM (full) **Connection URL:** `https://KEYSTONE_HOST:5000/v3` | Source | Destination | Ports | Description | | ------ | --------------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Node | Keystone, Nova, Glance, Cinder, Neutron | ports that were defined in endpoints for OpenStack services | API access to the OpenStack management services - using endpoint type that has been specified in hypervisor manager details | | Node | Ceph monitors | 3300/tcp, 6789/tcp | if Ceph RBD is used as the backend storage - used to collect changed-blocks lists from Ceph | ### Backup Strategies #### Disk Attachment with generic incremental Automatically selects the incremental method for each volume. It uses native changed-block tracking for Ceph and Pure Storage, and checksum-based processing for other storage backends. ![](https://content.gitbook.com/content/rOgv7hQUSgzt1N4wNaDx/blobs/CGjMj18AIw9wEQUYdBHk/protecting_ve-virtual_machines-openstack-disk-attachment.png) #### Disk attachment to proxy VM (full) - deprecated This strategy uses the Cinder API to attach volumes to a proxy VM running Storware Backup & Recovery Node. It supports full backups for Cinder-compatible storage. Incremental backups are available for Ceph RBD volumes when a storage provider is specified in the volume type on the **Storage** tab. ![](https://content.gitbook.com/content/rOgv7hQUSgzt1N4wNaDx/blobs/CGjMj18AIw9wEQUYdBHk/protecting_ve-virtual_machines-openstack-disk-attachment.png) ![Storware Backup & Recovery also supports deployments with Ceph RBD as a storage backend. Depending on the strategy, the communication between the node and the Ceph monitor is used for a different purpose:](https://content.gitbook.com/content/rOgv7hQUSgzt1N4wNaDx/blobs/VonDVnicq0kt5vQkkZSl/protecting_ve-virtual_machines-openstack-disk-attachment-ceph.png) **Backup process:** * crash-consistent snapshot using cinder API * optional application consistency using pre/post snapshot command execution * metadata exported from API * volumes created from snapshotted disks are mounted one by one to the Proxy VM * data read directly on the Proxy VM * incremental backups supported for Ceph RBD - a list of the changed blocks are fetched from the monitors, and only these blocks are read from the attached disk on the Proxy VM * if an instance is created from the glance image and "download image from glance" option is enabled data is downloaded from glance API, an instance is created from the instance metadata, and the images which are fetched from the glance API * restore creates empty disks on the Proxy VM, imports merged data then recreates the VM using these volumes, it will try to use the image from a glance if present in the target environment or it will upload the image to the glance and register it with the restored VM ### Authentication Domains Storware Backup & Recovery supports OpenStack environments with multiple domains. Each OpenStack Hypervisor Manager needs to have at least one Authentication Domain provided. Storware Backup & Recovery supports two types of domain authorization: * Unscoped - single credentials to multiple domains * Scoped - credentials to individual domains #### Unscoped - single credentials to multiple domains **Use domain-scoped authorization** option needs to be turned **OFF**. With this setup, the user needs to create only one Authentication Domain. Projects and Virtual Machines are scanned in every domain that the provided user has access to. **Required permissions:** * The account must be able to access and enumerate resources in every domain that should be scanned. * Assign to this account an **admin role across all domains applicable** in your environment, and ensure **role inheritance** is enabled so access is effective in underlying projects: ``` for d in DOMAIN_A DOMAIN_B DOMAIN_C; do openstack role add admin \ --user STORWARE_SVC_USER --user-domain DOMAIN_A \ --domain "$d" \ --inherited done ``` * You can also use **LESS SECURE alternative - system scope:** ``` openstack role add admin \ --user STORWARE_SVC_USER --user-domain DOMAIN_A \ --system all ``` #### Scoped - credentials to individual domains **Use domain-scoped authorization** option needs to be turned **ON**. With this setup, the user can create Authentication Domains for every domain in OpenStack environment. Projects and Virtual Machines are only scanned in the provided Authentication Domains. **Required permissions:** * Separate accounts in individual domains must be assigned the **admin** role on the **domain level** (not only on a single project). * Inheritance must be enabled so that the domain-level role is propagated “down” to projects contained in that domain.
``` openstack role add admin \ --user STORWARE_SVC_USER_A --user-domain DOMAIN_A \ --domain DOMAIN_A \ --inherited openstack role add admin \ --user STORWARE_SVC_USER_B --user-domain DOMAIN_B \ --domain DOMAIN_B \ --inherited .... ``` ### Tags Tags in Nova are also scanned (when nova API ≥ 2.26). Tags can later be used in the auto-assignment of the backup policy. {% hint style="info" %} Tags themselves are **not** part of the backup. {% endhint %} You can list tags for a specific instance in the OpenStack using this command: ``` root@c254:~# nova show d6787375-ea0c-49fd-878b-35b71747c62a |grep tags | tags | ["test"] ``` ### Access Keys During Inventory Synchronization, Storware Backup & Recovery scans all Keypairs (to which a user has access) and lists them as Access Keys. Access keys are not exported during backup. When restoring the instance, in the restore modal -> Advanced tab, the user can specify the Access Key (otherwise, the instance will be restored without one). ### Flavors During Inventory Synchronization, Storware Backup & Recovery scans all Flavors and saves their configuration. When restoring an instance, in the restore modal -> Advanced tab, the user can specify the flavor. {% hint style="info" %} When restoring to a different OpenStack than the original instance was backed up, or the nova version is higher than 2.46 (where flavor ID cannot be fetched from the nova API) - you always need to specify in the restore modal -> Advanced tab which flavor should be used for recovery. {% endhint %} ### Metadata This feature introduces support for protecting additional OpenStack metadata during backup and restore operations. Backup jobs now capture extended metadata associated with instances, volumes, and ports. This metadata is stored alongside the backup metadata and can be optionally restored during virtual machine recovery, helping to preserve the original configuration and deployment characteristics of the protected workload. This feature is fully backward compatible. Existing backups remain fully supported, and restore operations can be performed safely regardless of whether the additional metadata restore option is enabled or disabled. The following OpenStack metadata is included in backup operations and can be restored during VM recovery. #### **Instance Metadata** `OS-EXT-SRV-ATTR:user_data` , `config_drive` , `locked_state` , `locked_reason`, `properties`, `tags`, `description` #### **Volume Metadata** `description`, `properties`, `volume_image_metadata` #### **Port Metadata** `admin_state_up`, `description`, `dns_domain`, `dns_name`, `extra_dhcp_opts`, `numa_affinity_policy`, `propagate_uplink_status`, `tags` {% hint style="warning" icon="person-waving" %} Only the metadata attributes listed above are protected and restored by this feature. Any OpenStack metadata not explicitly listed is not included in the additional metadata backup and restore process. The set of protected attributes may be extended in future releases. {% endhint %} #### Restore Additional metadata restoration can be enabled during virtual machine recovery in the **Advanced** step of the restore wizard. The following options are available: * **Restore with Instance Metadata** – Restores protected instance metadata. * **Restore with Disk Metadata** – Restores protected Cinder volume metadata. * **Restore with Port Metadata** – Restores protected network port metadata. #### Error Handling Restoration of additional metadata is performed as a post-import operation. If restoration of any metadata component fails, the virtual machine restore process is not interrupted. Metadata restoration failures are logged, and the restore workflow continues to completion. This ensures that a successfully restored virtual machine remains available even if one or more metadata objects cannot be applied. Example log entry: ``` [ERROR] Post-import step failed for server ``` Administrators should review the application logs after the restore operation to identify and resolve any metadata restoration issues. ### Limitations * Storware Backup & Recovery does not backup and restores keypairs that user used in Storware Backup & Recovery doesn't have access to. The restored instance will have no keypairs assigned. In such a case, the keypairs have to be backed up and restored manually under the same name before restoring the instance. * For the libvirt strategy only, QCOW2/RAW files or Ceph RBD are supported as the backend. * The disk attachment method with Ceph requires access to the monitors from the Proxy VM. ## Protecting Openstack {% hint style="info" %} This section covers the advanced setup of OpenStack protection. For most deployments, including complex environments, you can use the configuration wizard available from the dashboard. The Storware Backup & Recovery server and node must be installed before you start the wizard. {% endhint %} 1. Go the **Virtual Environments -> Virtualization Providers** and click **Create** 2. Select **OpenStack** at the top 3. In the **General** tab: 1. specify **Node configuration** for the nodes communicating with the keystone 1. later you can override these settings on the Hypervisor level, but for now, select node config that is able to communicate with your OpenStack KeyStone 2. if using the **disk attachment** method, it has nodes residing in their corresponding **Proxy VMs** 2. **URL** - Keystone API URL, e.g. `https://10.201.32.40:5000/v3` 3. **Region -** provide the name of your region (each region must be added as a separate hypervisor manager 4. **Choose import/export mode** 5. **Trust certificates** - if you're using certificates that may not be trusted by you nodes - e.g. self-signed - you can enable this toggle. By default they will be imported automatically when connecting for the first time anyway. 4. In the **OpenStack settings** tab: 1. **Endpoint interface type** - interface type used to connect to the OpenStack services' endpoints returned from your Keystone 2. **Download image from glance:** 1. when enabled - this setting **only applies when OS (boot) volume is either:** 1. **nova volume** 2. **cinder volume from image** 2. the image will be downloaded **only if the OS (boot) volume is not excluded**. 3. this setting will **download the OS image from glance** instead of the OS (boot) volume 4. this means that **changes applied to the OS (boot) volume will be discarded**, and the original glance image (the one used to create the instance, and in the resulting backup) will be later used for recovery 5. this may be useful for a disk-attachment strategy (**where nova volumes are not supported**), and you still need to recover the instance to another OpenStack, where this image doesn't exist. 3. **Use domain-scoped authorization** - depending on your use case 1. single credentials with the permission to access all OpenStack authentication domains and projects -> then this toggle should be **disabled,** and the credentials should be provided in the only Authentication Domain tab on the left available 2. separate Authentication domains - then this toggle should be **enabled**, and all authentication domains used for authentication should be defined on the left with (+) icon 5. In the **Authentication domain** tabs (you can use your OpenStack RC file to fill these fields): 1. **Name** - name of domain 2. **DomainI ID** - optional domain ID 3. **User/Password** - OpenStack user and password 4. **Default project** - name of default project in the domain being defined 6. Save and **run first inventory sync** - this will also detect hypervisors, which may require 2 things: 1. assigning different node configurations to specific hosts (this must correspond with your AZ setup 2. providing SSH credentials (when using SSH Transfer backup strategy) 7. When you want to use the **Ceph RBD variant** in your backup strategy: 1. make sure to have this setup done **for all nodes** that will need access to the Ceph monitors 2. Make sure that volumes have appeared in **Storage -> Instances** tab to confirm connectivity between node and Ceph monitors 3. **for each Ceph RBD Storage (volume type),** assign your Ceph storage provider and the appropriate Ceph storage pool in **Virtual Environments -> Infrastructure -> your hypervisor manager details -> Storage -> volume type -> Ceph settings** 8. When your environment uses an **NFS storage backend**, make sure to enable QCOW2 file support. Otherwise, backup snapshots will create RAW files (instead of QCOW2): 1. it's recommended to set these values in `/etc/cinder/cinder.conf`:
``` default_volume_type = nfs nfs_sparsed_volumes = true nfs_qcow2_volumes = true volume_driver = cinder.volume.drivers.nfs.NfsDriver enabled_backends = nfs ``` 9. Run both full and incremental backups to verify the setup. ## Instant restore setup ### Node configuration First step to initiate the configuration process for OpenStack Instant Restore service, is creating a directory that will be accessible for mounting by the NFS server. Create a specific directory on your Node machine that will be used as the target space for Instant Restore's shared resources. ``` mkdir /vprotect_data/instant_restore/ chown -R vprotect:vprotect /vprotect_data/instant_restore/ ``` Next, create an NFS share that will allow access to the `/vprotect_data/` directory from other machines in the network. Sharing this directory will enable OpenStack clients to use it for virtual machine restoration. ``` echo '/vprotect_data/ *(fsid=0,no_subtree_check,rw,sync,no_root_squash,insecure)' >> /etc/exports exportfs -arv ``` ### Cinder storage backend configuration {% hint style="info" %} Paths and commands may vary depending on the version of OpenStack you are using. {% endhint %} After creating the NFS share on the node, you need to configure the NFS backend in the cinder service. This step will allow OpenStack to access resources stored on the node via NFS. Edit the `/etc/cinder/cinder.conf` file and add this section at the end of the file: ``` [nfs-instant-restore] volume_backend_name=nfs-instant-restore volume_driver=cinder.volume.drivers.nfs.NfsDriver nfs_shares_config=/etc/cinder/nfs_instant_restore nfs_snapshot_support=True nfs_qcow2_volumes=True nfs_sparsed_volumes=true nfs_mount_options=vers=4 ``` Create the file you provided in the configuration as the value of `nfs_shares_config` parameter ``` vi /etc/cinder/nfs_instant_restore ``` and path to the NFS share: ``` sbr_node_ip:/instant_restore ``` After creating the NFS server and configuring cinder, restart the cinder volume service. Please note that the name of this service may be different depending on the OpenStack version. ``` systemctl restart openstack-cinder-volume ``` ### Matching nodes to the OpenStack storage backends (volume types) After completing the inventory synchronization of the OpenStack, in Node edition window you can select the storage with the NFS backend configuration. Details about the NFS backend should be supplied by the OpenStack administrator. ![](https://content.gitbook.com/content/rOgv7hQUSgzt1N4wNaDx/blobs/GfgwabytWUaNwHZG2plq/protecting-virtual-environments_virtual-machines_openstack_instant-restore.png) You should now be able to select "Instant restore" for backed up virtual machines. ### Limitations * For OpenStack Instant Restore, a dedicated node is required. * Ephemeral disks are not supported.