1 of 86

T4O-6.x

About Trilio for OpenStack

Welcome to Trilio for OpenStack

Trilio Data, Inc

Trilio Data, Inc. is the leader in providing backup and recovery solutions for cloud-native applications. Established in 2013, its flagship products, Trilio for OpenStack(T4O) and Trilio for Kubernetes(T4K) are used by a wide number of large corporations around the world.

About Trilio for OpenStack

T4O, by Trilio Data, is a native OpenStack service-based solution that provides policy-based comprehensive backup and recovery for OpenStack workloads. It captures point-in-time workloads (Application, OS, Compute, Network, Configurations, Data, and Metadata of an environment) as full or incremental snapshots. These snapshots can be held in a variety of storage environments including NFS, AWS S3, and other S3-compatible storages. With Trilio and its one-click recovery, organizations can improve Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). With Trilio, IT departments are enabled to fully deploy OpenStack solutions and provide business assurance through enhanced data retention, protection, and integrity.

With the use of Trilio’s VAST (Virtual Snapshot Technology), Enterprise IT and Cloud Service Providers can now deploy backup and disaster recovery as a service to prevent data loss or data corruption through point-in-time snapshots and seamless one-click recovery. Trilio takes point-in-time backup of the entire workload consisting of compute resources, network configurations, and storage data as one unit. It also takes incremental backups that capture only the changes that were made since the last backup. Incremental snapshots save a considerable amount of storage space as the backup only includes changes since the last backup. The benefits of using VAST for backup and restore could be summarized below:

Efficient Capture and Storage of Snapshots

Since our full backups only include data that is committed to storage volume and the incremental backups only include changed blocks of data since the last backup, our backup processes are efficient and store backup images efficiently on the backup media.

Faster and Reliable Recovery

When your applications become complex that snap multiple VMs and storage volumes, our efficient recovery process will bring your application from zero to operational with just a click of a button

Easy Migration of Workloads between Clouds

Trilio captures all the details of your application and hence our migration includes your entire application stack without leaving anything for guesswork.

Low Total Cost of Ownership

Our tenant-driven backup policy and automation eliminate the need for dedicated backup administrators, thereby improving your total cost of ownership.

About this Documentation

This documentation serves as the end-user technical resource to accompany Trilio for OpenStack. You will learn about the architecture, installation, and vast number of operations of this product. The intended audience is anyone who wants to understand the value, operations, and nuances of protecting their cloud-native applications with Trilio for OpenStack.

T4O Architecture

A quick overview on the Architecture of T4O

Backup-as-a-Service

Trilio is an add-on service to OpenStack cloud infrastructure and provides backup and disaster recovery solutions for tenant workloads. Trilio is very similar to other OpenStack services including Nova, Cinder, Glance, etc., and adheres to all tenets of OpenStack. It is a stateless service that scales with your cloud.

Main Components

Trilio has three main software components which are again segregated into multiple services.

WorkloadManager

This component is registered as a keystone service of type workloads which manages all the workloads being created for utilizing the snapshot and restore functionalities. It has 4 services responsible for managing these workloads, their snapshots, and restores.

workloadmgr-api
workloadmgr-scheduler
workloadmgr-workloads

DataMover

Similar to WorkloadManager, this component registers a keystone service of the type datamover which manages the transfer of extensive data to/from the backup targets. It has 2 services that are responsible for taking care of the data transfer and communication with WorkloadManager

datamover-api
datamover

Horizon Dashboard Plugin

For ease of access and better user experience, T4O provides an integrated UI with the OpenStack dashboard service Horizon,

Trilio API is a Python module that is installed on all OpenStack controller nodes where the nova-api service is running.
Trilio Datamover is a Python module that is installed on every OpenStack compute nodes
Trilio Horizon plugin is installed as an add-on to Horizon servers. This module is installed on every server that runs Horizon service.

Service Endpoints

Trilio is both a provider and consumer in the OpenStack ecosystem. It uses other OpenStack services such as Nova, Cinder, Glance, Neutron, and Keystone and provides its own services to OpenStack tenants. To accommodate all possible OpenStack deployments, Trilio can be configured to use either public or internal URLs of services. Likewise, Trilio provides its own public, internal, and admin URLs for two of its services WorkloadManager API and Datamover API.

Network Topology

Unlike the previous versions of Trilio for OpenStack, now it utilizes the existing network of the OpenStack deployed environment. The networks for the Trilio services can be configured as per the user's desire in the same way the user configures any other OpenStack service. Additionally, a dedicated network can be provided to Trilio services on both control and compute planes for storing and retrieving backup data from the backup target store.

Release Notes

6.1.7

Release Date : 10th Feb'2026

Features

A list of impactful features in Trilio for OpenStack.

Immutable Backups

Release version: 6.0

Trilio offers the capability to create immutable T4O backups/snapshots, ensuring they cannot be deleted until the specified retention period has ended. It leverages the target's locking and versioning features to achieve this immutability.

Purpose

In recent years, the Trilio S3 Fuse plugin introduced the ability to support backup immutability through the S3 object lock mechanism. This feature ensures that backups remain secure even if the OpenStack platform is compromised, acting as a crucial safeguard against cyber attacks. While traditional backup solutions prevent direct exposure of backup media to the platform, Trilio's scale-out architecture necessitates direct attachment of the

Key Highlights

Pre-requisites:
- Create a new S3 bucket to enable the object-locking feature, as it cannot be enabled on existing buckets.
- Configure Object Locking in Compliance mode with a retention period of at least one day for enhanced protection.

How To Use It

Follow the steps mentioned to know how to use this feature in the product.

Configuration

To enable this feature, you need to adjust certain configuration settings in the product. Refer to the deployment guides of the desired distribution for detailed instructions.

Limitations

The feature may not work as expected if the object lifecycle policy is set for a backup target.
The same backup target cannot be used for DR or migration purposes, additional steps will be required to perform it.

Advanced Scheduler & Retention

Release version: 6.0

The Advanced Scheduler is a newly introduced feature in Trilio that provides enhanced flexibility and granularity in scheduling and retaining snapshots. With this feature, users can now schedule both full and incremental snapshots across various intervals—hourly, daily, weekly, monthly, and yearly. Each scheduling type offers customizable retention policies, allowing users to manage snapshots as per their specific requirements effectively.

Purpose

The purpose of the Advanced Scheduler is to empower users with more control over their snapshot management. By addressing limitations in the previous scheduler, this feature ensures improved efficiency, optimized resource usage, and greater alignment with organizational backup policies. This feature is especially beneficial for organizations with diverse workloads that demand varying backup frequencies and retention policies.

Key Highlights

Flexible Scheduling Intervals: Users can now schedule snapshots across the following intervals:
- Hourly: For tasks requiring frequent backups.
- Daily: Ideal for daily operations requiring end-of-day snapshots.

How To Use It

Follow the steps mentioned to know how to use this feature in the product.

Limitations

While the Advanced Scheduler introduces significant improvements, it has certain limitations:

Immutable Backups:
- In case the user chooses the immutable backup storage, the scheduling policy will get limited options. The user can have only hourly scheduling and retention types and hourly will have only 24hrs interval option.
Resource Utilization:

Multiple Backup Targets

Release version: 6.0

Previously, Trilio allowed a single backup target per cloud, either NFS or S3, for all backups. Now, Trilio supports multiple backup targets, enabling both NFS and S3 types to coexist as backup options. Admin users can configure multiple backup targets and define their accessibility for tenant users. Additionally, admin users have the ability to restrict backup targets to specific projects for enhanced control.

Purpose

The feature aims to enhance the flexibility, scalability, and manageability of backup configurations in Trilio. By supporting multiple backup targets:

Organizations can align their backup strategies with diverse operational requirements.
Admin users can provide tenant users with more options for workload backups.
Access control over backup targets is improved, allowing organizations to secure sensitive data.

Key Highlights

Support for Multiple Backup Targets: Trilio now supports both NFS and S3 simultaneously for backup storage.
Admin Configuration: Admin users can configure multiple backup targets during deployment.
Tenant User Flexibility: Tenant users can choose from available backup targets when creating workloads.

How To Use It

Follow the steps mentioned to know how to use this feature in the product.

Configuration

To take advantage of this feature, you need to adjust certain configuration settings in the product. Refer to the deployment guides of the desired distribution for detailed instructions.

Limitations

Backup Targets are configured during deployment. Modifying them may require redeploying Trilio.
While this feature is highly expandable, it currently limits the isolation of the backup targets to the projects only.

Compatibility Matrix

Trilio for OpenStack Compatibility Matrix

Trilio Release

RHOSP version

Linux Distribution

Supported ?

Resources

Each T4O release includes a set of artifacts such as version-tagged containers, package repositories, and distribution packages.

To help users quickly identify the resources associated with each release, we have added dedicated sub-pages corresponding to a specific release version.

6.1.7 6.1.6 6.1.5 6.1.4 6.1.3 6.1.2 6.1.1 6.1.0 6.0.0

Getting Started

Requirements

Cloud-Native and Containerized

T4O represents a comprehensively containerized deployment model, eliminating the necessity for any KVM-based appliances for service deployment. This marks a departure from earlier T4O releases, where such appliances were required.

Summary of Requirements

Trilio requires its containers to be deployed on the same plane as OpenStack, utilizing existing cluster resources.

As described in the , Trilio requires sufficient cluster resources to deploy its components on both the Controller Plane and Compute Planes.

Valid Trilio License & Acceptance of the
When deploying the Control Plane to OpenShift, ensure sufficient resources are available on Worker Nodes.
Sufficient storage capacity and connectivity on Cinder for snapshotting operations

Network Considerations

Trilio seamlessly integrates with OpenStack, functioning exclusively through APIs utilizing the OpenStack Endpoints. Furthermore, Trilio establishes its own set of OpenStack endpoints. Additionally, both the Trilio appliance and compute nodes interact with the backup target, impacting the network strategy for a Trilio installation.

Existing endpoints in OpenStack

OpenStack comprises three endpoint groupings:

Installation Strategy and Preparation

Before embarking on the installation process for Trilio in your OpenStack environment, it is highly advisable to carefully consider several key elements. These considerations will not only streamline the installation procedure but also ensure the optimal setup and functionality of Trilio's solutions within your OpenStack infrastructure.

Tenant Quotas

Trilio leverages Cinder snapshots to facilitate the computation of both full and incremental backups.

When executing full backups, Trilio orchestrates the generation of Cinder snapshots for all volumes included in the backup job. These Cinder snapshots remain intact for subsequent incremental backup image calculations.

Getting started with Trilio on Red-Hat OpenStack Platform

Trilio Installation on RHOSP Trilio Installation on RHOSO

Licensing

After all Trilio components are installed, the license can be applied.

The license can be applied either through the Admin tab in Horizon or the CLI

Apply license through Horizon

To apply for the license through Horizon follow these steps:

Login to Horizon using admin user.
Click on the Admin Tab.
Navigate to Backups-Admin
Navigate to Trilio
Navigate to License
Click "Update License"
Read the license agreement
Click on "I accept the terms in the License Agreement"
Click on "Next"
Click "Choose File"
Choose license file on the client system
Click "Apply"

Apply license through CLI

<license_file> ➡️ path to the license file

Read and accept the End User License Agreement to complete the license application.

Users can preview the latest EULA at our main site:

Installing WorkloadManager CLI client

About the workloadmgr CLI client

The workloadmgr CLI client is provided as rpm and deb packages.

The following operating systems have been verified with the installation:

Uninstall Trilio

The high-level process is the same for all Distributions.

Uninstall the Horizon Plugin or the Trilio Horizon container
Uninstall the datamover-api container
Uninstall the datamover container
Uninstall the workloadmgr container

Uninstalling from OpenStack Helm/MOSK

1] Uninstall trilio-openstack helm chart

Run following commands to uninstall trilio services from MOSK cloud.

2] Uninstall Dynamic Backup Targets (Optional)

If you have installed multiple backup targets other than the default one, you can uninstall them using:

3] Verify uninstallation

Verify if the trilio-openstack chart and other components got uninstalled. No objects should be listed in following command output:

4] Clean TrilioVault’s OpenStack resources

5] Unmount the targets from All Worker and Master Nodes

To unmount the backup target mount points from each node, run:

Repeat this on each worker and master node where the target was mounted.

Upgrading to T4O-6.x from older supported versions

Supported Trilio Upgrade Path

The following versions can be upgraded to each other:

From

Upgrade Trilio

Upgrading on RHOSP Upgrading on RHOSO Upgrading on OpenStack-Helm/MOSK

Upgrading on RHOSP

1] Prerequisites

Please ensure the following requirements are met before starting the upgrade process:

No Snapshot or Restore is running
Global job scheduler is disabled
Disable the wlm services on all controller nodes

Disable the datamover service on all compute nodes

2] Install latest Trilio release

Take a backup of existing triliovault-cfg-scripts directory

Clone triliovault-cfg-scripts github repository of latest release.

Copy the passwords and triliovault wlm ids files from old cfg-scripts directory.

Please follow from section 1.4 to section 10. Please note that sections 5 and 6 needs to be skipped during this process.

While providing the backup target details in section 4.1, please ensure to provide the existing backup target (of 5.x release) as default.

3] Restart wlm-cron resource

From any one of the controller nodes, run the below command.

4] Fetch backup target details

From any one of the controller nodes, login to wlm api container and run the below commands to fetch the backup target details.

This command will return the backup_target_id and backup_target_type_id.

5] Import workloads

To import workloads after upgrade, run the following command from any controller node by logging into the WLM API container:

Above --inplace-upgrade will update all the workload and policy records in database as per the current release version.

The above command gives you the list of all the workloads that can be imported from the specified backup target.

The above command imports all workloads from the specified backup target in the current cloud.

6] Update backing file path

This step would be needed only when your old backup target is S3.

Please follow to update the backing file path of existing snapshots.

Advanced Configuration

Switching NFS Backing file

Trilio employs a base64 hash to establish the mount point for NFS Backup targets, ensuring compatibility across multiple NFS Shares within a single Trilio installation. This hash is an integral component of Trilio's incremental backups, functioning as an absolute path for backing files.

Consequently, during a disaster recovery or rapid migration situation, the utilization of a mount bind becomes necessary.

In scenarios that allow for a comprehensive migration period, an alternative approach comes into play. This involves modifying the backing file, thereby enabling the accessibility of Trilio backups from a different NFS Share. The backing file is updated to correspond with the mount point of the new NFS Share.

Multi-IP NFS Backup target mapping file configuration

Introduction

Filename and location:

This file exclusively comes into play when users aim to configure Trilio with a NFS backup target that employs multiple network endpoints. For all other scenarios, such as single IP NFS or S3, this file remains inactive, and in such instances, please consult the standard installation documentation.

When using an NFS backup target with multiple network endpoints, T4O will mount a single IP/endpoint on a designated compute node for a specific NFS share. This approach enables users to distribute NFS share IPs/endpoints across various compute nodes.

Advanced Ceph configurations

Ceph is the most common OpenSource solution to provide block storage through OpenStack Cinder.

Ceph is a very flexible solution. The possibilities of Ceph require additional steps to the Trilio solution.

Additions for multiple CEPH configurations

It is possible to configure Cinder and Ceph to use different Ceph users for different Ceph pools and Cinder volume types. Or to have the nova boot volumes and cinder block volumes controlled by different users.

If multiple Ceph storages are configured/integrated with the OpenStack, please ensure that respective conf and keyring files are present in /etc/ceph directory.

In the case of multiple Ceph users, it is required to delete the keyring extension from the triliovault-datamover.conf inside the Ceph block by following below mentioned steps:

Serial Upload per Instance during Snapshot

The following steps depict configuring the Trilio for OpenStack to override the default snapshot upload functionality.

By default, during a snapshot, Trilio will consider all the instances that are members of a workload and starts uploading the resources of each instance simulateously. In some cases, it may be required that the snapshots must be done in serial per VM such that backup of all the disks of one VM/instance must be finished before taking backup of the other VMs that are part of that workload.

Trilio has a provision to update the default behaviour of considering all the instances of a workload during backup process, by introducing a configrable parameter in the on of its services.

Follow the below mentioned steps to set the serial upload as the default behavior.

Finding the required configuration file

As per the OpenStack distribution, look for the configuration file of workloadmgr-api(wlm-api) and workloadmgr-workloads(wlm-workloads) services or containers on the controller plane.

The default location of this configration file in the container or VM where it is running is /etc/triliovault/triliovault-wlm.conf

Once the file is located, take a backup of the file in-case of future reference.

Updating the configuration file

Once the files are located, add the below mentioned parameter with its value to the [DEFAULT] section of the configuration file. serial_vm_backup=true

After successfully updating the file, restart the services or containers and these steps need to be followed on all the controller plane.

User Guide

E-Mail Notifications

Definition

Trilio can notify users via E-Mail upon the completion of backup and restore jobs.

The E-Mail will be sent to the owner of the Workload.

Requirements to activate E-Mail Notifications

To use the E-mail notifications, two requirements need to be met.

Both requirements need to be set or configured by the OpenStack Administrator. Please contact your OpenStack Administrator to verify the requirements.

User E-Mail assigned

As the E-Mail will be sent to the owner of the Workload does the OpenStack User, who created the workload, require to have an E-Mail address associated.

Trilio E-Mail Server configured

Trilio needs to know which E-Mail server to use, to send the E-mail notifications. Backup Administrators can do this in the "Backup Admin" area.

Activate/Deactivate the E-Mail Notifications

E-Mail notifications are activated tenant wide. To activate the E-Mail notification feature for a tenant follow these steps:

Login to Horizon
Navigate to the Backups
Navigate to Settings
Check/Uncheck the box for "Enable Email Alerts"

Example E-Mails

The following screenshots show example E-mails send by Trilio.

Admin Guide

Managing Trusts

Trilio is using the OpenStack Keystone Trust system which enables the Trilio service user to act in the name of another OpenStack user.

This system is used during all backup and restore features.

OpenStack Administrators should never have the need to directly work with the trusts created.

The cloud-trust is created during the Trilio configuration and further trusts are created as necessary upon creating or modifying a workload.

Trusts can only be worked with via CLI

List all trusts

Show a trust

<trust_id> ➡️ ID of the trust to show

Create a trust

<role_name> ➡️Name of the role that trust is created for
--is_cloud_trust {True,False} ➡️ Set to true if creating cloud admin trust. While creating cloud trust use same user and tenant which used to configure Trilio and keep the role admin.

Delete a trust

<trust_id> ➡️ ID of the trust to be deleted

Rebasing existing workloads

The Trilio solution is using the qcow2 backing file to provide full synthetic backups.

Especially when the NFS backup target is used, there are scenarios at which this backing file needs to be updated to a new mount path.

To make this process easier and streamlined Trilio is providing the following rebase tool.

Troubleshooting

General Troubleshooting Tips

Troubleshooting inside a complex environment like OpenStack can be very time-consuming.

The following tips will help to speed up the troubleshooting process to identify root causes.

What is happening where

OpenStack and Trilio are divided into multiple services. Each service has a very specific purpose that is called during a backup or recovery procedure. Knowing which service is doing what helps to understand where the error is happening, allowing more focused troubleshooting.

Important log files

Trilio services logs on RHOSP

On the Controller Node

Below Trilio containers gets deployed on the Contoller node.

API GUIDE

Features

A list of impactful features in Trilio for OpenStack.

Immutable Backups

Release version: 6.0

Purpose

Key Highlights

Pre-requisites:
- Create a new S3 bucket to enable the object-locking feature, as it cannot be enabled on existing buckets.
- Configure Object Locking in Compliance mode with a retention period of at least one day for enhanced protection.

How To Use It

Follow the steps mentioned to know how to use this feature in the product.

Configuration

To enable this feature, you need to adjust certain configuration settings in the product. Refer to the deployment guides of the desired distribution for detailed instructions.

Limitations

The feature may not work as expected if the object lifecycle policy is set for a backup target.
The same backup target cannot be used for DR or migration purposes, additional steps will be required to perform it.

Advanced Scheduler & Retention

Release version: 6.0

Purpose

Key Highlights

Flexible Scheduling Intervals: Users can now schedule snapshots across the following intervals:
- Hourly: For tasks requiring frequent backups.
- Daily: Ideal for daily operations requiring end-of-day snapshots.

How To Use It

Follow the steps mentioned to know how to use this feature in the product.

Limitations

While the Advanced Scheduler introduces significant improvements, it has certain limitations:

Immutable Backups:
- In case the user chooses the immutable backup storage, the scheduling policy will get limited options. The user can have only hourly scheduling and retention types and hourly will have only 24hrs interval option.
Resource Utilization:

Multiple Backup Targets

Release version: 6.0

Purpose

The feature aims to enhance the flexibility, scalability, and manageability of backup configurations in Trilio. By supporting multiple backup targets:

Organizations can align their backup strategies with diverse operational requirements.
Admin users can provide tenant users with more options for workload backups.
Access control over backup targets is improved, allowing organizations to secure sensitive data.

Key Highlights

Support for Multiple Backup Targets: Trilio now supports both NFS and S3 simultaneously for backup storage.
Admin Configuration: Admin users can configure multiple backup targets during deployment.
Tenant User Flexibility: Tenant users can choose from available backup targets when creating workloads.

How To Use It

Follow the steps mentioned to know how to use this feature in the product.

Configuration

To take advantage of this feature, you need to adjust certain configuration settings in the product. Refer to the deployment guides of the desired distribution for detailed instructions.

Limitations

Backup Targets are configured during deployment. Modifying them may require redeploying Trilio.
While this feature is highly expandable, it currently limits the isolation of the backup targets to the projects only.

Snapshots

Definition

A Snapshot is a single Trilio backup of a workload including all data and metadata. It contains the information of all VM's that are protected by the workload.

List of Snapshots

Using Horizon

Login to Horizon
Navigate to the Backups
Navigate to Workloads
Identify the workload to show the details on

The List of Snapshots for the chosen Workload contains the following additional information:

Creation Time
Name of the Snapshot
Description of the Snapshot
Total amount of Restores from this Snapshot

Using CLI

--workload_id <workload_id> ➡️ Filter results by workload_id
--tvault_node <host> ➡️ List all the snapshot operations scheduled on a tvault node(Default=None)
--date_from <date_from>

Creating a Snapshot

Snapshots are automatically created by the Trilio scheduler. If necessary or in case of deactivated scheduler is it possible to create a Snapshot on demand.

Using Horizon

There are 2 possibilities to create a snapshot on demand.

Possibility 1: From the Workloads overview

Login to Horizon
Navigate to Backups
Navigate to Workloads
Identify the workload that shall create a Snapshot

Possibility 2: From the Workload Snapshot list

Login to Horizon
Navigate to Backups
Navigate to Workloads
Identify the workload that shall create a Snapshot

Using CLI

<workload_id>➡️ID of the workload to snapshot.
--full➡️ Specify if a full snapshot is required.
--display-name <display-name>

Snapshot overview

Each Snapshot contains a lot of information about the backup. These information can be seen in the Snapshot overview.

Using Horizon

To reach the Snapshot Overview follow these steps:

Login to Horizon
Navigate to Backups
Navigate to Workloads
Identify the workload that contains the Snapshot to show

Details Tab

The Snapshot Details Tab shows the most important information about the Snapshot.

Snapshot Name / Description
Snapshot Type
Time Taken
Size

Restores Tab

The Snapshot Restores Tab shows the list of Restores that have been started from the chosen Snapshot. It is possible to start Restores from here.

Please refer to the User Guide to learn more about Restores.

Misc. Tab

The Snapshot Miscellaneous Tab provides the remaining metadata information about the Snapshot.

Creation Time
Last Update time
Snapshot ID
Workload ID of the Workload containing the Snapshot

Using CLI

<snapshot_id>➡️ID of the snapshot to be shown
--output <output>➡️Option to get additional snapshot details, Specify --output metadata for snapshot metadata, Specify --output networks for snapshot vms networks, Specify --output disks for snapshot vms disks

Delete Snapshots

Once a Snapshot is no longer needed, it can be safely deleted from a Workload.

The retention policy will automatically delete the oldest Snapshots according to the configure policy.

You have to delete all Snapshots to be able to delete a Workload.

Deleting a Trilio Snapshot will not delete any OpenStack Cinder Snapshots. Those need to be deleted separately if desired.

Using Horizon

There are 2 possibilities to delete a Snapshot.

Possibility 1: Single Snapshot deletion through the submenu

To delete a single Snapshot through the submenu follow these steps:

Login to Horizon
Navigate to Backups
Navigate to Workloads
Identify the workload that contains the Snapshot to delete

Possibility 2: Multiple Snapshot deletion through checkbox in Snapshot overview

To delete one or more Snapshots through the Snapshot overview do the following:

Login to Horizon
Navigate to Backups
Navigate to Workloads
Identify the workload that contains the Snapshot to show

Using CLI

<snapshot_id>➡️ID of the snapshot to be deleted

Snapshot Cancel

Ongoing Snapshots can be canceled.

Canceled Snapshots will be treated like errored Snapshots

Using Horizon

Login to Horizon
Navigate to Backups
Navigate to Workloads
Identify the workload that contains the Snapshot to cancel

Using CLI

<snapshot_id>➡️ID of the snapshot to be canceled

Getting started with Trilio on OpenStack-Helm

1. Prepare for deployment

1.1] Install Helm CLI Client

Ensure the Helm CLI client is installed on the node from which you are installing Trilio for OpenStack.

1.2] (Optional) Install NFS Client Package

If you plan to use NFS as a backup target, install nfs-common on each Kubernetes node where TrilioVault is running. Skip this step for S3 backup targets.

SSH into each Kubernetes nodes which have the following labels

Run this command on the respective nodes:

1.3] Install Necessary Dependencies

Run the following command on the installation node:

2] Clone Helm Chart Repository

Refer to the link to get release specific values of the placeholder, viz trilio_branch.

3] Configure Container Image Tags

Select the appropriate image values file based on your OpenStack-Helm setup. Update the Trilio-Openstack image tags accordingly.

If your OS Helm cloud version is 2023.1 then images yaml file name is 2023.1.yaml

4] Create the `trilio-openstack` Namespace

To isolate trilio-openstack services, create a dedicated Kubernetes namespace:

5] Label Kubernetes Nodes for TrilioVault Control Plane

Trilio for OpenStack control plane services should run on Kubernetes nodes labeled with triliovault-control-plane=enabled. Only nodes labeled with openstack-control-plane should be selected. For high availability, it is recommended to use three Kubernetes nodes.

Steps:

1] Retrieve the OpenStack control plane node names:

2] Assign the triliovault-control-plane label to the selected nodes:

3] Verify the nodes with the assigned label:

6] Configure the Backup Target for Trilio-OpenStack

Backup target storage is used to store backup images taken by Trilio and details needed for configuration:

The following backup target types are supported by Trilio

a) NFS

b) S3

Steps:

If using NFS as the backup target, define its details in below file:

If using S3, configure its details in below file:

If using S3 with TLS enabled and self-signed certificates, store the CA certificate in below file:

The deployment scripts will automatically place this certificate in the required location.

We will be using this yaml file in trilio-openstack 'install' command at later step in this document.

7] Provide Cloud Admin Credentials in keystone.yaml

The cloud admin user in Keystone must have the admin role on the cloud domain. Update the required credentials in below file:

8] Retrieve and Configure Keystone, Database and RabbitMQ Credentials

For Openstack Helm; Please ensure that the correct ca.crt is present inside the secret “trilio-ca-cert” in the openstack namespace. If the secret is created with a different name, make sure to update the reference in the ./get_admin_creds.sh script before executing it.

Separate RabbitMQ Installation:
Fetch Internal and Public Domain Names of the Kubernetes Cluster
Fetch Keystone, RabbitMQ, and Database Admin Credentials a. These credentials are required for Trilio deployment. b. Navigate to the utils directory:
c. Generate the admin credentials file using the previously retrieved domain names

9] Configure Ceph Storage (if used as Nova/Cinder Backend)

If your setup uses Ceph as the storage backend for Nova/Cinder, configure Ceph settings for Trilio.

Manual Approach

1] Edit the Ceph configuration file:

a) Set rbd_user and keyring (the user should have read/write access to the Nova/Cinder pools). b) By default, the cinder/nova user usually has these permissions, but it’s recommended to verify.

2] Copy the contents of /etc/ceph/ceph.conf into the appropriate Trilio template file:

Automated Approach

1] Run the Ceph configuration script:

2] Verify that the output is correctly written to:

10] Create Docker Registry Credentials Secret

Trilio images are hosted in a private registry. You must create an ImagePullSecret in the trilio-openstack namespace.

1] Navigate to the utilities directory:

2] Run the script with Trilio’s Docker registry credentials kubernetes secret:

3] Verify that the secret has been created successfully:

11. Install Trilio for OpenStack Helm Chart

11.1] Review the Installation Script

11.1.1] Open the install.sh Script

The install.sh script installs the Trilio Helm chart in the trilio-openstack namespace.

11.1.2] Configure Backup Target

Modify the script to select the appropriate backup target:

a) NFS Backup Target: Default configuration includes nfs.yaml.

b) S3 Backup Target: Replace nfs.yaml with s3.yaml.

Example Configuration for S3:

11.1.3] Select the Appropriate OpenStack Helm Version

Use the correct YAML file based on your OpenStack Helm Version:

Antelope → 2023.1.yaml
Bobcat (Default)→ 2023.2.yaml

11.1.4] Validate values_overrides Configuration

Ensure the correct configurations are used:

Disable Ceph in ceph.yaml if not applicable.
Remove tls_public_endpoint.yaml if TLS is unnecessary.

11.2] Run the Installation Script

Execute the installation:

11.3] Configure DNS for Public Endpoints

11.3.1] Retrieve Ingress External IP

Example Output:

11.3.2] Fetch TrilioVault FQDNs

Example Output:

If the ingress service doesn’t have an IP assigned, follow these steps:

1] Check the Ingress Controller Deployment

Look for the ingress-nginx-controller deployment, typically in the ingress-nginx or kube-system namespace:

2] Verify the --watch-namespace Arg

If the controller has a --watch-namespace argument, it means it’s watching only specific namespaces for ingress resources.

3] Update watch-namespace to include trilio-openstack

Edit the deployment to include trilio-openstack in the comma-separated list of namespaces:

Example --watch-namespace arg:

4] Restart the Controller

This will happen automatically when you edit the deployment, but you can manually trigger it if needed:

11.4] Verify Installation

11.4.1] Check Helm Release Status

11.4.2] Validate Deployed Containers

Ensure correct image versions are used by checking container tags or SHA digests.

11.4.3] Verify Pod Status

Example Output:

11.4.4] Check Job Completion

Example Output:

11.4.5] Verify NFS Backup Target (if applicable)

Example Output:

11.4.6] Validate S3 Backup Target (if applicable)

Ensure S3 is correctly mounted on all WLM pods.

Trilio-OpenStack Helm Chart Installation is Done!

Logs:

1] triliovault-datamover-api service logs.

Logs available on kuberentes nodes

2] trliovault-datamover service logs

Logs available on kuberentes nodes

3] triliovault-wlm-api, triliovault-wlm-cron, triliovault-wlm-scheduler, triliovault-wlm-workloads services logs

Logs available on kuberentes nodes

12] Install Trilio for OpenStack Horizon Plugin

Below are the steps to patch the Horizon deployment in an OpenStack Helm setup to install the Trilio Horizon Plugin.

12.1] Pre-requisites

Horizon is deployed via OpenStack Helm and is running in the openstack namespace.
Docker registry secret triliovault-image-registry must already exist in the openstack namespace from the steps performed during Trilio Installation.

If not already created, follow this command:

12.2] Patch Horizon Deployment

Use the command below to patch the Horizon deployment with the Trilio Horizon Plugin image. Update the image tag as needed for your release.

12.3] Verification

After patching:

Ensure the Horizon pods are restarted and running with the new image:

Access the Horizon dashboard and verify the TrilioVault section appears in the UI.

Trilio Installation on RHOSO

The Red Hat OpenStack Services on OpenShift 18.0 is the supported and recommended method to deploy and maintain any RHOSO installation.

Trilio is integrating natively into the RHOSO. Manual deployment methods are not supported for RHOSO.

1. Prepare for deployment

Refer to the link Resources to get release specific values of the placeholders, viz Container URLs, trilio_branch, RHOSO Version and CONTAINER-TAG-VERSION in this document as per the OpenStack environment:

1.1] Pre-requisites

Podman tool should be available on the bastion host.
All commands must be executed from the bastion host where RHOSO OpenStack was installed.
Install the ruamel.yaml package using the following command: pip3 install ruamel.yaml

1.2] Clone triliovault-cfg-scripts repository

The following steps are to be done on the bastion node on an already installed RHOSO environment.

The following command clones the triliovault-cfg-scripts github repository.

1.3] Create namespace for Trilio control plane services

1.4] Create the trilio-openstack-secret in the trilio-openstack namespace.

In this secret we keep passwords and s3 keys in base64 encoded form.

In this trilio-openstack-secret.yaml file you need to fill the base64 encoded strings for container registry password, s3-keys and other passwords.

If you want to use s3 as backup storage then you need to provide s3 access keys and secret keys for all the s3 buckets in base64 encoded format.

If you dont want to use s3 as backup storage, you need to remove all s3 key parameters from this secret file.

To get base64 encoded string please use following linux command

If you want to using old db approach you can remove the DbRootPassword parameter

Parameter

Description

1.5] Create image pull secret

Following script creates image pull secret for Trilio container images. User need to pass image registry url and authentication user name of that registry. This script reads registry user password from trilio-openstack-secret secret.

By default Trilio container images are available in RedHat connect registry, it's url is registry.connect.redhat.com. User needs to provide this registry url and it's user name to the script.

If user wants to use a different registry to keep the Trilio container images, then user need to pull Trilio images from registry.connect.redhat.com and push them to user's registry. In this case user need to provide it's registry url and user name to following command.

2] Install Trilio Control Plane Services

2.1] Install Operator - tvo-operator

You can install the Trilio for OpenStack Operator using either of the following methods:

Method 1: Install Using local shell Script

Please get value of parameter TVO_OPERATOR_CONTAINER_IMAGE_URL from . This is Trilio for OpenStack Operator container image tag.
Run the following commands:

Method 2: Install Using Operator Hub (OpenShift Console)

Log in to the OpenShift Console using the admin user.
Create a namespace named tvo-operator-system.
Switch to the tvo-operator-system namespace.

Note: You can use either method based on your deployment preference. Script-based installation is recommended for automated or CLI-driven environments.

Verify the tvo operator pod got created

Verify that operator CRD is installed

2.2] Edit tvo-operator-inputs.yaml file

This file named tvo-operator-inputs.yaml is used to create CR of kind TVOControlPlane. This CR is responsible to deploy Trilio control plane services.

Run the script below to fill in some of the details automatically in tvo-operator-inputs.yaml.

Above script automatically fills in some details like Trilio image tags, memcached_servers, keystone, database, and rabbitmq.

User need to manually fill in backup target details in the file tvo-operator-inputs.yaml.

Review the file tvo-operator-inputs.yaml and make sure all the details are correct. If there is any change required, you can edit this file. Above script only takes default parameters during script execution.

Operator parameter details from file tvo-operator-inputs.yaml that user need to edit:

Note: Trilio supports two database deployment approaches, depending on the deployment model:

OpenStack Galera (Old Database approach)
- Trilio uses the already deployed Galera from 'OpenStack' namespace to create necessary databases.
- Please refer following configuration parameters to use old database approach. User need to set this parameters in tvo-operator-inputs.yaml file.

Trilio Galera (New Database approach)
- Trilio deploys fresh Galera cluster in 'trilio-openstack' namespace and uses it to create necessary databases.
- Please refer following configuration parameters to use new database approach. User need to set this parameters in tvo-operator-inputs.yaml file.

Parameter

Description

Edit Mode

2.3] Set correct labels to Kubernetes nodes.

Trilio control plane services will be deployed on OpenShift nodes having label trilio-control-plane=enabled . It is recommended to use three Kubernetes nodes for Trilio control plane services. Please use following commands to assign correct labels to nodes.

Get list of OpenShift nodes

Assign ‘trilio-control-plane=enabled' label to any three nodes of your choice where you want to deploy TVO control plane services.

Verify list of nodes having 'trilio-control-plane=enabled' label

2.4] Create TLS certificate secrets

Following script creates TLS certificates for Trilio services and defines secrets having these certs.

Edit '$PUBLIC_ENDPOINT_DOMAIN' parameter in utils/certicate.yaml file and set it to correct value. Refer openstack keystone service public endpoint.

Create certificates and secrets

You can verify if these cert secrets are created in 'trilio-openstack' namespace.

2.5] Run deploy command

2.6] Check logs

2.7] Check deployment status

2.8] Verify successful deployment of T4O control plane services.

Verify if wlm cloud trust created successfully

3] Install Trilio Data Plane Services

Set context to ‘openstack' namespace. All the trilio data plane resources will be created in 'openstack’ namespace.

3.1] Create the trilio-openstack-secret in the openstack namespace. This secret is needed for the Trilio data plane.

3.2] User need to review below parameters fill all input parameters needed for Trilio data plane services in following cm-trilio-datamover.yaml file.

Run the script below to fill in some of the details automatically in cm-trilio-datamover.yaml.

Above script automatically fills in some details like rabbit_host, rabbit_ssl, database_host, database_port, triliovault_backup_targets.

User need to manually fill in trilio-container-image-tags for datamover and wlm images, trilio_container_registry_username, trilio_container_registry_password and trilio_container_registry_url in the file cm-trilio-datamover.yaml.

Review the file cm-trilio-datamover.yaml and make sure all the details are correct. If there is any change required, you can edit this file.

Parameter

Description

Edit Mode

Create config map having all input parameters for Trilio data plane services deployment.

3.3] Create cm-trilio-datamover config map

3.4] Edit file ‘trilio-datamover-service.yaml' and set correct tag for container image 'openStackAnsibleEERunnerImage

3.5] Following script creates CRD “OpenStackDataPlaneService“ resource for Trilio

3.6] Trigger Deployment of Trilio data plane services

In this step we will trigger the ansible scripts execution to deploy Trilio data plane components. Get Data Plane NodeSet names using following command

Edit two things in following file

Set Unique ‘name' for every ansible execution for ‘OpenStackDataPlaneDeployment’
Set correct name for 'nodeSets’ parameter. Take nodeSet name from previous step.

To check list of deployment names alreday used, please use following command

Trigger Trilio Data plane deployment execution

3.7] Check deployment logs.

Edit parameter name : <OpenStackDataPlaneDeployment_NAME>, use name from above steps.

If it fails or completes and you want to run it again, you need to change the name of CR resource ‘OpenStackDataPlaneDeployment' to something new and unique in following template 'trilio-data-plane-deployment.yaml' and create it again using oc create command.

3.8] Verify deployment completed well

4] Install Trilio Horizon Plugin

Pre-requisite: You should have created image pull secret for Trilio container images.

Get the openstackversion CR

Edit the openstackversion CR resource/object and change horizonImage undercustomContainerImages Set 'horizonImage:' to Trilio Horizon Plugin container image url as shown below.

For example: if resource name is 'openstack-controlplane'

Save changes and exit. [Use escape + Colon + wq like linux vi editor.]
Verify if changes are done correctly using below command.

Increase HAproxy route timeout

Run the following command to set the route timeout to 180 seconds:

This annotation configures the HAProxy router to allow backend requests up to the specified timeout duration.

Verify the HAproxy route timeout

Confirm that the timeout annotation has been applied successfully:

You should see an output similar to:

You can access the OpenStack horizon using your same URL and login using same credentials. This openstack horizon will have Trilio UI components as well by verifying using the UI horizon.

5] Advanced configurations (Optional)

5.1] Attaching Additional Networks to Trilio Pods

Trilio pods can attach additional networks using the networks parameter in tvo-operator-inputs.yaml. This enables Trilio components to connect to custom or isolated networks.

5.2] Copy NetworkAttachmentDefinition (NAD) to `trilio-openstack`

If a network exists in the openstack namespace, it must be copied to trilio-openstack.

Example: copying the storage network.

Export NAD from openstack
Remove namespace-specific metadata
Apply NAD in trilio-openstack

5.3] Configure networks in `tvo-operator-inputs.yaml` in

Each Trilio pod includes a networks field where you can specify additional networks.

5.4] Specify networks for each pod

Provide a comma-separated list of network names. These networks must exist in the trilio-openstack namespace.

Example:

This attaches the storage and tenant networks to the triliovault_wlm_api pod.

Note:

All networks listed in networks must exist as NADs in trilio-openstack.
If a network exists in another namespace, export and recreate it in trilio-openstack.

Trilio Installation on RHOSP

The Red Hat OpenStack Platform Director is the supported and recommended method to deploy and maintain any RHOSP installation.

Trilio is integrating natively into the RHOSP Director. Manual deployment methods are not supported for RHOSP.

1. Prepare for deployment

Refer to the link Resources to get release specific values of the placeholders, viz Container URLs, trilio_branch, RHOSP Version and CONTAINER-TAG-VERSION in this document as per the OpenStack environment:

1.1] Select 'backup target' type

Backup target storage is used to store backup images taken by Trilio and details needed for configuration:

The following backup target types are supported by Trilio

a) NFS

Need NFS share path

b) Amazon S3

- S3 Access Key - Secret Key - Region - Bucket name

c) Other S3 compatible storage (Like Ceph based S3)

- S3 Access Key - Secret Key - Region - Endpoint URL (Valid for S3 other than Amazon S3) - Bucket name

1.2] Clone triliovault-cfg-scripts repository

The following steps are to be done on the undercloud node on an already installed RHOSP environment. The overcloud-deploy command has to be run successfully already and the overcloud should be available.

All commands need to be run as a stack user on the undercloud node

Refer to the word <RHOSP_RELEASE_DIRECTORY> as rhosp17 in the below sections

The following command clones the triliovault-cfg-scripts github repository.

1.3] Set executable permissions for all shell scripts

1.4] If the backup target type is 'Ceph based S3' with SSL:

If your backup target is CEPH S3 with SSL and SSL certificates are self-signed or authorized by a private CA, then the user needs to provide a CA chain certificate to validate the SSL requests. For all s3 backup target with self signed TLS certificates, user need to copy ca chain files in following location and in given file name format in trilio puppet module. Edit <S3_BACKUP_TARGET_NAME>, <S3_SELF_SIGNED_CERT_CA_CHAIN_FILE> parameters in following command.

For example if S3_BACKUP_TARGET_NAME = BT2_S3 and your S3_SELF_SIGNED_CERT_CA_CHAIN_FILE='s3-ca.pem' then command to copy this ca chain file to trilio puppet module would be

2] Update the overcloud roles data file to include Trilio services

Trilio contains multiple services. Add these services to your roles_data.yaml.

In the case of uncustomized roles_data.yaml can the default file be found on the undercloud at:

/usr/share/openstack-tripleo-heat-templates/roles_data.yaml

Add the following services to the roles_data.yaml

All commands need to be run as a 'stack' user

2.1] Add Trilio Datamover Api and Trilio Workload Manager services to role data file

This service needs to share the same role as the keystone and database service. In the case of the pre-defined roles, these services will run on the role Controller. In the case of custom-defined roles, it is necessary to use the same role where OS::TripleO::Services::Keystone service installed.

Add the following line to the identified role:

Note : If s3 backup target is NOT used, the above entry of TrilioObjectStore should not be done in role data file

2.2] Add Trilio Datamover Service to role data file

This service needs to share the same role as the nova-compute service. In the case of the pre-defined roles will the nova-compute service run on the role Compute. In the case of custom-defined roles, it is necessary to use the role that the nova-compute service uses.

Add the following line to the identified role:

3] Prepare Trilio container images

All commands need to be run as a 'stack' user

Trilio containers are pushed to the RedHat Container Registry. Registry URL: 'registry.connect.redhat.com'. For Container URLs, please refer

There are three registry methods available in the RedHat OpenStack Platform.

Remote Registry
Local Registry
Satellite Server

3.1] Remote Registry

Follow this section when 'Remote Registry' is used.

In this method, container images get downloaded directly on overcloud nodes during overcloud deploy/update command execution. Users can set the remote registry to a redhat registry or any other private registry that they want to use. The user needs to provide credentials for the registry in containers-prepare-parameter.yaml file.

Make sure other OpenStack service images are also using the same method to pull container images. If it's not the case you can not use this method.
Populate containers-prepare-parameter.yaml with content like the following. Important parameters are push_destination: false, ContainerImageRegistryLogin: true and registry credentials. Trilio container images are published to registry registry.connect.redhat.com. Credentials of registry 'registry.redhat.io' will work for registry.connect.redhat.com registry too.

Note: This file containers-prepare-parameter.yaml

Redhat document for remote registry method:

Note: File 'containers-prepare-parameter.yaml' gets created as output of command 'openstack tripleo container image prepare'. Refer above document by RedHat

3. Make sure you have network connectivity to the above registries from all overcloud nodes. Otherwise image pull operation will fail.

4. The user needs to manually populate the trilio_env.yaml file with Trilio container image URLs as given below:

trilio_env.yaml file path:

cd triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/

At this step, you have configured Trilio image URLs in the necessary environment file.

3.2] Local Registry

Follow this section when 'local registry' is used on the undercloud.

In this case, it is necessary to push the Trilio containers to the undercloud registry. Trilio provides shell scripts that will pull the containers from registry.connect.redhat.com and push them to the undercloud and update the trilio_env.yaml.

At this step, you have downloaded Trilio container images and configured Trilio image URLs in the necessary environment file.

3.3] Red Hat Satellite Server

Follow this section when a Satellite Server is used for the container registry.

Pull the Trilio containers on the Red Hat Satellite using the given

Populate the trilio_env.yaml with container URLs.

At this step, you have downloaded Trilio container images into the RedHat satellite server and configured Trilio image URLs in the necessary environment file.

4] Provide environment details in trilio-env.yaml

Edit /home/stack/triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_env.yaml file and provide backup target details and other necessary details in the provided environment file. This environment file will be used in the overcloud deployment to configure Trilio components. Container image names have already been populated in the preparation of the container images. Still, it is recommended to verify the container URLs.

You don't need to provide anything for resource_registry, keep it as it is.

Parameter

Description

4.1] TrilioBackupTargets Details

T4O supports setting up multiple target backend for storing snapshots. User can define any number of storage backends as required. At a high level, NFS and S3 are supported.

Following table provides the details of parameters to be set in trilio_env.yaml file against all the S3 target backends.

Parameters

Description

Following table provides the details of parameters to be set in trilio_env.yaml file against all the NFS target backends.

Parameters

Description

4.2] Update triliovault object store yaml

After you fill in details of backup targets in trilio_env.yaml, user needs to run following script from ‘scripts' directory on undercloud node. This script will update ‘services/triliovault-object-store.yaml' file. User don’t need to verify that.

5.1] Change the directory and run the script

5.2] Output will be written to the below file.

Include this file in your overcloud deploy command as an environment file with the option "-e"

6] Fetch ids of required OpenStack resources

6.1] User needs to source 'overcloudrc' file of cloud admin user. This is needed to run OpenStack CLI.

For only this section user needs to source the cloudrc file of overcloud node

6.2] User must have filled in the cloud admin user details of overcloud in 'trilio_env.yaml' file in the 'Provide environment details in trilio-env.yaml' section. If not please do so.

6.3] Cloud admin user should have admin role on cloud admin domain

6.4] After this, user can run the following script.

The output will be written to

7] Load necessary Linux drivers on all Controller and Compute nodes

For TrilioVault functionality to work, we need the following Linux kernel modules to be loaded on all controllers and compute nodes(Where Trilio WLM and Datamover services are going to be installed).

7.1] Install nbd module

7.2] Install fuse module

8] Upload Trilio puppet module

All commands need to be run as a 'stack' user on undercloud node

8.1] Source the stackrc

8.2] The following commands upload the Trilio puppet module to the overcloud registry. The actual upload happens upon the next deployment.

9] Deploy overcloud with Trilio environment

9.1] Include the environment file `trilio_defaults.yaml` in overcloud deploy command with `-e` option as shown below.

This YAML file holds the default values, like default Trustee Role is creator and Keystone endpoint interface is Internal. There are some other parameters as well those User can update as per their requirements.

9.2] Additionally include the following heat environment files and roles data file we mentioned in the above sections in an overcloud deploy command:

trilio_env.yaml
roles_data.yaml
trilio_passwords.yaml

To include new environment files use -e option and for roles data files use -r option.\

Below is an example of an overcloud deploy command with Trilio environment:

Post-deployment for the multipath enabled environment, log into respective Datamover container and add uxsock_timeout with value as 60000 (i.e. 60 sec) in /etc/multipath.conf. Restart datamover container

10] Verify deployment

Please follow to verify the deployment.

11] Troubleshooting for overcloud deployment failures

Trilio components will be deployed using puppet scripts.

In case of the overcloud deployment failing do the following command provide the list of errors. The following document also provides valuable insights:

=> If any Trilio containers do not start well or are in a restarting state on the Controller/Compute node, use the following logs to debug.

12] Advanced Settings/Configuration

12.1] Configure Multi-IP NFS

This section is only required when the Multi-IP feature for NFS is required.

This feature allows us to set the IP to access the NFS Volume per datamover instead of globally.

i] On Undercloud node, change the directory

ii] Edit file `triliovault_nfs_map_input.yml` in the current directory and provide compute host and NFS share/IP map.

Get the overcloud Controller and Compute hostnames from the following command. Check Name column. Use exact host names in the triliovault_nfs_map_input.yml file.

Run this command on undercloud by sourcing stackrc.

Edit the input map file triliovault_nfs_map_input.yml and fill in all the details. Refer to for details about the structure.

Below is an example of how you can set the multi-IP NFS details:

You can not configure the different IPs for the Controllers/WLM nodes, you need to use the same share on all the controller nodes. You can configure the different IPs for Compute/Datamover nodes

iii] Update pyyaml on the undercloud node only

If pip isn't available please install pip on the undercloud.

Expand the map file to create a one-to-one mapping of the compute nodes and the NFS shares.

iv] Validate output map file

The result will be stored in the triliovault_nfs_map_output.yml file

Open file triliovault_nfs_map_output.yml available in the current directory and validate that all compute nodes are covered with all the necessary NFS shares.

v] Append this output map file to `triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_nfs_map.yaml`

Validate the changes in the file triliovault-cfg-scripts/redhat-director-scripts/<RHOSP_RELEASE_DIRECTORY>/environments/trilio_nfs_map.yaml

vi] Include the environment file (`trilio_nfs_map.yaml`) in overcloud deploy command with '-e' option as shown below.

vii] Ensure that `MultiIPNfsEnabled` is set to true in the `trilio_env.yaml` file and that NFS is used as a backup target.

viii] After this you need to run the overcloud deployment.

12.2] Haproxy customized configuration for Trilio dmapi service

The existing default HAproxy configuration works fine with most of the environments. Only when timeout issues with the Trilio Datamover Api are observed or other reasons are known, change the configuration as described here.

Following is the HAproxy conf file location on HAproxy nodes of the overcloud. Trilio Datamover API service HAproxy configuration gets added to this file.

Trilio Datamover HAproxy default configuration from the above file looks as follows:

The user can change the following configuration parameter values.

To change these default values, you need to do the following steps. i) On the undercloud node, open the following file for editing.

ii) Search the following entries and edit as required

iii) Save the changes and do the overcloud deployment again to reflect these changes for overcloud nodes.

12.3] Configure Custom Volume/Directory Mounts for the Trilio Datamover Service

i) If the user wants to add one or more extra volume/directory mounts to the Trilio Datamover Service container, they can use a variable named 'TrilioDatamoverOptVolumes' is available in the below file.

To add one more extra volume/directoy mount to the Trilio Datamover Service container it is necessary that volumes/directories should already be mounted on the Compute host

ii) The variable 'TrilioDatamoverOptVolumes' accepts a list of volume/bind mounts. User needs to edit the file and add their volume mounts in the below format.

iii) Lastly you need to do overcloud deploy/update.

After successful deployment, you will see that volume/directory mount will be mounted inside the Trilio Datamover Service container.

12.4] Advanced Ceph Configration (Optional)

We are using cinder's ceph user for interacting with Ceph cinder storage. This user name is defined using parameter - 'ceph_cinder_user'.

Details about multiple ceph configuration can be found .

Backup Targets

This document explains the concepts of Backup Targets and Backup Target Types in Trilio, their purpose, and how they provide additional flexibility and control for backup storage management.

1. Backup Targets (BTs)

Definition:

Backup Targets are storage backends where backups are stored. These can be any of the supported storage systems such as NFS (Network File System) or S3 (Simple Storage Service). Backup Targets act as the foundational layer for storing backup data.

Key Characteristics of Backup Targets:

They are storage systems connected to Trilio.
Supported storage types include:
- NFS: A shared file system accessible over a network.

How to configure Backup Target(s):

The Admin user will have to plan and make the desired Backup Targets available before deploying Trilio. Backup Targets need to be configured during the deployment of Trilio that will get mounted on the required hosts.

The below-mentioned entries need to be defined in the configuration file of the workloadmgrservices to enable the required Backup Targets, however, these parameters need not be populated manually. The deployment scripts will take care of it.

Define all the enabled backup target names separated by a comma under the DEFAULTsection of the config file and the config parameter enabled_backends
- Example:

where, NFS_BT1, S3_BT1, S3_BT2, and S3_BT3 are unique names of the Backup Targets and will have their own config sections with the same names in the configuration file, as mentioned below.

Define each of the Backup Target sections using all required parameters. These required parameters are based on the type of storage.
- For NFS storage:
  - vault_storage_type = nfs

List & Show Configured BTs

Using Horizon Dashboard

Log in to the OpenStack Horizon Dashboard as an Admin user.
Navigate to the Admin-> Backups-Admin -> Backup Targets
On the page, click the Backup Targets tab to see the list of Backup Target Types.

Using CLI

Create Backup Target:

Command:

Alias:

Options:

Example:

Delete Backup Target:

Command:

Alias:

Options:

Example:

List the available Backup Targets:

Command:

Alias:

Options:

Example:

Show Details of a Backup Target:

Command:

Alias:

Options:

Example:

Backup Target Set Default:

Command:

Alias:

Options:

Example:

2. Backup Target Types (BTTs)

Definition:

Backup Target Types are an abstraction layer over Backup Targets. They provide additional administrative controls and can be categorized based on their scope and access permissions.

Types of Backup Target Types:

Public:
- Accessible by all users and projects in the system.
- Suitable for shared storage scenarios where multiple teams or tenants use the same backup infrastructure.

Relationship Between Backup Targets and Backup Target Types:

A many-to-one relationship exists between Backup Target Types and Backup Targets.
- Multiple Backup Target Types can map to a single Backup Target.
- This allows administrators to define different policies or access levels for a shared storage backend.

Pre-created Backup Target Types

Trilio creates the BTTs of all the Backup Targets that are configured during deployment with the same name as the Backup Targets.
It inherits the provided configuration options for each Backup Target and creates the Public Backup Target Types by default.

List Available BTTs

Using Horizon Dashboard

Log in to the OpenStack Horizon Dashboard as an Admin user.
Navigate to the Admin-> Backups-Admin -> Backup Targets
On the page, click the Backup Target Types tab to see the list of Backup Target Types.

Using CLI

Command:

Alias:

Options:

Example:

Show Details of a BTT

Using Horizon Dashboard

Most of the relevant information about the BTT can be seen while .
Trilio does not provide a separate GUI for showing the additional details of the BTTs.
But, Trilio does provide a to get the additional details.

Using CLI

Command:

Alias:

Options:

Example:

Create a BTT

Using Horizon Dashboard

Log in to the OpenStack Horizon Dashboard as an Admin user.
Navigate to the Admin-> Backups-Admin -> Backup Targets
On the page, click the Backup Target Types tab to see the list of Backup Target Types.

Using CLI

Command:

Alias:

Options:

Example:

Modify a BTT

Modification of the Default Backup Target Type is not allowed.

Using Horizon Dashboard

Log in to the OpenStack Horizon Dashboard as an Admin user.
Navigate to the Admin-> Backups-Admin -> Backup Targets
On the page, click the Backup Target Types tab to see the list of Backup Target Types.

Using CLI

Command:

Alias:

Options:

Example:

Assign/Unassign Project(s) to/from a BTT

Project assignment is allowed only to the Private Backup Target Types.

Using Horizon Dashboard

Log in to the OpenStack Horizon Dashboard as an Admin user.
Navigate to the Admin-> Backups-Admin -> Backup Targets
On the page, click the Backup Target Types tab to see the list of Backup Target Types.

Using CLI

Assigning Projects:

Command:

Alias:

Options:

Example:

Unassigning Projects:

Command:

Alias:

Options:

Example:

Add/Remove BTT Metadata

Using Horizon Dashboard

Metadata updates are only possible through CLI

Using CLI

Adding Metadata:

Command:

Alias:

Options:

Example:

Removing Metadata:

Command:

Alias:

Options:

Example:

Delete a BTT

Removing Backup Target Types from an active Workload can lead to inconsistent behavior and potential backup operation failures.

Using Horizon Dashboard

Log in to the OpenStack Horizon Dashboard as an Admin user.
Navigate to the Admin-> Backups-Admin -> Backup Targets
On the page, click the Backup Target Types tab to see the list of Backup Target Types.

Using CLI

Command:

Alias:

Options:

Example:

3. User Interaction with Backup Target Types

How Users Choose Backup Storage:

Any user can select a Public Backup Target Type for storing backups, as these are universally accessible.
For Private Backup Target Types, users can only select them if the Backup Target Type is explicitly assigned to their project.
The user will have the option to select these Backup Target Types while creating a workload.

Backup Targets

This page contains the API guide for various operations on Backup Targets and Backup Target Types.

Backup Targets

Create Backup Target

Creates the backup target

POST https://<wlm_api_endpoint>/backup_targets

Input Parameters:

Path:

Parameter Name

Description

Headers:

Header Name

Value/Description

Body Format:

Sample Response

Delete a Backup Target

Deleting an existing backup target

Path:

Parameter Name

Description

Headers:

Header Name

Value/Description

Body Format:

Sample Response

Delete a Backup Target Type

Deleting an existing backup target type

Removing Backup Target Types from an active Workload can lead to inconsistent behavior and potential backup operation failures.

DELETE https://<wlm_api_endpoint>/backup_target_types/<backup_target_type_id>

Input Parameters:

Path:

Parameter Name

Description

Headers:

Header Name

Value/Description

Sample Response

T4O-6.x

About Trilio for OpenStack

Welcome to Trilio for OpenStack

hashtagTrilio Data, Inc

hashtagAbout Trilio for OpenStack

hashtagAbout this Documentation

T4O Architecture

hashtagBackup-as-a-Service

hashtagMain Components

hashtagWorkloadManager

hashtagDataMover

hashtagHorizon Dashboard Plugin

hashtagService Endpoints

hashtagNetwork Topology

Release Notes

hashtag6.1.7

hashtagRelease Date : 10th Feb'2026

Features

hashtagImmutable Backups

hashtagPurpose

hashtagKey Highlights

hashtagHow To Use It

hashtagConfiguration

hashtagLimitations

hashtagAdvanced Scheduler & Retention

hashtagHow To Use It

hashtagMultiple Backup Targets

Compatibility Matrix

hashtagTrilio for OpenStack Compatibility Matrix

Resources

Getting Started

Requirements

hashtagCloud-Native and Containerized

hashtagSummary of Requirements

Network Considerations

hashtagExisting endpoints in OpenStack

Installation Strategy and Preparation

hashtagTenant Quotas

Getting started with Trilio on Red-Hat OpenStack Platform

Licensing

hashtagApply license through Horizon

hashtagApply license through CLI

Installing WorkloadManager CLI client

hashtagAbout the workloadmgr CLI client

Uninstall Trilio

Uninstalling from OpenStack Helm/MOSK

hashtag1] Uninstall trilio-openstack helm chart

hashtag2] Uninstall Dynamic Backup Targets (Optional)

hashtag3] Verify uninstallation

hashtag4] Clean TrilioVault’s OpenStack resources

hashtag5] Unmount the targets from All Worker and Master Nodes

Upgrading to T4O-6.x from older supported versions

Supported Trilio Upgrade Path

Upgrade Trilio

Upgrading on RHOSP

hashtag1] Prerequisites

hashtag2] Install latest Trilio release

hashtag3] Restart wlm-cron resource

hashtag4] Fetch backup target details

hashtag5] Import workloads

hashtag6] Update backing file path

Advanced Configuration

Switching NFS Backing file

hashtag

Multi-IP NFS Backup target mapping file configuration

hashtagIntroduction

Advanced Ceph configurations

Additions for multiple CEPH configurations

Serial Upload per Instance during Snapshot

hashtagFinding the required configuration file

hashtagUpdating the configuration file

User Guide

E-Mail Notifications

hashtagDefinition

hashtagRequirements to activate E-Mail Notifications

hashtagUser E-Mail assigned

hashtagTrilio E-Mail Server configured

hashtagActivate/Deactivate the E-Mail Notifications

hashtagExample E-Mails

Admin Guide

Trilio Data, Inc

About Trilio for OpenStack

About this Documentation

Backup-as-a-Service

Main Components

WorkloadManager

DataMover

Horizon Dashboard Plugin

Service Endpoints

Network Topology

6.1.7

Release Date : 10th Feb'2026

Immutable Backups

Purpose

Key Highlights

How To Use It

Configuration

Limitations

Advanced Scheduler & Retention

How To Use It

Multiple Backup Targets

Trilio for OpenStack Compatibility Matrix

Cloud-Native and Containerized

Summary of Requirements

Existing endpoints in OpenStack

Tenant Quotas

Apply license through Horizon

Apply license through CLI

About the workloadmgr CLI client

1] Uninstall trilio-openstack helm chart

2] Uninstall Dynamic Backup Targets (Optional)

3] Verify uninstallation

4] Clean TrilioVault’s OpenStack resources

5] Unmount the targets from All Worker and Master Nodes

1] Prerequisites

2] Install latest Trilio release

3] Restart wlm-cron resource

4] Fetch backup target details

5] Import workloads

6] Update backing file path

Introduction

Finding the required configuration file

Updating the configuration file

Definition

Requirements to activate E-Mail Notifications

User E-Mail assigned

Trilio E-Mail Server configured

Activate/Deactivate the E-Mail Notifications

Example E-Mails

List all trusts

Show a trust

Create a trust

Delete a trust

What is happening where

Trilio services logs on RHOSP

On the Controller Node

Trilio Data, Inc

About Trilio for OpenStack

About this Documentation

Backup-as-a-Service

Main Components

WorkloadManager

DataMover

Horizon Dashboard Plugin

Service Endpoints

Network Topology

Finding the required configuration file

Updating the configuration file

Existing endpoints in OpenStack

Tenant Quotas

OpenStack endpoints required by Trilio

Recommendation: Provide access to all OpenStack Endpoint types

Backup target access required by Trilio

AWS S3 Eventual Consistency

AWS Region Considerations

Trilio Cluster

Immutable Backups

Purpose

Key Highlights

How To Use It