Features

A list of impactful TrilioVault for Kubernetes features and use cases

Feature List

Operator and Helm based Deployment

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:

  1. Helm based Operator

  2. Operator Lifecycle Management Operator

TrilioVault can be deployed and managed using these tools.

Application Types supported

TrilioVault provides an innovative approach to backup applications based on:

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

  2. Operators - Operators are meant to manage the install, updates and life cycle of applications. TrilioVault 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. TrilioVault for Kubernetes supports namespace based backups as well.

Kubernetes-native

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

Ecosystem Integration

Prometheus

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.

Role Based Access Control (RBAC)

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.

Open Backup Format

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.

  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. TrilioVault supports both these storage types as backup targets.

Multiple 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 Forever

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.

Full Synthetic Backups

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.

Hooks

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

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.

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

Restore Tranforms

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.

Target Browser

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.