By Murali Balcha | August 2, 2022
If you’re deploying and managing cloud-native applications, then you know there’s no one way to do it. You can define and manage artifacts in a Kubernetes cluster by labels, namespaces, operators, and Helm charts. Among these, Helm has become the gold standard for defining, packaging, installing, and managing the life cycle of cloud-native applications.
One of the most important parts of managing those applications is having a resiliency strategy via backup and recovery operations. But what solutions are out there? And do they offer the support you need, especially if you manage your K8s applications via Helm?
Below, we’ll dig into your options, explain some key concepts to take full advantage of Helm and share how Trilio provides top-notch backup and recovery for Helm applications.
What Backup and Recovery Solutions Exist for Helm Applications?
All backup and recovery solutions in the market today support label and namespace-based applications. But what about Helm and operator-based applications? Supporting these is equally, if not more, important.
Unfortunately, very few solutions support applications managed by Helm and operators. And generic backup methods, such as label-based and namespace-based, don’t help much. They can only offer limited ability to back up and restore your Helm applications.
But good news! You have options. Trilio’s goal is to help you recover applications like they were never restored from the backup target, to begin with. Following this principle, TrilioVault for Kubernetes (TVK) provides full support for Helm applications—with big benefits.
To fully understand those benefits, let’s dive deeper into Helm.
Why Namespace- and Label-Based Backups Fall Short for Helm Applications
Generic approaches like the label or namespace-based backups only back up a collection of resources, losing the application’s soul. They have limited capability to restore such backups and may suffer unforeseen consequences, including disrupting production applications or being unable to restore to an arbitrary cluster or namespace.
But with Helm-based support via TVK, users can:
- Customizing applications during a restore is an essential requirement for disaster recovery.
- Restore to the same namespace or different namespaces.
- Roll back their applications by restoring their revision history.
- Upgrade restored applications using Helm tooling.
Helm Key Concepts
Though TVK has the best possible support for Helm releases, there are a few concepts you should understand to take full advantage of it.
Helm Storage Backend
Helm storage backend holds the application’s installed data, including Helm templates, values, hooks, manifests, secrets, dependency information, and config maps. Helm store only includes the main chart templates, not the sub-chart templates.
The manifests are the rendered templates of the chart and sub-charts using the values. If the Helm chart has sub-charts, you can specify them as dependencies in the chart.
Helm Sub Charts
TVK may change the release name and apply transformations when restoring backups that require rendering the templates again. If your Helm application has sub-charts, then you will need to include their templates.
TVK parses the Charts.yaml and reads the dependencies list. It then fetches the dependency charts from their repositories and stores them on the backup target.
Helm Release Names
Helm allows you to install multiple copies of the same application with different release names in the same namespace.
TVK then provides comprehensive backup and recovery of Helm applications by providing options to rename a release or apply transformations.
How TVK Supports Helm
Now that you understand the concepts and dependencies, let’s take a look at a few ways that TVK supports Helm in different scenarios.
Scenario 1: A Simple, Well-Formed Helm Chart Without Sub-Charts
The Helm chart, including templates and values, is stored in the Helm storage backend. TVK’s backup process saves the Helm chart to the target. Then, the restore operation reads the Helm chart from the backup target and renders it with the new release name and namespace. It will also apply any available transformations and execute the hooks.
The label-based generic backup method cannot modify the release names or change the namespace. It can’t use any transformations and can’t invoke hooks during a restore operation.
Scenario 2: A Well-Formed Helm Chart With Sub-Charts as Dependencies in Chart.yaml Accessible via Kubernetes
Helm only stores the main chart in its backend but does not keep the sub-charts. However, TVK reads the sub-chart dependencies in Chart.yaml during the backup operation and keeps them in the backup target, assuming the sub-charts are accessible by Kubernetes resources.
TVK’s restore function will render templates from the main chart and sub-charts with the new release name and namespace information. It applies any applicable transformations and invokes any registered hooks with the main chart and sub-charts.
TVK’s backup and restore process can handle any level of nested sub-charts.
Scenario 3: A Broken Helm Chart with Sub-Charts That Are Inaccessible from Kubernetes
You can create Helm releases if the sub-charts are accessible locally to the Helm tool—for example if the sub-charts are stored on the local file system or specified as an FTP location that’s only accessible from the Helm tool. The Helm store includes the main Helm chart with Chart.yaml containing references to sub-chart dependencies.
However, TVK can only back up the main Helm chart from the Helm store, but it can’t back up the sub-charts, as they are only available from Kubernetes. Since TVK does not have sub-charts, it can only render main chart templates with new release names and namespaces, but not its sub-charts. That’s why TVK limits the restoration of those applications to the original namespace.
Under this scenario, you can’t restore the application in other namespaces, nor can you specify the transformation.
Backup and Recovery for Your Kubernetes Helm Applications Start Here
Backup and recovery solutions for Kubernetes should support any application, no matter how they’re designed or deployed. Unfortunately, there are many limitations on the market for those of you managing K8s apps via Helm, risking your recoverability and disrupting your business when the unexpected happens.
But with TrilioVault for Kubernetes, you can get full coverage and restoration for your Helm applications. So don’t leave your data protection to chance—learn more about how TVK can help you get the protection you need, hit SLAs, and boost your resiliency. Get started now.
