What This Service Does

Trilio Share Protection for OpenStack (codename Abacá) is a standalone OpenStack service that backs up and recovers Manila shared file system shares. This page explains the problem Abacá solves, how it fits into the OpenStack ecosystem, and what makes its architecture distinct from both block-level backup tools and Manila's own native backup API. Understanding this context will help you make informed decisions about deployment, target configuration, and integration with your existing OpenStack tenant workflows.

The problem: Manila shares are invisible to infrastructure-level backup

Manila shares are file systems mounted inside a tenant's own network scope. Unlike Nova instance volumes, they are not block devices at the infrastructure layer — a hypervisor-level snapshot tool has no path to their data. Existing block-level backup products, including Trilio for OpenStack VM protection, cannot reach a Manila share's contents. Meanwhile, RHOSO 18 (based on OpenStack 2023.1 Antelope) does not include Manila's native share backup API, which only became available in upstream 2023.2 and later.

Tenants who rely on Manila for mission-critical or regulated workloads therefore have no platform-native, file-granularity backup option on RHOSO 18. Abacá fills this gap as a standalone service with its own Keystone service entry, versioned API, and data plane.

What Abacá does

Abacá takes point-in-time snapshots of Manila shares and streams the data — client-side encrypted and deduplicated — into tenant-owned or operator-managed S3-compatible object storage. The backup engine is Kopia, an open-source tool that produces encrypted, content-addressed, deduplicated repositories. Abacá manages the full lifecycle: scheduling periodic backups from a cron-based protection policy, tracking job state, and exposing restore operations at whole-share, sub-path, or single-file granularity.

From the tenant's perspective, Abacá appears in the OpenStack service catalog as the share-protection service type and is accessible via the openstack share protection CLI subcommands, the REST API at /v1, or the Share Protection panels in Horizon.

How it fits into the OpenStack ecosystem

Abacá is a native OpenStack service in the full sense: it registers with Keystone (service entry, public/internal/admin endpoints, dedicated service account, and roles), enforces access control through oslo.policy, reads configuration through oslo.config, and communicates internally over a dedicated oslo.messaging RabbitMQ broker. It integrates with the following platform services:

• Manila — the source of share metadata and the target of access-rule management during backup and restore.
• Keystone — authentication, authorization, domain-scoped tokens, and Keystone trusts that allow Abacá's service user to act on behalf of a tenant without holding the tenant's password.
• Barbican — the only place where S3 credentials and Kopia repository passwords are ever stored. Abacá's own database holds only Barbican secret hrefs and trust IDs; no secret material is ever written to Abacá's database or transmitted over the message bus.
• Nova and Neutron — used to boot and network stateless worker VMs in the Domain's service project.
• Glance — stores the pre-baked worker VM image (identified by the abaca_worker_image=1 property) that contains Kopia, NFS utilities, and the worker agent.

Architecture in one mental model

Abacá is split across two distinct layers:

Control plane — The abaca-api and abaca-conductor services run as pods in the abaca namespace on OpenShift, alongside the RHOSO control plane. The API accepts tenant and operator requests; the conductor drives the job state machine, schedules policy-based backups, manages the worker VM fleet, and runs reconciliation sweeps to recover from failures. A dedicated MySQL/MariaDB database holds bookkeeping metadata only — targets, policies, jobs, worker fleet state. The actual backup data never touches this database.

Data plane — Stateless worker VMs run inside the tenant's own network scope, which is the only place from which a Manila share's export is reachable. Each worker VM is booted from the pre-baked Glance image, mounts the Manila share using the appropriate network and snapshot access strategy, fetches credentials from Barbican into memory, runs Kopia to transfer data to the S3 bucket, and is torn down or returned to the pool when the job completes. Workers contact the conductor over outbound HTTPS to claim leased commands; they never initiate inbound connections and do not touch the RabbitMQ broker.

This split is deliberate: the control plane needs no access to tenant networks or share data, while the data plane needs no persistent state — the Kopia repositories in S3 are the durable source of truth, and the Abacá database can be reconstructed from them using the abaca-manage rebuild-from-repository disaster-recovery operation.

The encryption and ownership model

Every Kopia repository is initialized with a unique encryption key that is stored in Barbican under the tenant's own project, wrapped in a Keystone trust the tenant can revoke at any time. Abacá's service user never sees the plaintext key — it reads the Barbican secret href from its database, presents the trust to Barbican, and passes the resolved secret to Kopia via environment variable or stdin, never via disk or logs. Cloud operators have no path to plaintext backup data at rest.

When S3 Object Lock is enabled on the target bucket, backup objects become immutable for the configured retention period. A compromised tenant credential cannot silently delete or overwrite backups within that window, providing a protection layer beyond what access control alone can offer.

What makes Abacá different from Manila's native backup API

The table below summarizes the key distinctions for operators evaluating whether Abacá, Manila's native backup capability (where available), or both are appropriate for a given deployment.

This differentiation is architectural and persists after RHOSO 19. When Manila's native backup API becomes available in a future RHOSO release, Abacá and the native API are complementary rather than redundant: vendor replication for fast operational recovery, Abacá for tenant-owned, off-array, storage-independent protection with FIPS-grade encryption.

Scope and phasing

Abacá's initial release targets NFS shares with NetApp ONTAP as the production backend and Linux NFS (LVM/generic drivers) as the reference implementation. CIFS support and formal coexistence with Manila's native backup API are planned for a subsequent phase. The service is designed so that environmental preconditions — share capabilities, S3 bucket configuration, network reachability, root-squash behavior — are verified at runtime rather than assumed, and failures surface as actionable errors classified as either tenant_action_required or operator_action_required.

The following example shows how Abacá appears in the OpenStack service catalog after deployment, confirming it is registered as a first-class OpenStack service.

Verify the Abacá service catalog entry

openstack catalog show share-protection

Expected output (endpoint URLs reflect your deployment):

+-----------+-------------------------------------------------------------------+
| Field     | Value                                                             |
+-----------+-------------------------------------------------------------------+
| endpoints | RegionOne                                                         |
|           |   publicURL: https://abaca.example.com/v1                        |
|           |   internalURL: http://abaca-api.abaca.svc.cluster.local:9797/v1  |
|           |   adminURL: http://abaca-api.abaca.svc.cluster.local:9797/v1     |
| name      | abaca                                                             |
| type      | share-protection                                                  |
+-----------+-------------------------------------------------------------------+

List available backup targets using the CLI plugin

Once the python-abacaclient package is installed and your clouds.yaml or environment variables are configured, you can interact with Abacá through the standard OpenStack CLI:

openstack share protection target list

Expected output when no targets are registered yet:

+----+------+--------+--------+
| ID | Name | Status | Scheme |
+----+------+--------+--------+
+----+------+--------+--------+

Check job state after requesting an on-demand backup

After submitting a backup request, you can track its progress through the job state machine (queued → provisioning_network → provisioning_source → connecting_repository → transferring → finalizing → releasing → available or error):

openstack share protection job show <JOB_ID>

Expected output for a completed backup:

+----------------+--------------------------------------+
| Field          | Value                                |
+----------------+--------------------------------------+
| id             | a1b2c3d4-e5f6-7890-abcd-ef1234567890 |
| type           | backup                               |
| status         | available                            |
| share_id       | share-uuid-0001                      |
| target_id      | target-uuid-0001                     |
| created_at     | 2025-01-15T02:01:43Z                 |
| updated_at     | 2025-01-15T02:07:12Z                 |
| error_category | None                                 |
+----------------+--------------------------------------+

If the job reaches error state, the error_category field will be either tenant_action_required (for example, invalid S3 credentials) or operator_action_required (for example, no worker fleet available), so you know immediately where to direct the resolution effort.

• BackupTarget and BackupTargetTemplate — How S3 buckets are registered, validated, and organized into Domain-level templates before a protection policy can reference them.
• Protection policy — How a Manila share is bound to a backup target template, a backup schedule (cron expression), and retention rules.
• Job state machine — The sequence of lifecycle states (queued through available or error) that every backup, restore, and enrollment job passes through, and how the conductor recovers from failures at each stage.
• Worker VM image — How the pre-baked RHEL image containing Kopia, NFS utilities, and the worker agent is built and registered in Glance, and why workers must not fetch packages from the internet at boot.
• Enrollment and preflight conformance checks — The automated checks Abacá runs before accepting an S3 bucket as a backup target, including reachability, versioning, object-lock configuration, and lifecycle rule validation.
• FIPS crypto profile — How Kopia repositories are initialized with FIPS-approved cryptographic algorithms at enrollment time, and why this choice is immutable for the lifetime of a repository.
• Rebuild from repository — The disaster-recovery operation that reconstructs the Abacá database catalog from Kopia repositories in S3 when the database is lost but backup data is intact.
• Domain owner role and domain_service_projects — How Keystone Domains map to dedicated service projects where worker VMs, S3 buckets, and Barbican secrets physically reside, and what the abaca_domain_owner role authorizes.