Features

A list of impactful Trilio for Kubernetes features and use cases

Feature List

Operator and Helm based Deployment

Trilio for Kubernetes (T4K) is a cloud native application, built based on Kubernetes principles. It consists of a collection of CRDs and Controllers that manages Trilio objects that are Kubernetes resources. Like any other cloud native application, Trilio supports two Operator deployment methods:

1. Helm based Operator

2. Operator Lifecycle Management Operator

Trilio can be deployed and managed using these tools.

Application Types supported

Trilio provides an innovative approach to backup applications based on:

1. Helm charts - if an application is provisioned via the helm packaging methodology, T4K can back it up by providing it the name of the release and the helm version.

2. Operators - Operators are meant to manage the install, updates and life cycle of applications. Trilio can protect Operator based applications.

3. Custom Labels - Labels in Kubernetes are like tags that are applied to resources for better identification. Customers can choose to protect applications based on labels of its components. Labels are very powerful and can be used in various permutations and combinations to detect and find application resources.

4. Namespaces - Trilio provides a CR known as BackupPlan for users to define a set of applications to protect within a namespace. Users also end up using Namespaces themselves as the boundary to define their protection scope. Trilio for Kubernetes supports namespace based backups as well.

Kubernetes-native

The architecture of Trilio for Kubernetes is similar to the architecture and operating model of Kubernetes environments. As a result, a customer does not have to learn any new concepts or frameworks to operate Trilio for Kubernetes. If a customer understands Kubernetes architecture, they understand T4K architecture. Kubernetes Native also means that the Trilio application can be run and supported on any Kubernetes distribution.

Application Aware Backup Policies

Application aware backups have been around for quite some time. Application aware backups make sure the backups are "application consistent" and not "crash consistent". When backups provide application consistency, during backup processes, backup applications invoke application specific hooks within the container that give the application the ability to flush any in-memory data structures to disk and makes sure the disk structure are in a consistent state. Backup applications then perform a point in time copy of the application. This will make sure when these applications are restored, applications can restart reliably.

Application aware backups are relatively easy when the application is running in a single virtual machine. However cloud native applications are comprised of more than one Pod or PV. Hence, the invocation of application hooks need to be orchestrated based on the data flow in the application. Trilio provides a means to express the application hooks and the order in which these hooks need to be invoked to accomplish application consistent backups.

Ecosystem Integration

Prometheus

T4K integrates with de facto tools for monitoring and logging for Kubernetes clusters. Prometheus is a data collector engine for metrics and Grafana is a visualization tool of those metrics. T4K provides default dashboards along with standard installation, but customers can create more detailed charts and meaningful visualizations of their data protection metrics based on their needs.

Role Based Access Control (RBAC)

RBAC is built into Kubernetes clusters by design. Since T4K is built on the same principles on which Kubernetes is built, it automatically supports RBAC. T4K can be installed into individual namespaces or the entire cluster. Namespaces are generally the units used for multi-tenancy within Kubernetes.

Open Backup Format

Another key attribute of Trilio for Kubernetes is the format in which the backup is stored. T4K stores backups in an open QCOW2 format - which means that the backup is not stored in any proprietary format and thus augments the ‘open’ nature of cloud-native environments.

There are several advantages provided by a QCOW2 format.

1. Open - No hydration required for moving backup data. Scanning of data from a security perspective is also enabled.

2. Enables data efficiency by enabling a software only de-duplication solution. Only unique blocks are copied for incremental backups with pointers to the base image.

Multiple Target Types

The most popular backup target medias are NFS and S3 compatible storage types. Trilio supports both these storage types as backup/snapshot targets.

Multiple Targets

Trilio users can configure more than one target for their backup/snapshot needs. They can have NFS based local storage for mission critical apps and s3 based cloud storage for other applications.

For examples, follow Target section.

All backups/snapshots, both incremental and full will reside on the same target as per the configured BackupPlan .

Backups

Backups consists of backup of application resources along with the data present in the Persistent Volumes. Both application resources and data will stored on the target.

Snapshots

In the Snapshot process, only application resources are getting backed up on target. Volume Snapshots are getting maintained in the cluster for the data present in the Persistent Volumes. Data is not getting uploaded to target in this feature. This is the quick way to protect your application.

Incremental Forever

Incremental backups provide both space savings and efficient network bandwidth utilization. Trilio supports forever incremental backups which means all backups are incrementals after the first full backup is taken (concatenating diffs). This will enhance your TCO of the solution as it uses less storage and network bandwidth. This feature is not applicable to Snapshots as Snapshots are always Full snapshots.

Full Synthetic Backups

Though Trilio supports forever incremental backups, organizations only need to keep a certain number of backups at a given time, determined either by the backup count or by the date of the backups. Any older backups that exceed the count or the expiration date should be deleted to conserve backup storage. Since Trilio supports forever incrementals, it cannot delete all last backups. It will break the backup chain and more recent backups becomes unusable. Trilio creates and manages full synthetic backups, where Trilio merges all backups that were marked for deletion into one full backup and retains the full backup. All other backups are deleted from the backup media. This way Trilio continues to take incremental backups, but still maintains the list of backups according to user retention needs.

Hooks

Trilio for Kubernetes provides the ability to inject commands before and after a backup as well as before and after a restore. As a result, customers can take application consistent backups of their application or have the ability to extend their backup and restore workflows to achieve additional use cases within their environments.

For examples, follow Hooks section.

Retention

Retention is a way to retain backup/snapshot images that meets your business needs. Business reasons could be compliance, risk tolerance, data analytics, etc. Trilio supports retention policies that can be defined to meet your business needs.

Trilio Retention policy

You can define retention policies by number of yearly backups, monthly backups, weekly backups and daily backups. The above diagram explains how the backup/snapshot retention works in Trilio. Same is applicable to Snapshot feature as well.

For example, follow Retention Policy section.

Restore Transforms

In a microservices oriented architecture, components are loosely connected or are completely independent of each other. Another aspect is that applications, workloads or plain objects reference Kubernetes abstractions specific to a namespace or cluster. As a result, when migrating applications from one cluster/namespace to another, it becomes important for users to be able to change or edit the Kubernetes resources of an application so that it can function successfully in the target environment that it is being ported into. T4K 2.0 onwards, customers have the ability to transform and edit the metadata associated with their applications before it is restored into a target environment.

Metadata information such as storageclass or nodeport can be easily changed using the RestoreTransform feature.

Target Browser

In order to enable seamless Disaster Recovery or migration scenarios, Trilio for Kubernetes provides the ability to browse the contents of a target repository (where backups are kept), so that applications can be restored without having access to the original cluster or the metadata of the backup operation from the original cluster. As a result, a target can be connected to any cluster and applications can be readily restored from them. Target browsing is supported via the management console as well as the CLI.

Multicloud Management

Trilio supports multi-cloud management (MCM) by allowing users to manage multiple T4K instances via its management console. As a result, application and data management between multiple Kubernetes clusters is simplified via a single pane of glass.

Trilio's MCM feature is built as a peer-to-peer model. Any cluster can be the primary cluster and any cluster can be the secondary cluster as per the users preference. Since Trilio's management console is completely stateless and aligned with Kubernetes RBAC, each user can connect clusters as per their RBAC and that view will be saved specifically for that user upon next login activity.

Disaster Recovery Plan

Trilio provides a DRPlan feature that enables users to perform disaster recovery operations as part of a single workflow from the management console. Users can pick and choose backups from various backup repositories to create a plan in terms of restoring business operations. The plans can be focused on backend apps, frontend apps, middleware/ecosystem apps etc. The DRPlan is created and saved at the destination cluster - which means that the plan can be executed even when the source cluster is not available.

Encryption

Trilio for Kubernetes provides the capability to encrypt backups/snapshots. Encryption is enabled at the BackupPlan level and different keys will be created for each backupPlan. Encryption keys are stored as Kubernetes secrets, and integration with Vault will be provided soon. Trilio leverages the LUKS encryption format to protect data. LUKS is extremely flexible and secure providing a range of cipher suites.

For example, follow Encryption section.

Backup and Snapshot Immutability

Trilio provides the ability to create immutable T4K backups/snapshots, so that they cannot be deleted from until the user defined retention period is over. Trilio interfaces with target's locking and versioning feature to provide immutability. Immutability is set at the backupPlan level, so users have the granular capability to specify which applications need immutability support. Currently, any S3-compatible device (AWS S3, MinIO, Wasabi etc.) that allows locking is supported.

Include/Exclude GVKO

This feature enables you to explicitly include or exclude resources during backup, snapshot and restore processes. Resources listed in the IncludeResources section are always added to the final list of captured resources, while those in the ExcludeResources section are removed from it. Trilio also extends the include/exclude logic to the dependent resources of those specified in the Include and Exclude resources field.

Backup and Snapshot Process:

Application Scope

1. Custom

For custom applications, you can select resources for backup/snapshot by specifying a labelSelector or gvkSelector (Group, Version, Kind, Name) under the IncludeResources section. Trilio will process these selectors to accurately identify the resources to be included in the backup/snapshot.

custom-backupplan-include-exclude-resource-section

Exclusion: You can exclude specific resources from the backup/snapshot by defining them with a labelSelector or gvkSelector in the ExcludeResources section. Trilio will apply the exclusion logic to both the specified resources and their dependent resources.

Use Case:

• If your application requires a cluster-scoped resource not included in the namespace backup/snapshot, you can use include.

• If you want to perform a namespace backup/snapshot but explicitly exclude a resource, you can use exclude.

• If a namespace contains 10 deployments that share the same labels, and you want to exclude one specific deployment (e.g., XYZ), adding the common label to the IncludeResources section will cause Trilio to back up all 10 deployments, including XYZ. To prevent XYZ from being backed up, you can explicitly specify it in the ExcludeResources section using either a labelSelector or a gvkSelector (Group, Version, Kind, Name).

1. Operator

Please refer to this guide for detailed instructions on creating an operator Backup Plan. Trilio determines the operator resources for backup based on the inputs provided by the user in the operator section.

operator-backupplan-exclude-section

Exclusion: You can exclude specific operator resources by specifying them in the ExcludeResources section. Trilio will skip backing up those resources and their dependent resources.

1. Helm

The Include and Exclude resources options do not apply to Helm-based backups.

Namespace Scope

When backing up a namespace, all components within the namespace are backed up.

namespace-backupplan-include-exclude-section

Inclusion:

Resources can be included using either labelSelector or gvkSelector (Group, Version, Kind, Name). Inclusion is applied on top of the resources identified for the namespace backup. For instance, when backing up a namespace, all the resources within that namespace will be included, and the inclusion list will operate on top of it.

Use Case:

• Include Ignored Resources: A default ignore list is maintained in the backup code, containing components not included in the component/namespace-level backup. The backup/snapshot inclusion process incorporates everything specified in the IncludeResources, regardless of the Backup Ignore List. For instance, if a network interface is listed in the Backup Ignore List but a user provides the GVKN(Group, Version, Kind, Name) of that network interface, Trilio will back up the network interface based on the GVKN(Group, Version, Kind, Name).

• Include Child Resources: In some cases, a child resource may not be automatically included in the backup/snapshot, such as when a secret abc is a child of a custom resource xyz (i.e., the secret abc has the custom resource xyz listed in its ownerReferences). By default, only the parent resource xyz is backed up, as Trilio assumes the parent will recreate the child during restore, similar to how a deployment recreates ReplicaSets, and ReplicaSets recreate pods.

  However, when the parent resource may not recreate the child, you can explicitly include the child resource (e.g., secret abc) in the backup by specifying it in the IncludeResources section.

Exclusion:

Resources can be excluded based on either labelSelector or gvkSelector(Group, Version, Kind, Name) . Excluded resources are specified at the component level in application-based backups, while in namespace backups, exclusions are specified at the spec level.

• Inclusion is explicit, meaning resources designated for inclusion are always added to the list of captured resources for the component level. Conversely, exclusion is also explicit, where resources marked for exclusion are always removed from the final list of captured resources at the component level. Exclusion occurs after inclusion. Thus, if a GVKN(Group, Version, Kind, Name) is included and then added to exclusion, it will be excluded.

• TVK also identifies and excludes any dependent resources. For example, if a user chooses to exclude a deployment during backup, TVK automatically identifies and excludes associated resources like Persistent Volume Claims (PVCs) and Service Accounts (SAs) from the backup. The same principle applies to inclusion.

for example, follow Inclusion/Exclusion section.

Restore Process

restore-include-exclude-section

Inclusion:

You can select specific resources for restoration by using the IncludeResources section. This enables you to restore only the chosen resources, rather than the entire backup. Use Case: If your backup contains 10 deployments but you only want to restore one, you can use the IncludeResources section to select and restore just that specific deployment. Resources can be defined using either a labelSelector or a gvkSelector (Group, Version, Kind, Name).

For example, follow Restore with Inclusion section.

Exclusion:

You can exclude specific resources from being restored by defining them in the ExcludeResources section. Trilio will skip the restoration of those resources, along with their dependent resources.

Use Case:

• Exclude Virtual Machines: If a backup contains multiple Virtual Machines and you want to exclude a specific one (e.g., a CentOS VM), you can specify that VM in the ExcludeResources field. Trilio will automatically identify related resources, such as disks (PVCs), secrets, and ConfigMaps tied to the excluded VM, and will exclude them from the restore process as well.

For example, follow Restore with Exclusion section.

Protection of Restore Application

Trilio enables users to automatically protect an application that has been restored. A flag that controls this behavior allows Trilio to recreate resources like hooks, policies, backupPlans and automatically have the application protected as it moves from one environment to another. As a result, no matter where your application is running, once it is protected by T4K it is always protected.

Authentication - OIDC/LDAP

Trilio now supports authentication to the management console via OIDC, LDAP and many more in conjunction to supporting the original kubeconfig methods of authentication. As a result, Trilio offers a wide range of authentication support. Trilio leverages the tool called Dex to support authentication and all the connectors provided by Dex are supported by Trilio. For OpenShift environments, configuration to the management console is handled by Trilio by default.

Share/Clone Resource

In order to simplify management of multiple clusters, the ability to share T4K resources like policies, hooks, targets etc. is required, so that users can create a resource once and use it across many Kubernetes clusters. Trilio provides the ability to share T4K native resources across namespaces and clusters so as to enable simplified global management. This feature also supports creation of the resource based on a suffix and counter so as to avoid conflicts in case of cloning to multiple clusters at the same time.

Restore Cleanup

Trilio provides the ability to automatically clean up a restore in case it fails. Enabled as a flag, this feature enables quick retry attempts of a restore instead of manually cleaning out objects that may have failed. The flag can also be applied (patched) after a failure and the objects etc. will still be cleaned up. The Trilio restore object will be left behind for customers to look at error messages and logs.

Continuous Restore

Through the continuous restore feature, users can restore a certain number of backups of an application on a set of remote clusters. Remote clusters can read the backup images from the backup target and create a set of PVs from the backup data. Users can use these PVs to quickly failover an application to the remote cluster. The Continuous Restore feature significantly reduces the RTO of applications in DR scenarios. This feature can also be used for other use cases, including test/dev, blue/green deployments, migration, DR plan testing, etc. This feature is not applicable for Snapshots.