> 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/platform9.md). # Platform9 PCD ## Overview Storware Backup and Recovery supports backup and restore operations for **Platform9 PCD.** Storware Backup and Recovery can uses the following backup strategy: * **Disk attachment with generic incremental** – supportincremental backup regardless of the underlying storage backend ### Backup Strategies #### Disk attachment with generic incremental Storware Backup & Recovery also supports the disk-attachment method using cinder where incremental backups are supported regardless of the underlying storage backend. This strategy however, requires more resources as it uses block-level checksum computation. Storware Backup & Recovery needs to communicate the OpenStack service's API to attach drives to the proxy VM with Storware Backup & Recovery Node installed. ![](/files/ApiEr0eLZehbgsbZNhV3) **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 using checksum computation * 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 that 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 ### Supported features **Supported backup strategies:** Disk attachment with generic incremental
Disk attachment with generic incremental (preferred)
Supported versionsP9 PCD 2025.10-180
The last snapshot is kept on the hypervisor for incremental backupsNo
Access to hypervisor OS requiredNo
Proxy VM requiredYes
Full backupSupported
Synthetic backupsSupported
File-level restoreSupported
VM disk exclusionSupported
Quiesced snapshotsNot supported
Snapshots managementSupported*
Pre/post command executionSupported
Access to VM disk backup over iSCSISupported
VM name-based policy assignmentSupported
VM tag-based policy assignmentSupported
Power-on VM after restoreSupported
*\* Without snapshot revert* ### 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 | ### 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 %} ### 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. * Backup and restor of Glance images is not supported ## General configuration 1. Go the **Virtual Environments -> Virtualization Providers** and click **Create** 2. Select **Platform9 PCD** 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 Platform9 PCD 2. **URL** - Keystone API URL, e.g. `https://platform9_fqdn/keystone/v3` 3. **Region -** provide the name of your region (each region must be added as a separate hypervisor manager 4. **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 **Platform9 settings** tab: 1. **Endpoint interface type** - interface type used to connect to the OpenStack services' endpoints returned from your Keystone 5. In the **Authentication domain** tabs 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 7. Run both full and incremental backups to verify the setup.