> 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/upgrading-to-t4o-6.x-from-older-supported-versions/upgradetrilio/upgrade_on_rhoso18.md). # Upgrading on RHOSO ### Upgrading from 6.1.x to 6.2.x Trilio for OpenStack 6.2.x replaces the per-backup-target object-store containers with the [Dynamic Mount Service (DMS)](/openstack/about-trilio-for-openstack/triliovault-for-openstack-architecture.md#dynamic-mount-service-dms) — a single server container per host. Upgrading from 6.1.x therefore requires more than an image/package bump; the per-BT containers must be removed before the DMS containers are deployed. The high-level flow is: 1. **Tear down the 6.1 per-BT pods/containers first.** Before deploying any 6.2.x image, remove the existing `triliovault-object-store-` pods on the control plane and the matching per-BT backup-target containers on each compute node. They are replaced by a single `trilio-dms-server` per host and must not coexist with it. 2. **Migrate existing backup targets to the 6.2.x schema.** A migration script generates the Barbican secrets for each S3 backup target (using the S3 credentials currently stored in the WLM config), updates each backup target row with the resulting `secret_ref`, and adds the `backup_target_mount_ledger` table on both the `workloadmgr` and `dmapi` schemas. 3. **Deploy the 6.2.x control plane and data plane.** Run the upgrade playbook targeted at the 6.2.x `triliovault-cfg-scripts` branch. It rolls out the 6.2.x control-plane images (wlm, dmapi, horizon-plugin), deploys `trilio-dms-server` on the controller and on every compute node that needs backup-target access, and lays down `/etc/triliovault-dms/{server,client}.conf` plus the rootwrap files. 4. **Verify.** After the upgrade, confirm that: * `trilio-dms-server` pods are running in the `trilio-openstack` namespace, one per controller, and the matching `trilio-dms-server` containers are running on each compute node; * no `triliovault-object-store-` pods or per-BT backup-target containers remain; * each existing backup target lists a non-empty `secret_ref` (for S3) and reaches `online` status; * a fresh snapshot and restore against each backup target succeed end-to-end. Existing backup targets, backup-target types, workloads, snapshots, and policies are preserved across the upgrade; no workload data is migrated. The general upgrade flow (control-plane refresh, data-plane refresh, Horizon plugin update, dynamic backup-target refresh) below remains the same as for 6.1.x upgrades. *** ### 1] Configuration change If any config parameter is changed in `tvo-operator-inputs.yaml`, like DB user password or service endpoints, you can apply the changes using the following command. ``` cd triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts ./deploy_tvo_control_plane.sh ``` Above command will output ‘configured' or 'unchanged’ depending upon changes happened in tvo-operator-inputs.yaml. *** ### 2] Upgrade to New Build Please ensure the following requirements are met before starting the upgrade process: * No Snapshot or Restore is running * Global job scheduler is disabled * T4O should have been upgraded to the 6.1.7 or higher release. Please follow the steps below to upgrade to the new build on the RHOSO18 setup. Take a backup of existing triliovault-cfg-scripts and clone latest triliovault-cfg-scripts github repository. ``` mv triliovault-cfg-scripts triliovault-cfg-scripts-old git clone -b {{ trilio_branch }} https://github.com/trilioData/triliovault-cfg-scripts.git ``` In T4O 6.2.x, pre-mounted backup targets are not required. The T4O core code mounts the backup target when a backup is triggered. Therefore, existing backup targets must be unmounted from the cloud and related pods/containers removed. *** ### Choose Upgrade Path Select the appropriate upgrade path based on your current T4O version. | Current T4O Version | Upgrade Path | | ------------------- | ----------------------------------------------------------------- | | **6.1.7+** | 3] [Upgrade Path 1: Upgrade T4O 6.1.7+ to 6.2.1](#upgrade-path-1) | | **6.2.0** | 4] [Upgrade Path 2: Upgrade T4O 6.2.0 to 6.2.1](#upgrade-path-2) | *** ## 3] Upgrade Path 1: Upgrade T4O 6.1.7+ to 6.2.1 ### 3.1] Collect Existing Backup Targets Before upgrading to T4O 6.2.x, collect all backup target configurations from the current T4O 6.1.7+ installation. This script reads backup targets from the old `tvo-operator-inputs.yaml` and from any dynamic TVOBackupTarget CRs in the `trilio-openstack` namespace, writes a combined inventory YAML file, and verifies that the inventory matches `workloadmgr backup-target-list` exactly (count and names). #### What the script does: * Reads `backup_target` / `backup_targets` section from `tvo-operator-inputs.yaml` (if present) * Reads all TVOBackupTarget CR instances from the `trilio-openstack` namespace * Merges both sources into `existing_list_of_backup_targets.yaml` * Verifies inventory count and names match `workloadmgr backup-target-list` and reports any mismatches #### Prerequisites: * `oc` CLI logged in with cluster-admin (or appropriate RBAC permissions) * `python3` with PyYAML (`pip3 install pyyaml`) * `jq` command ``` # Check if pyyaml module is available python3 -c "import yaml; print('pyyaml: available, version:', yaml.__version__)" 2>/dev/null || echo "pyyaml: NOT available" # If not available, install pip3 install pyyaml # Check if jq command is available which jq &>/dev/null && echo "jq: available, version: $(jq --version), path: $(which jq)" || echo "jq: NOT available" # If not available, install dnf install jq ``` The T4O-6.1.7+ `tvo-operator-inputs.yaml` file used for installation should be present in the old cfg directory. Run the script and provide the T4O 6.1.7+ `tvo-operator-inputs.yaml` file path as an argument: ``` cd triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts/ bash collect_backup_targets.sh -i /path/to/old/tvo-operator-inputs.yaml ``` This produces `existing_list_of_backup_targets.yaml` file. Open the file and verify it contains all backup targets from the current T4O installation, especially S3 credentials: ``` vi existing_list_of_backup_targets.yaml ``` *** ### 3.2] Upgrade T4O to 6.2.1 Operator and Control Plane #### 3.2.1] Follow [step 1.4 of this documentation](/openstack/deployment/installing-on-rhosp/trilio_installation_on_rhoso.md#create-trilio-openstack-secret) #### 3.2.2] Follow [step 2.1 of this documentation](/openstack/deployment/installing-on-rhosp/trilio_installation_on_rhoso.md#install-operator-tvo-operator) #### 3.2.3] Follow [step 2.2 of this documentation](/openstack/deployment/installing-on-rhosp/trilio_installation_on_rhoso.md#edit-operator-inputs) #### 3.2.4] Patch Helm Ownership Metadata Before deploying the control plane, run the following script to add the required Helm ownership metadata to the existing Galera and RabbitMQ resources. In earlier T4O releases, the Galera and RabbitMQ resources were created without the Helm ownership metadata required for the 6.2.1 upgrade. This script updates the existing resources with the required ownership metadata so Helm can manage them during the control plane upgrade. Skipping this step may cause the upgrade to fail. ``` cd triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts/ chmod +x patch_helm_ownership_metadata.sh ./patch_helm_ownership_metadata.sh ``` #### 3.2.5] Run Deploy Command ``` cd triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts/ ./deploy_tvo_control_plane.sh ``` #### 3.2.6] Verify Successful Deployment of T4O Control Plane Services ``` [openstackdev@localhost ctlplane-scripts]$ oc -n trilio-openstack get pods NAME READY STATUS RESTARTS AGE job-triliovault-datamover-api-db-init-gwrpm 0/1 Completed 0 9m51s job-triliovault-datamover-api-keystone-init-fzkw8 0/1 Completed 0 11m job-triliovault-datamover-api-rabbitmq-init-8qhrq 0/1 Completed 0 10m job-triliovault-wlm-cloud-trust-kxj8g 0/1 Completed 0 3h41m job-triliovault-wlm-db-init-pl97t 0/1 Completed 0 9m47s job-triliovault-wlm-keystone-init-7spqh 0/1 Completed 0 10m job-triliovault-wlm-rabbitmq-init-8tf2x 0/1 Completed 0 9m56s trilio-galera-cluster-galera-0 1/1 Running 0 11m trilio-galera-cluster-galera-1 1/1 Running 0 11m trilio-galera-cluster-galera-2 1/1 Running 0 11m trilio-galera-wait-job-swwg9 0/1 Completed 0 11m trilio-rabbitmq-cluster-server-0 1/1 Running 0 12m trilio-rabbitmq-cluster-server-1 1/1 Running 0 12m trilio-rabbitmq-cluster-server-2 1/1 Running 0 12m triliovault-datamover-api-84c56cd576-f5x95 1/1 Running 0 9m36s triliovault-datamover-api-84c56cd576-hdsn4 1/1 Running 0 9m36s triliovault-datamover-api-84c56cd576-hqqg9 1/1 Running 0 9m36s triliovault-dms-bnlr2 1/1 Running 0 9m36s triliovault-dms-hsqz8 1/1 Running 0 9m36s triliovault-dms-tlclz 1/1 Running 0 9m36s triliovault-object-store-bt1-s3-dv2lq 1/1 Running 0 3h41m triliovault-object-store-bt1-s3-hqxfs 1/1 Running 0 3h41m triliovault-object-store-bt1-s3-krszz 1/1 Running 0 3h41m triliovault-object-store-bt2-s3-jtkc6 1/1 Running 0 3h41m triliovault-object-store-bt2-s3-q287h 1/1 Running 0 3h41m triliovault-object-store-bt2-s3-sbg7n 1/1 Running 0 3h41m triliovault-object-store-s3-bt3-7djh4 1/1 Running 0 3h24m triliovault-object-store-s3-bt3-bq4p9 1/1 Running 0 3h24m triliovault-object-store-s3-bt3-jr6b6 1/1 Running 0 3h24m triliovault-object-store-s3-bt4-5drpq 1/1 Running 0 53m triliovault-object-store-s3-bt4-sszpr 1/1 Running 0 53m triliovault-object-store-s3-bt4-ztblr 1/1 Running 0 53m triliovault-wlm-api-6fd6cc99bb-6l4zm 1/1 Running 0 9m36s triliovault-wlm-api-6fd6cc99bb-kdfrb 1/1 Running 0 9m36s triliovault-wlm-api-6fd6cc99bb-xctst 1/1 Running 0 9m36s triliovault-wlm-cron-65f5bbf67f-25t98 1/1 Running 0 9m36s triliovault-wlm-scheduler-759c5848db-fnkcn 1/1 Running 0 9m36s triliovault-wlm-scheduler-759c5848db-mknm8 1/1 Running 0 9m36s triliovault-wlm-scheduler-759c5848db-pnkgs 1/1 Running 0 9m36s triliovault-wlm-workloads-69d5575c7b-5ltk6 1/1 Running 0 9m36s triliovault-wlm-workloads-69d5575c7b-djpx2 1/1 Running 0 9m36s triliovault-wlm-workloads-69d5575c7b-rdghd 1/1 Running 0 9m36s [openstackdev@localhost ctlplane-scripts]$ ``` Expected: All required services should be in `Running` or `Completed` state. > **Note:** The `job-triliovault-wlm-cloud-trust` pod may remain in the Running state during the upgrade. Do not wait for this job to complete before proceeding with the remaining upgrade steps. It will automatically transition to the `Completed` state once the migration script finishes updating the required S3 secret references. *** ### 3.3] Run T4O Backup Target Uninstall and Unmount for Control Plane ``` cd triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts/ chmod +x cleanup_backup_targets_ctlplane.sh ./cleanup_backup_targets_ctlplane.sh ``` #### Verify: 1. No orphaned object store or NFS DaemonSets remain: ``` oc -n trilio-openstack get daemonsets | grep -E "triliovault-object-store|triliovault-nfs-mount" ``` Expected: No output 2. No orphaned object store Kubernetes resources remain: ``` oc -n trilio-openstack get secret triliovault-object-store-etc oc -n trilio-openstack get configmap triliovault-object-store-bin oc -n trilio-openstack get serviceaccount triliovault-object-store ``` Expected: "Not found" error for each command. 3. No hung mounts on control plane nodes (repeat for each node labeled `trilio-control-plane=enabled`): ``` oc debug node/ -- chroot /host findmnt -r | grep triliovault-mounts ``` Expected: No output 4. No stale empty directories under `vault_data_dir` (repeat for each control plane node): ``` oc debug node/ -- chroot /host ls /var/lib/trilio/triliovault-mounts/ ``` Expected: No output. If stale empty directories are present under `/var/lib/trilio/triliovault-mounts/` but no active mount points are listed, they can be safely ignored. 5. Verify T4O control plane pods are in healthy state: ``` [openstackdev@localhost ctlplane-scripts]$ oc -n trilio-openstack get pods NAME READY STATUS RESTARTS AGE job-triliovault-datamover-api-db-init-gwrpm 0/1 Completed 0 16m job-triliovault-datamover-api-keystone-init-fzkw8 0/1 Completed 0 17m job-triliovault-datamover-api-rabbitmq-init-8qhrq 0/1 Completed 0 16m job-triliovault-wlm-cloud-trust-kxj8g 0/1 Completed 0 3h47m job-triliovault-wlm-db-init-pl97t 0/1 Completed 0 16m job-triliovault-wlm-keystone-init-7spqh 0/1 Completed 0 16m job-triliovault-wlm-rabbitmq-init-8tf2x 0/1 Completed 0 16m trilio-galera-cluster-galera-0 1/1 Running 0 18m trilio-galera-cluster-galera-1 1/1 Running 0 18m trilio-galera-cluster-galera-2 1/1 Running 0 18m trilio-galera-wait-job-swwg9 0/1 Completed 0 18m trilio-rabbitmq-cluster-server-0 1/1 Running 0 19m trilio-rabbitmq-cluster-server-1 1/1 Running 0 19m trilio-rabbitmq-cluster-server-2 1/1 Running 0 19m triliovault-datamover-api-84c56cd576-f5x95 1/1 Running 0 15m triliovault-datamover-api-84c56cd576-hdsn4 1/1 Running 0 15m triliovault-datamover-api-84c56cd576-hqqg9 1/1 Running 0 15m triliovault-dms-bnlr2 1/1 Running 0 15m triliovault-dms-hsqz8 1/1 Running 0 15m triliovault-dms-tlclz 1/1 Running 0 15m triliovault-wlm-api-6fd6cc99bb-6l4zm 1/1 Running 0 15m triliovault-wlm-api-6fd6cc99bb-kdfrb 1/1 Running 0 15m triliovault-wlm-api-6fd6cc99bb-xctst 1/1 Running 0 15m triliovault-wlm-cron-65f5bbf67f-25t98 1/1 Running 0 15m triliovault-wlm-scheduler-759c5848db-fnkcn 1/1 Running 0 15m triliovault-wlm-scheduler-759c5848db-mknm8 1/1 Running 0 15m triliovault-wlm-scheduler-759c5848db-pnkgs 1/1 Running 0 15m triliovault-wlm-workloads-69d5575c7b-5ltk6 1/1 Running 0 15m triliovault-wlm-workloads-69d5575c7b-djpx2 1/1 Running 0 15m triliovault-wlm-workloads-69d5575c7b-rdghd 1/1 Running 0 15m [openstackdev@localhost ctlplane-scripts]$ ``` Expected: All required services should be in `Running` or `Completed` state. *** ### 3.4] Upgrade T4O Data Plane to 6.2.1 Release Follow [step 3 to 3.8 of this documentation](/openstack/deployment/installing-on-rhosp/trilio_installation_on_rhoso.md#install-trilio-data-plane-services) *** ### 3.5] Run Backup Target Uninstall and Unmount on Data Plane Nodes This step will unmount backup targets mounted as part of T4O 6.1.7+. It will also remove object store and NFS containers and their config files from compute nodes. * Set the correct list of data plane node set names (you need to run this for all data plane node sets). You can copy these from the data plane deployment templates or get them using the following command: ``` oc -n openstack get OpenStackDataPlaneNodeSet ``` ``` cd triliovault-cfg-scripts/redhat-director-scripts/rhosp18/dataplane-scripts/ vi trilio-backup-target-cleanup-deployment.yaml ``` * Save the changes. Run: ``` oc -n openstack apply -f trilio-backup-target-cleanup-deployment.yaml ``` #### Verify: 1. Check the OpenStackDataPlaneDeployment completed successfully: ``` oc -n openstack get openstackdataplanedeployment edpm-trilio-upgrade-cleanup-1 ``` Expected: Ready = True (Confirms the cleanup job has successfully completed on data plane nodes) 2. Check Ansible runner job logs for success: ``` oc -n openstack logs job/ ``` Expected: failed=0, unreachable=0 (Ensures all tasks executed successfully without errors on any host) 3. No old object store or NFS containers on compute nodes (SSH into a compute node and run): ``` sudo podman ps -a | grep -E "triliovault-object-store|triliovault-nfs-container" ``` Expected: no output (Confirms old backup target containers are removed) 4. No hung mounts on compute nodes (SSH into a compute node and run): ``` sudo findmnt -r | grep triliovault-mounts ``` Expected: no output (Ensures no stale backup target mounts remain) 5. No stale empty directories under vault\_data\_dir (SSH into a compute node and run): ``` ls /var/lib/trilio/triliovault-mounts/ ``` Expected: empty (Verifies cleanup of leftover mount directories) 6. Datamover service is healthy on compute nodes (SSH into a compute node and run): ``` sudo systemctl status edpm_triliovault-datamover.service ``` Expected: active (running confirms datamover service is running properly after cleanup) 7. Verify that only the required Trilio containers are running on the compute node. ``` podman ps -a | grep trilio- ``` Expected: Only `triliovault-datamover` and `triliovault-dms` containers should be listed. *** ### 3.6] Upgrade Trilio Horizon Plugin Follow [step 4 of this documentation](/openstack/deployment/installing-on-rhosp/trilio_installation_on_rhoso.md#id-4-install-trilio-horizon-plugin) and update the Horizon plugin with the new image tag. *** ### 3.7] Update T4O 6.1.7+ Backup Targets to T4O 6.2.1 > **Note:** This step is required only if your deployment includes one or more **S3 backup targets**. If your deployment uses **only NFS backup targets**, you can skip this step. After cleanup is complete, migrate the existing backup targets using the inventory file collected in Step 3 of this documentation. In T4O 6.2.x, S3 credentials are no longer stored in Kubernetes secrets — they are stored in **OpenStack Barbican**. The migration script handles this automatically for each S3 backup target: * Runs `trilio-dms-cli secret-payload create` to build the Barbican secret JSON * Validates the JSON with `trilio-dms-cli secret-payload validate` * Stores the secret in Barbican via `openstack secret store` * Updates the existing backup target in WLM using `workloadmgr backup-target-modify` > **Note:** NFS backup targets are listed but skipped — they do not require a Barbican secret. All operations run inside a temporary migration pod launched from the `trilio-wlm` image. This pod: * Includes `workloadmgr`, `trilio-dms-cli`, and the `openstack` CLI * Mounts the `triliovault-cloudrc` ConfigMap * Injects `OS_PASSWORD` from `openstack-secret` No manual credential setup is required. #### Run the migration: ``` cd triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts/ bash update_backup_targets_62.sh ``` #### Verify: 1. List backup targets via CLI: ``` oc -n trilio-openstack get pods | grep wlm-api oc -n trilio-openstack exec -it bash source workloadmgr backup-target-list ``` Expected: All previously configured backup targets are listed with an `online` status. 2. Verify Barbican secrets were created (one per S3 backup target): ``` openstack secret list | grep secret-key- ``` Expected: One Barbican secret named `secret-key-` per S3 backup target. #### Cleanup: After successful migration, you can remove the temporary inventory file. ``` cd triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts/ rm -f existing_list_of_backup_targets.yaml ``` *** ### 3.8] Install a new Backup Target To add a new backup target, refer to the [Adding a New Backup Target on RHOSO18](/openstack/admin-guide/backup-targets/add-a-backup-target.md). *** ## 4] Upgrade Path 2: Upgrade T4O 6.2.0 to 6.2.1 *** ### 4.1] Upgrade T4O to 6.2.1 Operator and Control Plane #### 4.1.1] Follow [step 2.1 of this documentation](/openstack/deployment/installing-on-rhosp/trilio_installation_on_rhoso.md#install-operator-tvo-operator) #### 4.1.2] Follow [step 2.2 of this documentation](/openstack/deployment/installing-on-rhosp/trilio_installation_on_rhoso.md#edit-operator-inputs) #### 4.1.3] Patch Helm Ownership Metadata Before deploying the control plane, run the following script to add the required Helm ownership metadata to the existing Galera and RabbitMQ resources. In earlier T4O releases, the Galera and RabbitMQ resources were created without the Helm ownership metadata required for the 6.2.1 upgrade. This script updates the existing resources with the required ownership metadata so Helm can manage them during the control plane upgrade. Skipping this step may cause the upgrade to fail. ``` cd triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts/ chmod +x patch_helm_ownership_metadata.sh ./patch_helm_ownership_metadata.sh ``` #### 4.1.4] Run Deploy Command ``` cd triliovault-cfg-scripts/redhat-director-scripts/rhosp18/ctlplane-scripts/ ./deploy_tvo_control_plane.sh ``` #### 4.1.5] Verify successful deployment of T4O control plane services ``` [root@localhost ctlplane-scripts]# oc -n trilio-openstack get pods NAME READY STATUS RESTARTS AGE job-triliovault-datamover-api-db-init-v8n7q 0/1 Completed 0 32m job-triliovault-datamover-api-keystone-init-wn2jl 0/1 Completed 0 33m job-triliovault-datamover-api-rabbitmq-init-btplt 0/1 Completed 0 32m job-triliovault-wlm-cloud-trust-w2rlw 0/1 Completed 0 32m job-triliovault-wlm-db-init-tcz9z 0/1 Completed 0 32m job-triliovault-wlm-keystone-init-fjfhg 0/1 Completed 0 32m job-triliovault-wlm-rabbitmq-init-mprs2 0/1 Completed 0 32m trilio-galera-cluster-galera-0 1/1 Running 0 33m trilio-galera-cluster-galera-1 1/1 Running 0 33m trilio-galera-cluster-galera-2 1/1 Running 0 33m trilio-galera-wait-job-nbsww 0/1 Completed 0 33m trilio-rabbitmq-cluster-server-0 1/1 Running 0 35m trilio-rabbitmq-cluster-server-1 1/1 Running 0 35m trilio-rabbitmq-cluster-server-2 1/1 Running 0 35m triliovault-datamover-api-5989dcb4c5-4b5bs 1/1 Running 0 32m triliovault-datamover-api-5989dcb4c5-5gk6d 1/1 Running 0 32m triliovault-datamover-api-5989dcb4c5-rq8mg 1/1 Running 0 32m triliovault-dms-68hfb 1/1 Running 0 32m triliovault-dms-8j5jg 1/1 Running 0 32m triliovault-dms-w47dp 1/1 Running 0 32m triliovault-wlm-api-5fd4bf65c6-8pvj5 1/1 Running 0 32m triliovault-wlm-api-5fd4bf65c6-9lhmh 1/1 Running 0 32m triliovault-wlm-api-5fd4bf65c6-mn49n 1/1 Running 0 32m triliovault-wlm-cron-7f85f75bb5-9vbdr 1/1 Running 0 32m triliovault-wlm-scheduler-7dc4764b4d-2v2ck 1/1 Running 0 32m triliovault-wlm-scheduler-7dc4764b4d-58wxk 1/1 Running 0 32m triliovault-wlm-scheduler-7dc4764b4d-pxs2r 1/1 Running 0 32m triliovault-wlm-workloads-5946d56cd4-c6cmd 1/1 Running 0 32m triliovault-wlm-workloads-5946d56cd4-cgc8h 1/1 Running 0 32m triliovault-wlm-workloads-5946d56cd4-n74hd 1/1 Running 0 32m [root@localhost ctlplane-scripts]# ``` Expected: All required services should be in `Running` or `Completed` state. *** ### 4.2] Upgrade T4O Data Plane to 6.2.1 Release Follow [steps 3.2 to 3.8 of this documentation](/openstack/deployment/installing-on-rhosp/trilio_installation_on_rhoso.md#install-trilio-data-plane-config) *** ### 4.3] Upgrade Trilio Horizon Plugin Follow [step 4 of this documentation](/openstack/deployment/installing-on-rhosp/trilio_installation_on_rhoso.md#id-4-install-trilio-horizon-plugin) and update the Horizon plugin with the new image tag. *** ### 4.4] Install a new Backup Target To add a new backup target, refer to the [Adding a New Backup Target on RHOSO18](/openstack/admin-guide/backup-targets/add-a-backup-target.md). ***