Setting Up Veeam Kasten for Kubernetes: A Complete Guide

What Kasten Is and Why It's Different

Veeam Kasten (formerly Kasten K10) is Veeam's Kubernetes-native data protection platform. It is a completely separate product from Veeam Backup and Replication. Where VBR protects virtual machines, physical servers, cloud workloads, and NAS, Kasten is built specifically for the Kubernetes application model: it understands namespaces, persistent volume claims, StatefulSets, Deployments, Helm releases, and the relationships between them.

Protecting Kubernetes workloads with VBR agents or generic backup tools misses the point of the Kubernetes model. An application in Kubernetes is not a single entity -- it is a collection of resources: Deployments, Services, ConfigMaps, Secrets, PersistentVolumeClaims, and often custom resource definitions specific to the application's operator. Restoring a Kubernetes application means restoring all of these resources in the right relationships, not just copying files off a persistent disk. Kasten understands this. A Kasten backup is a restore point for an entire application, not just its data.

The current version at the time of writing is Veeam Kasten 8.5.4, and this article is written against that version. Kasten releases frequently. Always check the release notes before installing or upgrading.

Architecture: How Kasten Protects Kubernetes Applications

Kasten installs as a set of pods in a dedicated namespace on your Kubernetes cluster (default: kasten-io). Once installed, it auto-discovers all applications running in the cluster by enumerating namespaces and identifying workloads with persistent storage.

The core backup flow has two layers:

CSI Volume Snapshots: Kasten's preferred and recommended method is to use the cluster's Container Storage Interface (CSI) driver to create volume snapshots of Persistent Volume Claims. The CSI driver creates a crash-consistent point-in-time snapshot of each PVC. This is fast and storage-efficient. The snapshot can then be exported to an external object storage location (the Location Profile) to produce a durable backup copy outside the cluster.

Generic Storage Backup: For storage without CSI snapshot support, Kasten can perform a file-copy-based backup by mounting the volume and streaming data to the export location. This is called Generic Storage Backup and is significantly slower than CSI snapshots. Importantly, as of Kasten v6.5.0, Generic Storage Backup is disabled by default for all new and upgraded deployments. If your storage requires it, you must explicitly enable it. CSI with snapshot support is the right long-term path.

Kanister Blueprints: For stateful applications that require application-level quiescing before a backup (databases are the canonical example), Kasten integrates with Kanister. Kanister is an open-source framework for application-specific data management actions. A Kanister Blueprint defines the pre-backup, backup, and post-backup actions for a specific application type. Kasten ships built-in blueprints for common databases. Custom blueprints can be written for any application.

Location Profiles: The external storage destination where Kasten exports backup data. Kasten supports S3, S3-compatible object storage, Azure Blob Storage, Google Cloud Storage, NFS, SMB, and Veeam Backup Repository targets. Kasten creates a Kopia repository in the object storage location, which provides deduplication, compression, and encryption of backup data at rest.

Prerequisites and Requirements

Step 1: Add the Helm Repository and Run Pre-flight Checks

Add the Kasten Helm chart repository to your Helm client:

helm repo add kasten https://charts.kasten.io/
helm repo update

Before installing, run the Kasten primer tool to validate that your cluster meets all requirements. The primer tool deploys a temporary pod into the cluster, validates Kubernetes settings, catalogs available StorageClasses, and performs CSI capability checks:

curl https://docs.kasten.io/downloads/8.5.4/tools/k10_primer.sh | bash

For air-gapped environments, use the air-gapped primer variant. Review the primer output carefully. Pay particular attention to the CSI section -- if your storage class does not show VolumeSnapshot support, that is the most important gap to address before proceeding. A Kasten installation without CSI snapshot support will use Generic Storage Backup, which is disabled by default and significantly less capable.

Step 2: Install Kasten via Helm

Create the kasten-io namespace and install Kasten. Kasten must be installed in a dedicated namespace. Do not install it into the default namespace or any application namespace.

kubectl create namespace kasten-io

Basic install with token authentication and an external load balancer for dashboard access:

helm install k10 kasten/k10 \
  --namespace=kasten-io \
  --set auth.tokenAuth.enabled=true \
  --set externalGateway.create=true \
  --set global.persistence.storageClass=<your-fast-storageclass>

Replace <your-fast-storageclass> with the name of a storage class backed by fast storage. If your default storage class is already SSD-backed, you can omit that flag. If you are not exposing the dashboard via a load balancer (for example, in a private cluster), omit externalGateway.create=true and use port-forwarding for dashboard access instead.

Step 3: Validate the Installation

Watch the pod startup in the kasten-io namespace. All pods should reach Running status within a few minutes:

kubectl get pods --namespace kasten-io -w

You will see pods for Kasten's component services including catalog-svc, auth-svc, aggregatedapis-svc, executor-svc, gateway, and others. All should show Running with their expected container count. If any pods remain in Pending or CrashLoopBackOff after five minutes, check pod events with kubectl describe pod <pod-name> -n kasten-io to identify the cause before proceeding.

Step 4: Access the Dashboard

If you installed with externalGateway.create=true, retrieve the external IP assigned to the gateway service:

kubectl get svc gateway-ext --namespace kasten-io

The dashboard is accessible at http://<EXTERNAL-IP>/k10/#/.

If you did not create an external gateway, use port-forwarding:

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

Access the dashboard at http://127.0.0.1:8080/k10/#/.

With token authentication enabled, generate a token to log in:

kubectl --namespace kasten-io create token k10-k10 --duration=24h

On first login, Kasten presents a company name and email acceptance screen. Complete this to activate the product and access the dashboard. The dashboard will immediately begin discovering applications in the cluster.

Step 5: Apply a License

Kasten operates in a free tier for clusters with up to 5 worker nodes. For larger clusters, apply your Enterprise license from the Kasten dashboard under Settings > Licenses. Paste the license key obtained from Veeam or your reseller. The license is applied immediately and does not require a pod restart.

Step 6: Configure a Location Profile

A Location Profile tells Kasten where to export backup data outside the cluster. Without a Location Profile, Kasten can take local CSI snapshots but cannot export them -- meaning your backups exist only within the cluster and are lost if the cluster is lost. Always configure at least one Location Profile before creating backup policies.

In the dashboard, navigate to Settings > Profiles > Location and click New Profile. Choose your storage type:

Amazon S3 or S3-compatible: enter the access key, secret, region, and bucket name. If the bucket has Object Lock enabled, toggle Enable Immutable Backups. For on-premises S3-compatible storage (MinIO, Ceph RGW, etc.), you will also need to specify the endpoint URL and can optionally disable SSL verification for internal endpoints with self-signed certificates.

Azure Blob Storage: enter storage account credentials and container name. Azure Federated Identity is supported for OpenShift on Azure. Veeam Data Cloud Vault (Azure) is a first-class location type for organizations using Veeam's managed cloud storage offering.

Google Cloud Storage: provide a GCS bucket name, region, and service account credentials in JSON or PKCS12 format. Google Workload Identity Federation is supported for clusters running on GKE.

Veeam Backup Repository: if your organization runs Veeam VBR, Kasten can export backups directly to a VBR repository. This is covered in more detail in the VBR integration section below.

Step 7: Create Backup Policies

Backup policies define what gets backed up, how often, where backups are exported, and how long restore points are retained. Kasten's policy model is application-centric: each policy targets one or more namespaces (or label selectors across namespaces), and Kasten protects the complete application within each selected namespace.

Navigate to Policies in the dashboard and click Create New Policy.

Step 8: Configure Kasten Disaster Recovery

Kasten Disaster Recovery (KDR) protects the Kasten installation itself. If the cluster running Kasten is lost, KDR allows you to restore the Kasten configuration, policy definitions, and restore point catalog to a new cluster. Without KDR configured, a cluster loss means starting Kasten from scratch with no knowledge of previous backup history.

From Kasten v8.0 onward, Quick DR mode is the default for all new installations. Quick DR uses a local CSI snapshot of the Kasten catalog PVC as the primary recovery mechanism, combined with the external Location Profile for the cluster-independent copy. This is the recommended mode for all clusters where snapshot-capable storage is available.

Configure KDR from the Kasten dashboard under Settings > Veeam Kasten DR. Select the Location Profile that will store the KDR backup. This should be a location outside the cluster being protected. Use a different bucket or container from your application backup location to keep KDR catalog data separate and clearly identifiable.

Restore Operations

Kasten provides several restore paths from the dashboard under Applications > Restore.

In-place restore restores the selected application namespace to a chosen restore point on the same cluster. This overwrites the current state of the namespace with the restore point. Use this for recovering from data corruption or accidental deletion within the same cluster.

Cross-namespace restore restores the application to a different namespace on the same cluster. Useful for recovering to an isolated environment for investigation without touching the production namespace.

Cross-cluster restore imports a restore point from an external Location Profile and restores the application to a different Kubernetes cluster. This is the primary disaster recovery restore path. The destination cluster must have Kasten installed and a compatible storage class available. Kasten handles remapping storage classes, network services, and ConfigMaps as part of the restore process.

During any restore, Kasten presents the restore point contents: the Kubernetes resource definitions, PVC data, and any application-specific data captured by Kanister blueprints. You can review what will be restored before confirming. Kasten also supports selective restore: restoring specific PVCs or resource subsets from a restore point rather than the entire application.

Kanister: Extending Kasten for Stateful Applications

CSI snapshots are crash-consistent by default. For databases and other applications with in-flight transactions, crash-consistency means the application must run its recovery process when it starts from the snapshot, which works for most databases but may result in some transaction loss and extended startup time. For applications where that is not acceptable, Kanister Blueprints provide application-aware backup orchestration.

A Kanister Blueprint defines a set of actions that run before and after the Kasten backup. For a PostgreSQL database, the pre-backup action might flush WAL buffers and checkpoint the database. For MongoDB, it might trigger a consistent backup via the mongodump utility. For Elasticsearch, it might call the native snapshot API. The Blueprint runs these actions inside the application pod via kubectl exec, then signals Kasten to proceed with the snapshot, then runs post-backup cleanup actions.

Kasten ships ready-to-use Blueprints for PostgreSQL, MySQL, MongoDB, Cassandra, Elasticsearch, and several other common databases and stateful applications. The Kanister project also maintains a community repository of Blueprints for additional applications. Blueprints are Kubernetes custom resources applied to the cluster before being assigned to a Kasten policy.

Kasten and Veeam VBR Integration

If your organization runs Veeam Backup and Replication alongside Kasten, the two products integrate directly. Kasten can export backup data to a VBR repository, and those backups appear in the VBR catalog alongside your VM and workload backups. This allows consolidated reporting, a single secondary storage target, and uniform retention management across VM and Kubernetes workloads from VBR.

To configure the integration, first set up the Kasten cluster as a protected workload in VBR using the Veeam Kasten Integration Guide in the VBR help center. Then create a Location Profile in Kasten of type Veeam Backup Repository, pointing to your VBR backup server. From that point, Kasten policies can target the VBR repository as their export destination.

A recent v8.5 improvement: backups exported from Kasten to a VBR repository now include Kubernetes application metadata captured by the policy. This metadata makes the backups more queryable and reportable from the VBR side without requiring policy changes on the Kasten side.

Key Caveats and Limitations