Intended Audience

This page describes who Trilio Share Protection for OpenStack (Abacá) is designed for and what each audience can expect to do with it. Whether you are a Manila tenant protecting your own file shares or a cloud administrator rolling out backup capabilities across a multi-tenant environment, understanding your role helps you find the right workflows, tools, and documentation sections for your needs.

OpenStack Tenants

If you provision and use Manila shares in an OpenStack environment, Trilio Share Protection gives you self-service backup and recovery of your file data — without depending on your cloud operator to initiate, access, or decrypt your backups.

As a tenant, you interact with Abacá through the REST API (using tools like curl, the python-abacaclient SDK, or openstack share protection … CLI commands) or through the Abacá panels in the Horizon dashboard. Your primary workflows are:

• Register a backup target. You bring your own S3-compatible bucket (AWS S3, MinIO, Ceph RGW, or Wasabi) and store its credentials as secrets in Barbican, your project's key manager. Abacá never holds your credentials directly — it only stores references to them.
• Create a protection policy. You attach a Manila share to a backup target and set a cron schedule and retention rules. Once the policy is active, backups run automatically.
• Run on-demand backups. You can request a backup at any time, outside your scheduled window.
• Restore a share. You can restore a complete share, a sub-path, or a single file to a new share or back to the original.
• Monitor backup jobs. Each backup or restore is tracked as a job you can poll for status, with a clear state progression from queued through to available or error.

A key tenant-facing property: your encryption keys never leave your Barbican secret store. Abacá workers handle keys only in memory during a job and never write sensitive material to disk or logs. Cloud operators cannot read your backup data, and there is no key escrow. Backups stored in your S3 bucket are protected by S3 Object Lock (WORM), so even a compromised credential cannot silently delete backups within the retention window.

OpenStack Cloud Administrators

If you operate an OpenStack cloud and want to offer backup and recovery as a managed service to your tenants, Trilio Share Protection provides the control plane, data plane, and operational tooling you need.

As an administrator, you deploy and maintain the service infrastructure and support tenants in onboarding. Your primary responsibilities are:

• Deploy the control plane. The Abacá API (abaca-api) and conductor (abaca-conductor) run as pods on OpenShift. You manage their configuration, database migrations (via abaca-manage), and upgrades.
• Build and register worker VM images. Short-lived worker VMs handle the actual data transfer inside each tenant's network. You build these RHEL-based images with Kopia baked in and register them in Glance so the conductor can boot them on demand.
• Validate deployments. The abaca-dev CLI lets you probe enrollment, worker provisioning, and the live data path against a real OpenStack environment, producing structured findings reports that confirm fidelity and capability.
• Monitor fleet health and coverage. The admin panels in abaca-dashboard give you a fleet-wide view of worker VMs, job states, and which shares are protected across tenants. Usage meters provide per-tenant metrics suitable for chargeback and billing integration.
• Respond to operational errors. Every failed job carries an error_category field — either tenant_action_required (the tenant must fix a configuration issue, such as a misconfigured bucket) or operator_action_required (the infrastructure or service needs attention). This lets you triage issues quickly without reading tenant backup data.
• Recover from database loss. Because the Kopia repositories in tenant S3 buckets are the authoritative source of truth — not the database — you can rebuild bookkeeping state from repositories after a database loss using abaca-manage.

Abacá is designed so that operators never have access to tenant plaintext data at rest. This is an architectural guarantee, not a configuration option: the confidentiality boundary is enforced by client-side encryption with tenant-held keys, and no administrative bypass exists.

What This Product Is Not

Abacá is not a block-level backup tool. It protects Manila file shares as files, not virtual machine disks or block devices. If you need VM-level protection, that is addressed by a separate product (Trilio for OpenStack). Abacá is also not a replacement for Manila's native backup API — it is a standalone service that complements it, particularly on deployments (such as RHOSO 18) where the native Manila backup paths are not yet available.

The following examples illustrate the difference between a tenant workflow and an administrator workflow. Both assume the service is already deployed and you have a valid Keystone token.

Tenant: register a backup target via the REST API

A tenant registers an S3 bucket they own as a backup destination. Credentials are already stored in Barbican; only the references (barbican_secret_refs) and a delegated Keystone trust (trust_id) are passed to Abacá.

curl -s -X POST https://<abaca-api-host>/v1/targets \
  -H "X-Auth-Token: $OS_TOKEN" \
  -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 response (enrollment job queued):

{
  "target": {
    "id": "<TARGET_ID>",
    "name": "primary",
    "status": "enrolling",
    "job_id": "<JOB_ID>"
  }
}

The enrollment job moves through the job state machine (queued → provisioning_network → … → available). Poll /v1/jobs/<JOB_ID> to follow progress.

Tenant: use the OpenStack CLI (python-abacaclient)

If you prefer the OpenStack CLI, the python-abacaclient plugin exposes the same operations under openstack share protection:

openstack share protection target create \
  --name primary \
  --endpoint https://s3.example.com \
  --bucket tenant-abaca \
  --barbican-secret-ref https://barbican/secrets/pw \
  --trust-id trust-1

Administrator: validate enrollment using abaca-dev

An administrator (or operator) uses abaca-dev enroll to validate the full enrollment path against a real OpenStack environment. S3 credentials are read from environment variables — never passed on the command line.

export OS_CLOUD=abaca-tenant
export ABACA_TARGET_ACCESS_KEY=<s3-access-key>
export ABACA_TARGET_SECRET_KEY=<s3-secret-key>

abaca-dev enroll \
  --target-name demo \
  --endpoint http://<controller>:9000 \
  --bucket abaca-demo-plain \
  --wait

With --wait, the command polls until the enrollment job reaches a terminal state and prints a summary including addressing mode, object-lock status, and Kopia FIPS profile confirmation.

• Backup target — Understand what a backup target is, what preflight checks are run against your S3 bucket, and why object lock must be enabled at bucket creation time.
• Protection policy — Learn how policies bind a share to a target and how cron schedules and retention rules work together.
• Job state machine — See the full sequence of states a backup or restore job passes through, and what each state means.
• Enrollment — Understand the one-time setup process that initializes a Kopia repository in your S3 bucket before backups can run.
• error_category — Learn how to interpret tenant_action_required versus operator_action_required on failed jobs to route issues to the right team.
• Kopia repository — Understand why the repository in your S3 bucket is the authoritative source of truth, and what that means for recovery after database loss.
• Barbican and Keystone trust — Learn how Abacá delegates access to your secrets and Manila resources without storing credentials itself.
• FIPS mode — Understand the FIPS 140 compliance posture for operators running regulated workloads.