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 Backup Target Types

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

Multiple Backup Targets

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

For examples, follow Backup Target section.

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

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.

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.

Backup Retention

Backup retention is a way to retain backup 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 retention works in Trilio.

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. 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 Immutability

Trilio provides the ability to create immutable T4K backups, so that they cannot be deleted from until the user defined retention period is over. Trilio interfaces with the backup storage 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

Backup Process:

Inclusion: Inclusion occurs atop the backup components outlined in the backup plan. For example, if the backup is for a namespace, all components within the namespace will be backed up, and the inclusion list will operate on top of it. A default ignore list is maintained in the backup code, containing components not included in the component/namespace-level backup.

The backup inclusion process incorporates everything specified in the GVKN (Group Version Kind Namespace), 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 of that network interface, TVK will back up the network interface based on the GVKN.

Exclusion: Resources can be excluded based on either Label Selectors or GVKN. Excluded resources are specified at the component level in component-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 is included and then added to exclusion, it will be excluded.

• TVK also identifies and restores 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.

Use Case:

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

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

Restore Process:

Exclusion in Restore Process: Exclusion in the restore process only affect the already backed-up resource. Any resource not part of the backup cannot be excluded during restoration.

Exclusion: If a user wishes to exclude certain applications from the backed-up set, they can define exclude labels for those specific applications during the restore process. TVK will identify and exclude these applications during the restore process while continuing to restore other applications in the backup.

Use Case: The exclusion feature in the restoration process offer selective restoration of backups containing multiple applications.

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.