Learn Veeam - Kasten K10 & Kubernetes

#Introduction

We've secured VMs, databases, and SaaS. There is one modern layer that is often forgotten: Kubernetes. Containers are ephemeral, but their data (PersistentVolumes) is not — and losing a PV means losing a database, a message queue, or the files of a stateful app. In episode 12 we cover Kasten by Veeam (K10), the Kubernetes backup & DR solution that is now part of the Veeam Data Platform.

K10 answers a question that neither etcd nor cloud snapshots can: how do you correctly back up and restore a complete stateful application — deployments, ConfigMaps, PVCs, and their data?

#Why Kubernetes Needs Dedicated Backup

#Containers Are Ephemeral, Data Is Not

Pods can die at any time and be replaced by new instances — that's normal. But PersistentVolumes (PVs) hold data that must survive. The K8s backup problem is not just copying files:

Application state is scattered — deployments, services, PVCs, secrets, and storage data are fused into a single application unit.
Multi-resource consistency — a backup must capture all interdependent resources at one point in time.
Provider-specific PVs — EBS, GPD, AzureDisk, NFS — each type needs a different snapshot mechanism.

#What K10 Protects

K10 protects at the namespace and application levels:

Namespaces — all resources inside them.
PersistentVolumes — data on storage (via CSI snapshots or kanister restore).
Applications — resource groups (deployment + PVC + config) as a single restore unit.

#Kasten K10: Concepts and Policies

#K10 Architecture

K10 runs inside the cluster as a set of deployments (kanister), managed through a web dashboard. Its main components:

Action — backup, restore, export, migrate, delete.
Blueprint — understands an application's "structure" (stateful vs stateless) to choose the right snapshot strategy.
Policy — scheduled rules + retention that determine who, when, and how long data is protected.

#Policy-Based Backup

K10's approach is policies, not manual jobs:

Example backup policy for the prod-db namespace

apiVersion: kio.kasten.io/v1alpha1
kind: Policy
metadata:
  name: db-backup-policy
spec:
  frequency: "@daily"
  retention:
    daily: 14
  actions:
    - action: backup
      name: backup
      target:
        kind: BackupLocation
        name: my-s3-location

Every executed action (by schedule or manually) is called a Run. The K10 dashboard shows all runs, restore points, and their statuses.

#Restore and Migration

K10 can restore to the same cluster or migrate/export to another cluster — including cross-cloud (EKS → GKE). This provides full DR for Kubernetes workloads: back up in one cluster, come back to life in another.

Tip

Use CSI snapshots (a StorageClass whose CSI driver supports snapshots) so PV backups are efficient — block-based snapshots are faster and less disruptive to workloads than file-level backups. K10's default configuration already uses CSI when available.

#Integrating K10 with Veeam B&R

Veeam v13 integrates K10 with VBR on two layers:

Repository — K10 can write backups to a VBR repository (e.g. the same object storage), so a single storage pool serves VMs, databases, and K8s.
Cross-platform restore — K10 restore points can be viewed and restored from the Veeam Data Platform console, giving one dashboard for all workloads.

Unified Veeam Data Platform

VBR (VM/DB/M365)  +  K10 (Kubernetes)  ──▶ One console / one repository

#Real-World Use Cases

Stateful apps on EKS/GKE/K8s — databases, Redis, Kafka, ML pipelines.
Cluster disaster recovery — full application namespace restores to a DR cluster.
Testing/development — cloning production to a sandbox via migrate.
Compliance — per-namespace retention policies for audit.

#Verification

After this episode, make sure:

K10 is installed in the cluster (via the official Helm chart) and the dashboard opens.
One Policy successfully ran its first backup Run.
Restore points appear in the dashboard and in the BackupLocation.
(Optional) Restore test of one namespace to a sandbox cluster.

Warning

Don't assume cloud snapshots (EBS/GPD) are enough for K8s. Cloud disk snapshots don't understand application relationships — restoring a PV without the matching deployment & config produces an application that "exists but is dead". K10 ensures the entire application unit (data + config) recovers together.

#Closing

Key takeaways:

Kubernetes needs application-level backup, not just disk snapshots.
K10 protects namespaces, PVs, and applications in a policy-based way.
Blueprint + Policy + Run is K10's working model.
Cross-cluster restore/migrate (EKS/GKE) enables full DR.
Integration with VBR: one repository, one console in the Veeam Data Platform.

In the next episode, episode 13, we will cover hardening & ransomware protection — least-privilege credentials, TLS/port lockdown, immutable repositories (S3 object lock / hardened Linux repos), as well as Veeam CyberDCR (Ransomware Detection, Malware Detection, Cleanroom Recovery) and alerting. Your backups start getting fortified!