Protecting Persistent Data on Kubernetes with Veeam Kasten

When Kubernetes first started gaining traction, most workloads were designed to be stateless. Applications could scale in and out easily, and if a container went down, it didn’t really matter—another one would spin up, and everything kept running.

But things have changed. Today, more and more solutions are running on Kubernetes with persistent data. Think of databases, message queues, or analytics tools—these workloads need their data to survive even if the container or node disappears. That’s where backup and recovery become critical.

The Challenge with Persistent Data on Kubernetes

Kubernetes does a great job at managing applications, but when it comes to protecting persistent data, it doesn’t provide a built-in backup solution. Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) give applications stable storage, but what happens if the storage itself is corrupted, deleted, or lost due to human error?

This is a big risk for organizations adopting Kubernetes at scale. Losing data is not an option, and while Kubernetes is excellent at high availability, it isn’t a replacement for proper backups.

Using Veeam Kasten to protect persistent data

Kasten is a backup and disaster recovery solution built specifically for Kubernetes. It integrates directly with Kubernetes APIs and makes it simple to:

• Back up persistent volumes and associated Kubernetes resources.
• Restore data in case of accidental deletion or corruption.
• Migrate applications and data between clusters or cloud providers.

The beauty of Kasten is that it understands Kubernetes as a whole—so it doesn’t just back up raw storage, it also captures the application metadata, namespaces, secrets, and configurations that make your app run.

Setting Up Veeam Kasten on Kubernetes in Azure

Depending on what kind of virtualization platform or cloud provider you are using, the approach is a bit different, since it requires some different integrations. The simplest approach is to use helm to install it using a service principal in Azure.

NB: This requires you to have a precreated app registration in Azure and fetch some information there including the application ID & directory ID.

After you have done that, run this helm commands and it will automatically install itself into a new namespace called “kasten-io”

helm install k10 kasten/k10 --namespace=kasten-io \

--set secrets.azureTenantId=<tenantID> \

--set secrets.azureClientId=<azureclient_id> \

--set secrets.azureClientSecret=<azureclientsecret>

While Kasten is now deploying the pods you can follow on the progress of the installation by using this command

kubectl get pods --namespace kasten-io --watch

By default, the Kasten K10 dashboard isn’t exposed outside the cluster. To reach it, you can forward a local port to the Kasten service with this command:

kubectl --namespace kasten-io port-forward service/gateway 8080:80

After running it, open your browser at the following address and you will access the dashboard.

 http://127.0.0.1:8080/k10/#/

Where we will need to enter some information before accessing the configuration

Once you logged into the Dashboard, Kasten will show all applications (that are directly mapped to namespaces within Kubernetes). Kasten also classifies Pods, VirtualMachines, StatefulSets, Deployments and DeploymentConfigs as workloads.

Unmanaged applications are services within namespaces that do not have a backup policy defined yet.

Location and Infrastructure Profiles in Kasten

Kasten makes Kubernetes data protection pretty straighforward by using modular, declarative configurations. Two of the most important building blocks are:

• Location Profiles
• Infrastructure Profiles

A Location Profile tells Kasten where to send your backup data. This is usually an external object storage location, for example:

• AWS S3
• Azure Blob Storage
• Google Cloud Storage

With a Location Profile, you define the target once, and Kasten will use that as the default storage location and will handle the data transfer. For Azure, a native blob storage account must be pre-created, along with a container within it.

Once you have that in place you just enter the name of a storage account and a primary access key that it should use to authenticate with.

 

Then we have Infrastructure Profiles. Infrastructure Profile defines how Kasten should handle snapshots for your storage classes or volume providers. In other words, it’s the configuration that tells Kasten how to talk to your infrastructure’s snapshot APIs.

This could be:

• Cloud-native snapshot APIs (like AWS EBS, Azure Managed Disks, or GCP Persistent Disks)
• CSI snapshot drivers (Container Storage Interface)

Like with most cloud based deployments the best approach is to use the CSI snapshots drivers provided by the cloud provider. Such as with Azure, Kubernetes ships with its own CSI drivers for the different storage services so this is automatically in place as part of the install.

Now that we have both a location and infrastructure profile in place we can set up a protection policy for our applications.

In Kasten, you can create a new policy from either the Policies page or the Applications page. If you start from the Applications page, some fields (like the policy name and namespace) will already be pre-filled for you.

Here’s how to do it from the Applications page:

• Go to the Applications page by clicking on the Applications card on the main dashboard, or by using the Applications link in the sidebar.
• Find an unmanaged application in the Applications table.
• Open the menu and choose Create a Policy.

Then we need to define a schedule,

Snapshots are the foundation for how Veeam Kasten captures data. Most of the time, they’re tied to disk volumes (PVC/PVs). In the cloud (AWS, Azure, Google Cloud), snapshots get stored in object storage, which means they stick around even if the original volume is deleted.

Backups take things a step further. They turn snapshots from apps and volumes into a format that isn’t tied to any one infrastructure, and then save them to a backup location of your choice.

If you want snapshots to be turned into backups automatically, just turn on Backups via Snapshot Exports when you set up a policy.

Once you are done with the backup policy creation wizard, the backup will start based upon the defined schedule or you can trigger one manually directly in the dashboard.

To trigger a restore operation of an application that has been backed up, go into the dashboard and select the application from the list and clicking Restore

The wizard will show different restore points that you can select from.

When you hit Restore, Kasten will bring back the whole application stack in the namespace you choose. That means not just the app’s data, but also the container images with their versions.

Summary

This blog post highlights the increasing need for robust data protection strategies in Kubernetes environments, especially as more stateful applications with persistent data are being deployed. While Kubernetes excels at high availability, it lacks built-in backup for Persistent Volumes (PVs) and Persistent Volume Claims (PVCs), making solutions like Veeam Kasten essential. Kasten provides a Kubernetes-native approach to backing up, restoring, and migrating applications and their associated data, configurations, and metadata.

from StarWind Blog https://ift.tt/VIEpGWC
via IFTTT