Features
TrilioVault for Kubernetes (TVK) is a cloud native application, built based on Kubernetes principles. It consists of a collection of CRDs and Controllers that manages TrilioVault objects that are Kubernetes resources. Like any other cloud native application, TrilioVault supports two Operator deployment methods:
Helm based Operator
Operator Lifecycle Management Operator
TrilioVault can be deployed and managed using these tools.
TrilioVault provides an innovative approach to backup applications based on:
Helm charts - if an application is provisioned via the helm packaging methodology, TVK can back it up by providing it the name of the release and the helm version.
Operators - Operators are meant to manage the install, updates and life cycle of applications. TrilioVault can protect Operator based applications.
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.
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. TrilioVault for Kubernetes supports namespace based backups as well.
The architecture of TrilioVault 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 TrilioVault for Kubernetes. If a customer understands Kubernetes architecture, they understand TVK architecture. Kubernetes Native also means that the TrilioVault application can be run and supported on any Kubernetes distribution.
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. TrilioVault provides a means to express the application hooks and the order in which these hooks need to be invoked to accomplish application consistent backups.
TVK 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. TVK 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.
RBAC is built into Kubernetes clusters by design. Since TVK is built on the same principles on which Kubernetes is built, it automatically supports RBAC. TVK can be installed into individual namespaces or the entire cluster. Namespaces are generally the units used for multi-tenancy within Kubernetes.
Another key attribute of TrilioVault for Kubernetes is the format in which the backup is stored. TVK 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.
Open - No hydration required for moving backup data. Scanning of data from a security perspective is also enabled.
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.
The most popular backup target medias are NFS and S3 compatible storage types. TrilioVault supports both these storage types as backup targets.
TrilioVault 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.
All backups, both incremental and full backups will reside on the same backup target as per the configured BackupPlan .
Incremental backups provide both space savings and efficient network bandwidth utilization. TrilioVault 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.
Though TrilioVault 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 TrilioVault supports forever incrementals, it cannot delete all last backups. It will break the backup chain and more recent backups becomes unusable. TrilioVault creates and manages full synthetic backups, where TrilioVault 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 TrilioVault continues to take incremental backups, but still maintains the list of backups according to user retention needs.
TrilioVault 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.
Backup retention is a way to retain backup images that meets your business needs. Business reasons could be compliance, risk tolerance, data analytics, etc. TrilioVault supports retention policies that can be defined to meet your business needs.
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 TrilioVault.
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. TVK 2.0 provides customers 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.
In order to enable seamless Disaster Recovery or migration scenarios, TrilioVault 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.
Trilio supports multi-cloud management (MCM) by allowing users to manage multiple TVK 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.
Velero, formerly known as Heptio Ark was one of the first solutions that was developed and offered as a backup solution in the Kubernetes market. Velero being an open-source solution and being the only solution available in the market back in the day, was adopted by users as they started evaluating Kubernetes and its ecosystem of products for their organizations. New users to the Kubernetes space also leverage Velero from time-to-time from an evaluation perspective or for running business operations within a small scope.
Velero being an open-source solution does not provide enterprise-grade support. Along with that, existing users and Trilio prospects have complained about Velero not supporting a management console for monitoring backups and restores, issues with the technology itself and various other reasons - big and small. As a result, customers adopt Trilio to eliminate issues that they are facing with Velero or to use an enterprise-grade solution as they mature with Kubernetes and move from running in evaluation mode to running in production mode. As customers adopt and migrate their data protection solution to Trilio, they desire a simple way to monitor and visualize their existing data protection landscape that they have with Velero.
Trilio supports monitoring Velero backups, restores and backup/snapshot locations through its own management console via a zero touch setup feature. TVK automatically discovers the Velero landscape running in a cluster and uses its own MCM capability to monitor velero installations across multiple Kubernetes cluster. As a result, customers can easily adopt Trilio while keeping a tab on its existing Velero infrastructure.
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.
