How to Build an OpenStack Self-Service Backup Portal with the Storware API

Why OpenStack Demands a Different Approach to Backup

A general-purpose backup product designed around VMware or Hyper-V can be extended to cover OpenStack. In practice, that extension usually means OpenStack is treated as a second-class citizen: the backup admin connects it as a generic hypervisor, policies are applied manually in a separate console, and tenants have no self-service mechanism at all.

The problem runs deeper than UX. OpenStack organises resources around projects (tenants). Instances, volumes, and snapshots are project-scoped. Access control is enforced through Keystone tokens. A backup solution that does not model this project structure natively cannot deliver genuinely tenant-aware protection — it can only simulate it through manual administrative mapping.

Storware Backup and Recovery was built with this topology in mind. The platform communicates with OpenStack’s Keystone, Nova, Glance, Cinder, and Neutron APIs to collect metadata, respects Keystone v3 domains and projects for authentication scoping, and exposes a tenantID parameter across its own REST API that maps directly to OpenStack project IDs. The result is a backup layer that is structurally aligned with how OpenStack actually works — not grafted onto it.

Backup Strategies: Choosing the Right Engine for Your OpenStack Storage

Before designing the portal, it is worth understanding what Storware does at the infrastructure level for OpenStack — the backup strategy affects what the API returns, how incrementals behave, and what network access the Storware Node requires. Storware supports two current backup strategies for OpenStack, both based on Cinder-driven disk attachment to a Proxy VM. No access to the hypervisor OS is required for either strategy.

Strategy 1 — Disk Attachment

The Storware Node attaches Cinder-snapshotted volumes one by one to a Proxy VM deployed in each Availability Zone, and reads data directly on the Proxy VM. Storware communicates with the OpenStack service API to coordinate volume attachment. This strategy works with any Cinder-compatible storage backend and supports full backups for all volume types. Incremental backups are supported when Ceph RBD is configured as the storage provider — Storware queries the Ceph monitors directly for changed-block information.

Strategy 2 — Disk Attachment with Generic Incremental Preferred

The same Cinder-based disk attachment model, but with storage-backend-independent incremental backups implemented through block-level checksum comparison. This makes incremental backups available regardless of the underlying Cinder backend — no Ceph dependency, no hypervisor access requirement. The trade-off is higher resource usage on the Proxy VM during incremental computation, since checksums are computed and compared on every protected block.

This is the strategy Storware recommends for new OpenStack deployments. It delivers the full incremental + synthetic + file-level-restore feature set, on any Cinder-compatible storage backend, without requiring access to the hypervisor operating system or to Ceph monitors.

Architecture of a Self-Service Backup Portal

A self-service backup portal for OpenStack has three layers:

• Frontend — the portal UI: a custom app, an ITSM integration, or an extension to OpenStack Horizon or Skyline.
• Storware REST API — the authoritative backend for all backup operations: scheduling, task distribution, load balancing, status tracking.
• Storware Nodes — the data movers that execute backup and restore tasks against the OpenStack infrastructure, communicating with OpenStack APIs and Proxy VMs.

The portal never talks to the hypervisor directly. All operations flow through the Storware API. The interaction model from the portal’s perspective is clean and consistent:

• Authenticate once per session — POST to /session/login, save the session cookie.
• Scope inventory by OpenStack project — use the tenantID filter to show each tenant only their own instances.
• Trigger backup jobs — POST to /tasks/export with the instance GUID, backup type, time window, and priority.
• Initiate restores — POST to /tasks/restore with the backup point GUID and restore configuration.
• Monitor task progress — poll GET /tasks/{taskId} for status, progress percentage, and completion events.

Step-by-Step: Implementing the Portal Backend

Step 1 — Authentication

All API communication runs over HTTPS on port 8181 (optionally port 443). The base URL is:

https://STORWARE_SERVER:8181/api

For Storware to talk to OpenStack itself, the Node needs access to the Keystone endpoint:

https://KEYSTONE_HOST:5000/v3

Authenticate with a dedicated service account scoped via RBAC to the minimum required permissions:

POST /session/login
Content-Type: application/json
 
{
  "login": "portal-service-account",
  "password": "<password>"
}

Save the returned session cookie. If you receive a 401 Unauthorized on any subsequent call, re-authenticate and retry.

Step 2 — Listing Instances Scoped to an OpenStack Project

This is the core of the multi-tenancy model. When a tenant logs into the portal, query their instances using their OpenStack project ID as the tenantID filter:

GET /virtual-machines?tenantid={OPENSTACK_PROJECT_ID}

The response returns all instances Storware has inventoried for that project. Each instance object includes its GUID (used in all subsequent API calls), UUID (the OpenStack instance UUID), display name, assigned policies, protection status, and last backup timestamps. Storware’s inventory sync runs on a configurable schedule, so new instances appear automatically and terminated instances are retained in history.

Step 3 — Retrieving Instance Details and Backup History

When a tenant selects an instance, fetch its full details and available backup points:

GET /virtual-machines/{guid}
GET /virtual-machines/{guid}/backups

Each backup point object includes its GUID, creation timestamp, backup type (FULL or INCREMENTAL), size, and status — everything needed to render a restore timeline in the portal UI.

Step 4 — Triggering an On-Demand Backup

On-demand backups are initiated by creating an export task. The portal supplies the instance GUID, backup type, time window, and priority:

POST /tasks/export
Content-Type: application/json
 
{
  "virtualMachine": { "guid": "<instance-guid>" },
  "backupType": "INCREMENTAL",
  "priority": 50,
  "windowStart": <unix-ms>,
  "windowEnd": <unix-ms>
}

The windowStart and windowEnd fields define the time window within which the task must start — if it does not start within this window, it fails gracefully rather than running unexpectedly. A store task is chained automatically once the export completes. The response includes the task GUID for status polling.

Step 5 — Initiating a Restore

Restores are triggered against a specific backup point GUID, with full control over the target environment, network mapping, VM flavour, access key, and security group:

POST /tasks/restore
Content-Type: application/json
 
{
  "backup": { "guid": "<backup-point-guid>" },
  "targetEnvironment": { "guid": "<openstack-env-guid>" },
  "restoreNetworkConfig": { ... },
  "vmFlavor": { "guid": "<flavor-guid>" }
}

As of Storware Backup and Recovery 7.x, operators can also specify which security group to assign to the restored VM — a detail that matters significantly when restoring into a different project or availability zone. Access keys (OpenStack keypairs) and flavours can be specified in the restore configuration; when restoring to a different OpenStack environment than the source, or to Nova versions where flavour ID cannot be auto-fetched, the flavour must be specified explicitly.

Step 6 — Monitoring Task Progress

Poll the task status endpoint until the task reaches a terminal state:

GET /tasks/{taskId}

The response includes current status, progress percentage, start/end timestamps, and error details on failure. For portal UX, a polling interval of 5–10 seconds is appropriate for active operations; drop to 30–60 seconds for scheduled background jobs.

The Faster Path: Storware’s OpenStack Horizon UI Plugin

For teams that need self-service capability immediately without building a custom portal, Storware provides a ready-made integration: the OpenStack Horizon UI plugin. After installation, a dedicated “Backup & Recovery” tab appears in the OpenStack Dashboard, giving tenants direct access to backup and restore operations without leaving Horizon.

The plugin is open-source and available on GitHub. Installation is straightforward:

git clone https://github.com/Storware/openstack-horizon-ui-vprotect-extensions
python3 install.py http://STORWARE_SERVER:8080/api <admin_user> <admin_password>

Restart the Horizon HTTP server and the plugin becomes active. It surfaces the following capabilities directly to tenant users:

• Instance inventory — all instances in the tenant’s project with protection status and last backup timestamp.
• On-demand backup — trigger immediate backups without contacting the platform administrator.
• Restore from backup history — browse available backup points, select a restore target, initiate recovery, including file-level browsing and individual file download from mounted backup data.
• Schedule management — create and modify backup schedules scoped to the tenant’s instances.
• Task monitoring — real-time status of running and recently completed backup and restore jobs.
• Reporting — per-tenant backup statistics and event history for chargeback or compliance reporting.

Automating Policy Assignment for New Instances

Self-service portals solve the on-demand use case. The more valuable automation is ensuring every new instance is protected automatically from the moment it is provisioned — without any action from the tenant or the platform administrator. Storware supports two mechanisms:

• Tag-based assignment — when a new OpenStack instance is tagged with a specific Nova tag (Nova API version 2.26 or later required), Storware’s inventory sync detects the tag and applies the matching SLA policy automatically. This integrates cleanly with Heat templates and Terraform providers — provisioning tooling applies the tag at creation time, backup policy follows automatically.
• VM name-based assignment — instances whose names match a configured regular expression are assigned to the corresponding policy. Useful for naming conventions like prod-*, db-*, or per-project prefixes.

For environments provisioned through a service catalog, the API-based approach is often preferable: the provisioning workflow calls POST /policies/assign after the instance appears in Storware’s inventory, binding backup policy to the infrastructure lifecycle explicitly.

Security Considerations for Multi-Tenant Portal Deployments

A self-service backup portal introduces a service account with API access to Storware that multiple tenant sessions flow through. Several controls are essential:

• Dedicated service account with RBAC — create a Storware account for portal operations with the minimum role required: read-only access to inventory, write access to on-demand tasks, no access to administrative functions like policy creation or destination management.
• Keycloak MFA for admin access — Storware integrates with Keycloak for multi-factor authentication. Enforce MFA on all admin accounts to prevent credential-based compromise of the backup management layer.
• Tenant scoping enforced server-side — never trust client-supplied project IDs without validating them against the authenticated user’s Keystone token. An attacker who can supply arbitrary tenantID values should not be able to enumerate another tenant’s backup data.
• HTTPS only, certificate validation enabled — all API communication must use HTTPS with a valid certificate. Replace the Node’s self-signed certificate with a properly signed one before exposing the API to a portal.
• IsoLayer Air-Gap for backup data — for high-security environments, Storware’s IsoLayer Air-Gap feature creates an immutable, network-isolated copy of backup data that cannot be reached through the regular API surface, protecting against compromised portal credentials.

Frequently Asked Questions

• Which backup strategy should I choose for a new OpenStack deployment?
  For new deployments, Storware recommends Disk Attachment with Generic Incremental. It delivers full, incremental, and synthetic backups on any Cinder-compatible storage backend, with no dependency on Ceph monitors and no requirement for hypervisor OS access. The plain Disk Attachment strategy is preferred only when you are running Ceph RBD storage and want to use Ceph’s native snapshot differencing for incremental backups instead of block-level checksum computation.
• Does the Storware API support OpenStack multi-domain deployments?
  Yes. Storware supports Keystone v3 Authentication Domains in two modes: unscoped (a single set of credentials enumerates resources across every domain the user has access to) and scoped (per-domain credentials, with each Authentication Domain configured separately in Storware). The scoped model is recommended for production multi-tenant deployments. Inventory scoping via tenantID works within each domain.
• Can tenants access backup and restore operations without a Storware admin account?
  Yes — this is the entire point of the self-service model. The portal uses a single shared service account to talk to the Storware API; tenant identity and access control are managed on the portal side (or via Keystone token validation). The Horizon plugin follows the same pattern: tenants interact through their normal OpenStack Horizon session, and the plugin talks to Storware on their behalf.
• How does Instant Restore work for OpenStack?
  Instant Restore for OpenStack requires an NFS share configured on the Storware Node and an NFS backend added to OpenStack’s Cinder service. When triggered, Cinder mounts the NFS share and presents the backup data as a Cinder volume. OpenStack boots the instance directly from this volume — typically within minutes. Data migration back to primary storage then happens in the background using standard Cinder migration.
• Which OpenStack versions does Storware support?
  Storware Backup and Recovery currently supports OpenStack releases from Wallaby through Epoxy, as well as Red Hat OpenStack Platform 17.1 and 18.0, and Canonical OpenStack (Sunbeam) 2024.1. Nova tag-based policy assignment requires Nova API version 2.26 or later.
• Is the OpenStack Horizon UI plugin free to use?
  Yes. The Horizon plugin is open-source and available on GitHub. It is included with all Storware Backup and Recovery deployments — no additional licensing is required. The same applies to the Skyline Plugin.
• Can the portal trigger cross-hypervisor restores or V2V migrations?
  Yes. Storware Backup and Recovery 7.1 introduced cross-hypervisor restore capability, including VM-to-VM migration from VMware vSphere directly into OpenStack. This is triggered via the same restore API endpoint with the target environment set to an OpenStack environment — directly relevant for teams protecting workloads during VMware-to-OpenStack migration.

Conclusion

OpenStack was designed to give tenants control over their infrastructure. A backup layer that forces every protection decision through a central admin queue undermines that model — and leaves data exposed in the gaps between requests and responses. A properly designed self-service portal closes those gaps: tenants trigger and monitor their own operations, policies are applied automatically at provisioning time, and the platform administrator’s role shifts from request handler to architect.

Storware Backup and Recovery provides the infrastructure that makes this possible: a fully documented REST API with native OpenStack project scoping, two production-ready Cinder-based backup strategies covering every OpenStack storage backend, a ready-made Horizon UI plugin for immediate self-service deployment, and a universal licensing model that adds no per-feature cost to API access or additional platform support.

The architecture described here is not a roadmap — it is a deployment pattern in production use across OpenStack environments today.