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

OpenStack is built on the principle of self-service infrastructure. Backup has historically been the exception — a centrally administered function with no tenant visibility. This guide walks through building a production-grade self-service backup portal backed by the Storware Backup and Recovery REST API: per-tenant inventory scoping, on-demand backup, restore initiation, task monitoring, and Horizon integration.

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.

Ceph RBD as a storage backend. Ceph RBD is not a separate backup strategy — it is a storage backend option that works with both Disk Attachment strategies above. When Ceph RBD is configured as the volume backend, Storware uses RBD snapshot differencing to fetch changed-block information for incremental backups under Strategy 1.

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.

For multi-domain OpenStack deployments using Keystone v3, Storware supports both unscoped (single credentials enumerating multiple domains) and scoped (per-domain credentials) authentication models. The scoped model is recommended for production multi-tenant deployments; inventory scoping via tenantID works within each Authentication Domain.

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.

Instant Restore for OpenStack: Storware uses an NFS share on the Node as a Cinder NFS backend. When triggered, OpenStack boots the instance directly from this volume — no full data transfer wait. Data migration back to primary storage happens in the background via standard Cinder migration.

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.

Storware also provides a dedicated Skyline Plugin for full compatibility with the modern OpenStack Skyline UI, for deployments that have moved away from Horizon.

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?

Does the Storware API support OpenStack multi-domain deployments?

Can tenants access backup and restore operations without a Storware admin account?

How does Instant Restore work for OpenStack?

Which OpenStack versions does Storware support?

Is the OpenStack Horizon UI plugin free to use?

Can the portal trigger cross-hypervisor restores or V2V migrations?

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.

Running OpenStack? Let’s talk about your backup architecture.

Our engineers have been building backup solutions for OpenStack since before it was mainstream. Book a session and we will walk through your specific environment — storage strategy, multi-tenancy model, and portal integration requirements. Book a Meeting →