> For the complete documentation index, see [llms.txt](https://docs.trilio.io/openstack/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trilio.io/openstack/admin-guide/backup-targets/add-a-backup-target.md).

# Add a backup target

Follow the steps below to add a new backup target.

{% hint style="info" %}
**6.2 changes the dynamic backup-target flow.** Trilio for OpenStack 6.2 deploys a single [Dynamic Mount Service](/openstack/about-trilio-for-openstack/triliovault-for-openstack-architecture.md#dynamic-mount-service-dms) server per host (one on the controller, one on each compute node) and removes the per-backup-target `triliovault-object-store-<bt-name>` pods used in 6.1. As a result, adding a new backup target in 6.2 no longer requires a per-BT control-plane CR or a per-BT data-plane container deployment — only the Trilio DB record needs to be created (with a Barbican `secret_ref` for S3 targets), and DMS handles mount/unmount on demand.
{% endhint %}

## 1] Create the Trilio DB record for the new backup target

Identify the Trilio WLM API container or unit and connect to it. All commands below run in that shell.

### RHOSO18

```
oc get pods -n trilio-openstack | grep wlm-api
oc exec -n trilio-openstack -it <trilio-wlm-api-pod-name> bash
source <admin rc file>
```

### Kolla

```
docker exec -it triliovault_wlm_api bash
source <admin rc file>
```

### Canonical

```
juju ssh trilio-wlm/leader
source <openrc file>
```

{% hint style="info" %}
NFS options : `nolock,soft,timeo=600,intr,lookupcache=none,nfsvers=3,retrans=10`
{% endhint %}

### Helm and MOSK

```
# Get the name of the WLM API Pod
WLM_POD=$(kubectl get pods -n trilio-openstack -l component=wlm-api -o jsonpath="{.items[0].metadata.name}")
# Execute into the pod
kubectl exec -it -n trilio-openstack $WLM_POD -- bash
source <admin rc file>
```

### 1.1] NFS backup target

For NFS, no Barbican secret is required. Create the backup target record directly:

```
workloadmgr backup-target-create --type nfs --filesystem-export <filesystem_export> --nfs-mount-opts <nfs_mount_opts> --btt-name <btt-name>
```

Sample command:

```
workloadmgr backup-target-create --type nfs --filesystem-export 192.168.0.53:/home/rhosp2 --nfs-mount-opts nolock,soft,timeo=600,intr,lookupcache=none,nfsvers=3,retrans=10 --btt-name bt3-nfs
```

### 1.2] S3 backup target

In 6.2, S3 credentials are stored in an OpenStack Barbican secret and the backup target record holds a `secret_ref` URL pointing at that secret. Both `trilio-dms-cli` and the `openstack` CLI are available inside the WLM API pod, so all of the following commands run there.

**Step 1.2.1 — Build the secret payload using `trilio-dms-cli secret-payload create`.**

The exact flags depend on the S3 endpoint. Two key rules apply across all examples below:

* `--endpoint-url` is **optional** for AWS S3 (leave it unset to use the default AWS endpoint) and **required** for any non-AWS S3-compatible endpoint (Ceph RGW, MinIO, Wasabi, etc.).
* `--filesystem-export` takes a different form per target type:
  * **AWS S3** — `<bucket_name>` only (e.g. `my-bucket`).
  * **Other S3** — `<s3_domain_name>/<bucket_name>` (e.g. `s3.example.com/my-bucket`).
  * **NFS** — `<nfs_server_ip>:<export_path>` (e.g. `192.168.0.53:/home/rhosp2`).

The five common S3 cases:

```
# AWS S3 (no --endpoint-url; --filesystem-export is the bucket name only)
trilio-dms-cli secret-payload create \
    --access-key <access_key> \
    --secret-key <secret_key> \
    --bucket <bucket> \
    --ssl --ssl-verify \
    --filesystem-export <bucket> \
    -o /tmp/secret-<btt-name>.json

# S3-compatible endpoint with publicly-trusted CA
trilio-dms-cli secret-payload create \
    --access-key <access_key> \
    --secret-key <secret_key> \
    --bucket <bucket> \
    --endpoint-url https://s3.example.com \
    --ssl --ssl-verify \
    --filesystem-export s3.example.com/<bucket> \
    -o /tmp/secret-<btt-name>.json

# S3 with self-signed CA cert
trilio-dms-cli secret-payload create \
    --access-key <access_key> \
    --secret-key <secret_key> \
    --bucket <bucket> \
    --endpoint-url https://s3.internal.example.com \
    --ssl --ssl-verify --ssl-cert /path/to/ca-cert.pem \
    --filesystem-export s3.internal.example.com/<bucket> \
    -o /tmp/secret-<btt-name>.json

# S3 with SSL verification disabled
trilio-dms-cli secret-payload create \
    --access-key <access_key> \
    --secret-key <secret_key> \
    --bucket <bucket> \
    --endpoint-url https://s3.internal.example.com \
    --ssl --no-ssl-verify \
    --filesystem-export s3.internal.example.com/<bucket> \
    -o /tmp/secret-<btt-name>.json

# S3 with SSL verification disabled and object lock enabled bucket
trilio-dms-cli secret-payload create \
    --access-key <access_key> \
    --secret-key <secret_key> \
    --bucket <bucket> \
    --endpoint-url https://s3.internal.example.com \
    --ssl \
    --filesystem-export s3.internal.example.com/<bucket> \
    --object-lock --manifest-suffix \
    -o /tmp/secret-<btt-name>.json

```

Validate the payload before storing it in Barbican:

```
trilio-dms-cli secret-payload validate /tmp/secret-<btt-name>.json
```

**Step 1.2.2 — Store the payload in Barbican.**

```
openstack secret store \
    --name secret-key-<btt-name> \
    --payload "$(cat /tmp/secret-<btt-name>.json)" \
    -f json
```

Capture the value of `Secret href` from the output — that URL is the `secret_ref` you pass to `workloadmgr` in the next step.

{% hint style="info" %}
**Cloud admin must have read access to the secret payload.** The DMS server fetches the secret at mount time using the requesting job's Keystone token. The cloud admin user (or whichever role is configured to run backup jobs) must have `secret:get` permission on the Barbican secret you just stored.
{% endhint %}

**Step 1.2.3 — Create the backup target record.**

For a non-object-locked S3 backup target:

```
workloadmgr backup-target-create \
    --type s3 \
    --secret-ref <Secret href from Barbican> \
    --s3-bucket <bucket>
    --btt-name <btt-name>
```

For an object-lock-enabled S3 backup target:

```
workloadmgr backup-target-create \
    --type s3 \
    --secret-ref <Secret href from Barbican> \
    --btt-name <btt-name> \
    --s3-bucket <bucket>
    --immutable --metadata object_lock=1
```

Sample (object-locked):

```
workloadmgr backup-target-create \
    --type s3 \
    --secret-ref https://barbican.example.com/v1/secrets/abcd1234-... \
    --btt-name s3-bt8 \
    --s3-bucket s3-object-lock
    --immutable --metadata object_lock=1
```

## 2] Verify

The backup target should now appear in the output of the following command:

```
workloadmgr backup-target-list
```

No additional control-plane or data-plane deployment is required. The DMS server pods deployed during the initial 6.2 install (one `triliovault-dms-*` on each controller and one `triliovault-dms` on each compute node) handle the new target automatically. You can spot-check that they are running:

### RHOSO18

```
oc -n trilio-openstack get pods | grep triliovault-dms
```

### Kolla

```
docker ps | grep triliovault_dms
```

### Canonical

```
juju ssh trilio-wlm/leader "systemctl is-active trilio-dms-server"
juju ssh nova-compute/0 "systemctl is-active trilio-dms-server"
```

### Helm and MOSK

```
kubectl get pods -n trilio-openstack | grep triliovault-dms
```

The first time a snapshot or restore runs against the new backup target, DMS will mount it on the relevant node on demand and unmount it when the last job finishes.

***

<details>

<summary>Deprecated (6.1) — adding a backup target with per-BT secret + per-BT object-store containers</summary>

In Trilio for OpenStack 6.1 and earlier, adding a dynamic backup target required deploying a per-BT object-store container on the control plane and on every compute node. The flow below is preserved for reference; **do not use it on 6.2 or later**.

### 1] Mount Backup target on Trilio Control Plane

Navigate to the trilio ctlplane-scripts directory:

```
cd /PATH/TO/triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts
```

T4O 6.1 supported two types of backup targets — `nfs` and `s3`.

For NFS:

```
vi tvo-backup-target-cr-nfs.yaml
oc -n trilio-openstack apply -f tvo-backup-target-cr-nfs.yaml
```

For S3, copy the secret template and base64-encode the access/secret keys:

```
cd /PATH/TO/triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts
cp trilio-s3-backup-target-secret.yaml trilio-s3-backup-target-secret-<BACKUP_TARGET_NAME>.yaml

echo -n "s3_key_string" | base64
```

Edit the copied file:

```
vi trilio-s3-backup-target-secret-<BACKUP_TARGET_NAME>.yaml
```

Set:

```
<BACKUP_TARGET_NAME>_s3_access_key: <base64_encoded_access_key>
<BACKUP_TARGET_NAME>_s3_secret_key: <base64_encoded_secret_key>
```

Apply:

```
oc -n trilio-openstack apply -f trilio-s3-backup-target-secret-<BACKUP_TARGET_NAME>.yaml
```

Apply the appropriate `tvo-backup-target-cr-*.yaml` for AWS S3 or other S3:

```
vi tvo-backup-target-cr-amazon-s3.yaml
oc -n trilio-openstack apply -f tvo-backup-target-cr-amazon-s3.yaml
# or
vi tvo-backup-target-cr-other-s3.yaml
oc -n trilio-openstack apply -f tvo-backup-target-cr-other-s3.yaml
```

A per-BT pod named `triliovault-object-store-<bt-name>-*` would then appear in the `trilio-openstack` namespace.

### 2] Mount Backup target on Trilio Data Plane

```
cd /PATH/TO/triliovault-cfg-scripts/redhat-director-scripts/rhosp18/dataplane-scripts/
./create-templates.sh <BACKUP_TARGET_NAME> <BACKUP_TARGET_TYPE>
cd <BACKUP_TARGET_NAME>/

vi cm-trilio-backup-target.yaml
oc -n openstack apply -f cm-trilio-backup-target.yaml

oc -n openstack apply -f ../../ctlplane-scripts/trilio-s3-backup-target-secret-<BACKUP_TARGET_NAME>.yaml

vi trilio-add-backup-target-service.yaml
oc -n openstack apply -f trilio-add-backup-target-service.yaml

oc -n openstack get OpenStackDataPlaneNodeSet
vi trilio-add-backup-target-deployment.yaml
oc -n openstack apply -f trilio-add-backup-target-deployment.yaml
```

This produced a per-BT `edpm_triliovault-object-store-<BT_NAME>.service` on every compute node.

### 3] Add Backup Target Records

In 6.1 the WLM record was created with inline S3 endpoint + bucket (no `secret_ref`):

```
workloadmgr backup-target-create --type s3 --s3-endpoint-url <s3_endpoint_url> --s3-bucket <s3_bucket> --btt-name <btt-name>
```

***

In 6.2 the per-BT secret YAML, the `tvo-backup-target-cr-*.yaml` CRs, the `create-templates.sh` step, and the `trilio-add-backup-target-{service,deployment}.yaml` data-plane resources are all replaced by the Barbican `secret_ref` flow documented above.

</details>