Problem Being Solved

Manila, OpenStack's Shared File System service, lets your tenants provision and use NFS and CIFS file shares — but it provides no production-grade facility to back those shares up or restore them when data is lost. This page explains exactly what is missing from the native OpenStack tooling, why that gap matters in multi-tenant, regulated environments, and how Trilio Share Protection for OpenStack (codename Abacá) closes it.

The gap in OpenStack file-share protection

Manila is the OpenStack service tenants use to create and mount shared file systems — NFS exports, CIFS shares, and other protocols — backed by a wide range of storage drivers. Tenants write application data to these shares every day, yet OpenStack has historically offered no built-in mechanism to create recoverable backups of that data or restore it when something goes wrong.

What Manila itself provides

Manila manages the lifecycle of shares: creation, resizing, access rules, and snapshots. A Manila snapshot captures a point-in-time image of a share's state, but it lives on the same storage backend as the original share. If that backend fails, the snapshot fails with it. Snapshots are also local to the backend: they cannot be transferred to off-site or tenant-controlled object storage, and they carry no encryption or immutability guarantees.

What upstream backup APIs leave unresolved

Upstream OpenStack added a share backup API in the 2023.2 release, with a generic NFS driver path in the manila-data service and driver-assisted paths (such as NetApp SnapVault) in the 2024.1 release. Even where these features are available, they do not meet the needs of most multi-tenant production environments:

• Not available on RHOSO 18. RHOSO 18 is based on OpenStack 2023.1 (Antelope) and includes neither the 2023.2 generic backup driver nor the 2024.1 driver-assisted path. Tenants on RHOSO 18 have no upstream backup option at all.
• Operator-controlled storage. The generic NFS backup driver writes to a single admin-managed NFS export that is shared across all tenants and readable by cloud operators. Tenants cannot bring their own bucket or control where their data lands.
• No tenant-owned credentials or keys. Neither the generic path nor the driver-assisted path allows tenants to supply their own encryption key. Backup data is either unencrypted or encrypted under an operator-managed key — meaning the operator can always read it.
• No per-tenant retention or scheduling policies. There is no API for a tenant to define how many backups to keep, on what schedule, or with what retention rules. Policy is either absent or managed at the infrastructure level.
• No immutability guarantee. The native paths do not integrate with S3 Object Lock or any equivalent WORM mechanism. A compromised operator credential or a ransomware attack can silently delete backup data.
• Coarse restore granularity. Full-share restore is the primary model; sub-path and single-file recovery are not available in the native paths on RHOSO 18.
• No metering or chargeback. There is no per-tenant usage API to support billing for protected capacity or restore operations.

What Trilio Share Protection provides

Trilio Share Protection for OpenStack (Abacá) is a standalone backup-and-recovery service that runs alongside your OpenStack deployment and fills every gap described above. Its design starts from the premise that the right owner of backup data is the tenant — not the operator.

Tenant-owned, operator-unreadable backups

Each tenant registers their own S3-compatible bucket as a backup target. The bucket can sit on any S3-compatible endpoint — AWS S3, MinIO, Ceph RGW, Wasabi, or Red Hat ODF. The tenant's S3 credentials and Kopia repository password are stored in their own Barbican secret store; Abacá holds only references (Barbican hrefs) to those secrets and never stores the secrets itself. Encryption keys never leave Barbican. Cloud operators cannot read backup data at rest, and there is no key escrow of any kind.

Immutable backup storage

Abacá enforces S3 Object Lock on every backup target bucket. Object Lock is a WORM (Write Once, Read Many) feature that prevents backup objects from being deleted or overwritten for a specified retention period. Because Object Lock must be enabled at bucket-creation time, Abacá's preflight checks verify it is present before accepting a bucket as a target. Even a compromised credential cannot silently erase backups within the retention window.

Tenant-controlled policies, schedules, and retention

Once a backup target is registered, tenants create protection policies that bind a Manila share to a target, set a cron-based backup schedule, and define retention rules (for example, 7 daily, 4 weekly, and 12 monthly backups). The Abacá conductor runs scheduled backups automatically and reclaims expired backups through a maintenance job that runs Kopia's cleanup against the repository. Tenants control every aspect of their own backup lifecycle without operator involvement.

File-granular, incremental, deduplicated backups

Abacá uses Kopia as its backup engine. Kopia performs incremental-forever, content-deduplicated, client-side-encrypted snapshots of share data. After the first full backup, only changed blocks are transferred — minimizing both transfer time and storage cost. Tenants can restore an entire share, a sub-directory, or a single file, either onto a new share or back onto the original.

Short-lived workers that stay inside the tenant's network

To mount Manila shares and transfer data, Abacá dispatches short-lived worker VMs into the tenant's own network. Workers handle encryption keys and plaintext only in memory during a job; nothing sensitive is written to disk. Once a job completes, the worker is released. This design means the data path is both isolated per tenant and horizontally scalable.

Available on RHOSO 18 today

Abacá ships as a standalone service — a control plane (the abaca-api and abaca-conductor services) running as pods on OpenShift, plus ephemeral worker VMs on RHEL. It does not depend on the Manila backup APIs introduced in 2023.2 or 2024.1. It is available on RHOSO 18 (OpenStack 2023.1 Antelope) right now, with no upstream OpenStack upgrade required.

Comparison with native Manila backup options

The following example shows the fundamental gap Abacá addresses. Suppose a tenant provisions a Manila share and then loses data due to accidental deletion or filesystem corruption. Without Abacá, there is no API call a tenant can make to restore their files:

# Without Abacá: a tenant has no backup or restore API available
# The following Manila commands exist, but none produce an off-site,
# encrypted, tenant-owned backup:
openstack share snapshot create <share-id>   # local snapshot only — same backend
openstack share list                          # no restore-from-backup command exists

With Abacá, a tenant registers their own S3 bucket, creates a protection policy, and can restore a share at any time:

# With Abacá: tenant registers their bucket, backs up, and restores

# 1. Register a backup target (tenant's own S3 bucket)
curl -s -X POST http://localhost:9797/v1/targets \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "primary",
    "endpoint": "https://s3.example.com",
    "bucket": "tenant-abaca",
    "barbican_secret_refs": ["https://barbican/secrets/pw"],
    "trust_id": "trust-1"
  }'
# Expected: 201 Created with target record and job reference for enrollment

# 2. Create a protection policy binding a share to the target
curl -s -X POST http://localhost:9797/v1/policies \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "nightly",
    "share_id": "share-uuid-0001",
    "target_id": "<TARGET_ID>",
    "schedule": "0 2 * * *",
    "retention": {"daily": 7}
  }'
# Expected: 201 Created — backups now run automatically at 02:00 UTC every day

# 3. Request an on-demand backup
curl -s -X POST http://localhost:9797/v1/backups \
  -H 'Content-Type: application/json' \
  -d '{"share_id": "share-uuid-0001", "target_id": "<TARGET_ID>"}'
# Expected: 202 Accepted with a job record; poll the job until status is "available"

Notice that in the Abacá model the tenant supplies their own endpoint, bucket, and Barbican secret references — not an admin-managed destination. The operator never touches the encryption key or the backup data.

• Backup target — Understand how Abacá registers and validates your S3 bucket before it can store backups.
• Protection policy — Learn how to bind a Manila share to a target and configure schedules and retention rules.
• Enrollment — The one-time preflight and repository-initialization process that a target must pass before any backup can run against it.
• Job state machine — Understand the sequence of states (queued → provisioning_network → … → available) that every backup and restore operation moves through.
• Object lock and immutability — Why S3 Object Lock is required and how Abacá enforces it during preflight checks.
• Kopia repository — How your backup data is stored as an encrypted, deduplicated archive in your own S3 bucket, and why the repository (not the database) is the source of truth.
• Worker VM — How short-lived VMs handle data transfer inside your network without persisting secrets to disk.
• FIPS mode — How Abacá meets FIPS 140 compliance requirements for encryption algorithms and worker VM configuration.