> 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/about-trilio-for-openstack/features.md). # 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. * **Disable object lifecycle policies** to prevent automated deletions. * Perform **manual deletion** of objects only after the retention period has expired. * **Retention** With the introduction of the immutable backups feature, Trilio’s retention policy has been changed. It's important to note that Trilio can no longer support incremental/full synthetic backups forever, as this functionality requires modifying the backup images. Instead, the following retention policy is now in place: * If the user wants to retain **n** number of backups, then the user needs to take full backups every **n** backups. * To keep at least **`n`** backups available, Trilio may retain **`2n`** backups, forming two backup chains. Once a chain is fully formed with one full backup and **n-1** incremental backup images, the second chain will start with a new full backup. The first chain will be removed once the second chain is fully formed with a full backup and **n-1** incremental backups. *** #### **How To Use It** *Follow the steps mentioned* [*here*](/openstack/user-guide/workloads.md#workload-create) *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. * **Weekly**: Suitable for less critical workloads. * **Monthly**: For long-term periodic backups. * **Yearly**: Designed for archival purposes. * **Snapshot Type Options**: * **Full Snapshots**: Each scheduling type allows the user to choose the full snapshot type.\ But, full snapshot type is mandatory for Weekly, Monthly, and Yearly scheduling types to avoid longer backup chains which may lead to data corruption. * **Incremental Snapshots**: Hourly and Daily scheduling types provide the options from either incremental or full snapshots. * **Advanced Retention Policies**: * Users can define retention settings for each scheduling type. * Retention can be based on: * **Number of Snapshots**: Keep a specified number of snapshots for the chosen schedule. * **Retention Duration**: This is based on the scheduling type selected by the user. * **Enhanced Management Efficiency**: * Simplifies backup strategies by tailoring frequency, type, and retention for specific workloads. * Supports compliance and long-term data retention policies. *** #### **How To Use It** *Follow the steps mentioned* [*here*](/openstack/user-guide/workloads.md#workload-create) *to know how to use this feature in the product.* *** **Limitations** While the Advanced Scheduler introduces significant improvements, it has certain limitations: 1. **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. 2. **Resource Utilization**: * Frequent full snapshots (e.g., on an hourly basis) may lead to higher storage and performance overhead. 3. **Complexity in Configuration**: * Advanced options may require more planning and understanding, increasing the learning curve for new users. 4. **Dependency on Storage Quotas**: * Users must ensure sufficient storage capacity to handle the retention policies and the frequency of snapshots. 5. **Manual Monitoring**: * In cases of excessive scheduling, manual intervention might be necessary to adjust retention policies or optimize schedules. *** ### **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. * **Enhanced Access Control:** Admin users can mark backup targets as private and restrict access to specific projects by creating backup target types and marking them as private. *** **How To Use It** *Follow the steps mentioned* [*here*](/openstack/user-guide/workloads.md#workload-create) *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. ### **Dynamic Mount Service (DMS)** **Release version:** 6.2 The Dynamic Mount Service (DMS) centralizes the mounting and unmounting of backup targets across every node that needs access to them — both controller and compute nodes. Instead of keeping a target mounted for the lifetime of the service, DMS mounts a target when a backup job needs it and unmounts it when the last job releases it. The 6.2 deployment runs **a single DMS server container per host** (one on the controller, one on each compute node) and replaces the **per-backup-target container** model used in earlier releases — there is no longer a separate `triliovault-object-store-` pod per S3 backup target. *** #### **Purpose** In earlier releases, backup targets were mounted statically on every Trilio node at service startup, with a dedicated container per S3 backup target on each node. That model created a wide surface area for stale or broken mounts — a single misbehaving target could impact node stability even when no jobs were active against it — and the per-BT container count grew linearly with the number of S3 backup targets. DMS replaces that model with a single per-host server that performs per-job, reference-counted mounts, so mount state closely tracks actual usage and failures stay isolated to the job that triggered them. *** #### **Key Highlights** * **Single DMS server container per host** replaces the per-BT object-store container model. One `trilio-dms-server` runs on the controller and one on each compute node, regardless of how many backup targets are configured. * **Per-job, reference-counted mounts.** A target is mounted on demand and stays mounted only for as long as at least one active job requires it. * **Works for both NFS and S3 backup targets.** S3 targets are served by `s3vaultfuse`, which DMS spawns and manages as a child process. * **Automatic stale-mount detection and recovery.** DMS detects dead FUSE processes and broken NFS sessions before every mount and cleans them up automatically. * **Secure S3 credential handling.** S3 credentials are stored in OpenStack Barbican and fetched at mount time using the job's Keystone token; they are never persisted in the WorkloadManager database. * **Controller- and compute-aware routing.** DMS routes mount requests to the specific node that needs the target — the controller for metadata operations, the compute node hosting an instance for data transfer. *** #### **How To Use It** DMS is transparent to end users. Administrators continue to configure backup targets and backup target types in the usual way; DMS handles the mount lifecycle behind the scenes. *** #### **Configuration** See [T4O Architecture](/openstack/about-trilio-for-openstack/triliovault-for-openstack-architecture.md#dynamic-mount-service-dms) for the architectural overview, and the [Backup Targets admin guide](/openstack/admin-guide/backup-targets.md) for the S3 Barbican secret payload requirements that DMS expects. ### **Nova Server Group Preservation** **Release version:** 6.2.1 Trilio captures the Nova server group each protected instance belongs to as part of every Snapshot, and restores that membership when the instance is brought back — preserving the affinity / anti-affinity placement policy of clustered applications across restore, migration and disaster recovery. *** #### **Purpose** Nova server groups enforce where instances are placed relative to one another through the `affinity`, `anti-affinity`, `soft-affinity` and `soft-anti-affinity` policies. Clustered applications depend on those guarantees — database replicas kept on separate hypervisors by an anti-affinity group, for example. Before this release, server group membership was not part of the backup, so restored and migrated instances silently lost their placement policy and had to be manually re-grouped afterwards. Because Nova only allows an instance to join a server group **at boot time**, re-grouping after a restore is not possible without recreating the instance - which makes capturing the membership at backup time and applying it at boot the only way to preserve it. *** #### **Key Highlights** * **Captured on every Snapshot.** Full and incremental Snapshots record the server group's ID, name and policy for each member instance, alongside the existing flavor and security group metadata. Instances that are not group members are unaffected. * **Restore behavior suited to each restore type.** Selective Restore lets the user pick the target server group per instance; One Click Restore reuses the captured group automatically; Inplace Restore is unaffected, since it does not boot new instances. * **A missing group never fails a One Click Restore.** If the captured group no longer exists on the target, the restore completes with the instance unassigned and records the reason under **Warning Message**, rather than failing a DR restore. * **Invalid input fails fast.** A non-existent server group ID submitted to a Selective Restore is rejected before any data transfer begins, reporting every invalid ID in a single message. *** #### **How To Use It** The capture side is automatic - no action is required to start recording server group membership. * **Horizon:** the Snapshot detail view shows a **Server Group** tab per instance, and the Selective Restore wizard adds a **Server Group** dropdown per instance, pre-selected to the captured group when it still exists on the target. * **CLI:** `workloadmgr snapshot-show ` reports a **Server Group** entry per instance; the Selective Restore `restore.json` accepts an optional `server_group` key per instance. * **REST API:** the Show Snapshot response includes a `server_group` object per instance, and the Selective Restore body accepts an optional `server_group` string per instance. See the [Restores](/openstack/user-guide/restores.md) user guide for the restore workflows and the [Restores API guide](/openstack/api-guide/restores.md) for the request format. *** #### **Configuration** None. The feature is active out of the box for all backup target types and requires no configuration option or deployment change. *** #### **Limitations** * **Server groups are not created on the target.** Trilio restores membership of an **existing** group; it does not recreate the group definition. For migration and disaster recovery, create the server group in the target project first. * **The group must exist in the project the restore runs in.** A group belonging to another project is treated as non-existent. * **Membership is applied at boot only.** This is a Nova constraint. Inplace Restore cannot change server group membership, and already-running instances are never added to or removed from groups. * **Placement remains Nova's decision.** If the group's policy cannot be satisfied - strict anti-affinity with too few compute hosts, for example, Nova rejects the boot and the restore fails with Nova's error, exactly as a manual boot into that group would. Note that for Selective Restore, restoring instances **alongside** the still-running originals doubles the group's membership, and therefore the number of hosts a strict anti-affinity policy needs.