Kubernetes Backup: Protecting Cloud-Native Workloads

The customer who had every node backed up 

The first time I watched a customer try to recover a Kubernetes cluster from their VM backup, I knew the next year of conversations was going to be about explaining why containers do not work the way VMs do. We had to walk through what the backup actually contained, what was missing, and what that meant for their RTO. 

The customer thought they were protected. They had backups of every node in the cluster. They had no way to bring the workload back. The backup captured the underlying VMs running Kubernetes. It did not capture the namespace configuration, the YAML manifests, the ConfigMaps and Secrets, or the etcd state that recorded what should exist. They had the substrate. They were missing the application. 

This piece is what I would tell that team if I could rewind and have the conversation before the incident. 

What Kubernetes backup actually is 

Kubernetes backup is the capture and recovery of containerized applications, their persistent state, and the Kubernetes configuration that defines how they run, in a way that allows the complete workload to be restored to the same cluster, a different cluster, or a different cloud. 

The distinction matters because the workload in Kubernetes is not just the running containers. It includes the persistent volumes (PVs) where stateful applications store data, the namespace where the workload lives, the YAML manifests that define Deployments and StatefulSets, the ConfigMaps and Secrets that carry environment-specific configuration, the Custom Resource Definitions (CRDs) that extend the API, and the etcd state that records what the cluster believes should exist. A backup that captures only the persistent volumes can restore the data but cannot restore the running application. A backup that captures only the YAML manifests can restore the structure but not the state. Both are common. Both are insufficient. 

Adoption of containerized production workloads is no longer hypothetical. Google launches billions of containers per week across its own infrastructure. For most enterprise platform teams, the question is no longer whether Kubernetes workloads need backup but how to architect it correctly. 

Why containers need different backup than VMs 

VMs and containers share enough that some backup principles transfer. Both are virtualized abstractions. Both expose APIs for snapshot operations. Backup data is still backup data regardless of source. A backup platform can reasonably store backups for both in the same vault. 

Operational model differs in 3 ways that matter for data protection design:

1. VM storage persists across shutdowns. Container storage often does not. When a VM shuts down, its allocated storage stays. When a Kubernetes pod shuts down, the kubelet may reclaim its emptyDir volumes and any non-persistent storage.
2. VMs are relatively stable. Pods are transient by design. Kubernetes is built to start, stop, and reschedule pods as a normal operational pattern. Backup that assumes long-lived workloads with predictable schedules does not fit. 
3. VMs run one application. Pods run pieces of applications. A meaningful application boundary in Kubernetes is the namespace or the Helm release, not the individual pod. Pod-level backup fragments the application. 

The five challenges that make Kubernetes backup architecturally different 

Analysts at the Data Center Intelligence Group (DCIG) identified five specific challenges that backup software must solve to protect Kubernetes environments. The framework holds up well and clarifies what differentiates Kubernetes-native protection from backup tools adapted from the VM era. 

1. Ephemeral storage 

When a pod shuts down, Kubernetes can reclaim its storage. The data effectively becomes lost. Two implications for backup: the platform has to know the containerized application exists in the first place (auto-discovery, not manual registration), and backup has to occur during the time the application is running, which may be hours, not days. Backup schedules built around nightly windows do not fit workloads that may not exist tomorrow morning. 

2. Unpredictability 

The kube-scheduler decides where pods run based on resource availability, affinity rules, taints, and tolerations. Not based on operator preferences. A pod may run on any node in any cluster at any time. The backup platform has to follow the workload rather than assuming a fixed location, and it has to make protection decisions per-workload. Not all containers need backup. Some need protection only at specific lifecycle events like pre-shutdown. 

3. Scalability 

A production Kubernetes deployment may run thousands of pods across hundreds of namespaces. Multi-cluster environments push that into the millions. Containers spin up and down at much higher rates than VMs. A backup platform that scales linearly with operator effort, manual registration, manual policy assignment, manual verification, becomes the bottleneck. Kubernetes backup requires cloud-native, dynamically-scaling backup infrastructure that grows and shrinks with the workload. 

4. Breadth: applications plus control plane 

Containerized applications matter, but they are useless without the control plane state that orchestrates them. etcd holds the cluster's source of truth. Which Deployments exist, which ConfigMaps and Secrets are bound to which workloads, which CRDs extend the API, which RBAC rules govern access. Mature Kubernetes shops script the control plane through GitOps and can rebuild it on demand. Less mature deployments rely on the backup platform to capture both layers. 

5. Recovery complexity 

Recovery surfaces all the prior challenges at once. The platform has to identify which backup to restore (date, cluster, namespace, application context), handle interdependencies between containerized applications that may need to come up together, and increasingly, restore into a different Kubernetes deployment than the one that was backed up. Different cluster, different cloud, different K8s version, potentially different distribution (EKS vs AKS vs GKE vs on-prem). The backup platform has to know enough about both source and destination to translate between them. 

What complete Kubernetes backup has to protect 

A complete Kubernetes backup covers four distinct categories. Backup tools vary widely in how many they actually handle. 

The role of container labels and metadata 

Kubernetes provides the protection mechanism the platform needs: labels and metadata attached to every workload. When a container starts, the Kubernetes node service reads its existing metadata, adds key-value pairs that identify which resources belong together, and exposes those labels to anything watching the API. 

A well-designed backup platform watches container start-ups and reads metadata in real time. The labels tell the platform what to back up (the workload meets policy criteria), when (according to the policy bound to those labels), and how (which related resources need coordinated capture). The platform can then schedule backup jobs through kube-scheduler integration, letting Kubernetes itself decide where the backup work runs the same way it decides where pods run. 

This pattern is different from the operator-driven model legacy backup uses. In the legacy model, a human or a configuration file declares what to back up. In the Kubernetes-native model, the workload declares itself through its labels and the backup platform responds. New workloads get protection automatically. Retired workloads stop generating backup load. The operator's job becomes setting policy, not managing inventory. 

Cross-cluster recovery and multi-cloud Kubernetes 

Single-cluster recovery (restore the workload to the same cluster it came from) is the simple case. Most enterprise Kubernetes deployments do not stay in the simple case for long. Three real-world scenarios backup platforms now need to handle. 

Workload migration between EKS, AKS, GKE, and on-prem distributions. Cluster lifecycle decisions (cost optimization, region changes, distribution preferences) regularly require moving workloads. Backup that supports cross-distribution restore turns these migrations from multi-week projects into routine operations. 

Disaster recovery to a different region. When the primary region fails, the recovery workload comes up in a different region's cluster, ideally with the same backup data, same policies, and same management plane the operations team uses day-to-day. 

Test and dev environment cloning. Restoring production workloads (with synthetic data or sanitized data) into test clusters is a common requirement for accurate pre-production testing. The same cross-project, cross-region restoration mechanism that supports DR also supports environment cloning. 

Common Kubernetes backup mistakes 

The Kubernetes data protection market is full of products that look adequate in a feature matrix and fail on contact with production complexity. Three patterns to watch for. 

Mistake 1: Persistent-storage-only backup 

Many "Kubernetes backup" tools capture PV snapshots and call themselves complete. PV snapshots are necessary but not sufficient. Without namespace configuration, YAML manifests, ConfigMaps, Secrets, and operator-defined custom resources, the recovered persistent volumes are data without context. Storage-only backup is a useful primitive. It is not a Kubernetes backup strategy. 

Mistake 2: Bolt-on plug-ins to legacy backup products 

When existing backup vendors added "Kubernetes support" in 2019-2021, many shipped plug-ins that adapted their VM-era architecture to call Kubernetes APIs. The result usually treats containers as a separate workload requiring separate infrastructure, creating exactly the siloed data protection the move to Kubernetes was supposed to eliminate. As Krista Macomber of Evaluator Group has noted in her primer on Containers Data Protection Fundamentals, treating Kubernetes as a bolt-on rarely produces the operational model platform teams expect. 

Mistake 3: Missing the control plane 

GitOps shops that rebuild their control plane from source control on demand can skip control plane backup safely. Most Kubernetes deployments are not GitOps-pure. The cluster has accumulated configurations applied manually, operators installed through kubectl, CRDs not in source control, and Secrets that were never committed (correctly so). Lose etcd, and the cluster's history of what was deployed is gone. Either control plane backup is part of the protection strategy, or operational discipline around GitOps is. Not neither. 

Common questions on Kubernetes backup 

Do stateless workloads need backup? 

Stateless workloads do not have application data to back up, but they have configuration (Deployments, ConfigMaps, Service definitions, Ingress rules) worth capturing. If the namespace is destroyed, restoring stateless workloads from container images is fast, but only if you have the configuration manifests handy. Most teams realize this the second time they have to recreate a Service from memory after a cluster incident. 

What about CSI snapshots? 

CSI snapshots are a useful primitive the backup platform should use under the hood. They capture point-in-time copies of persistent volumes at the storage layer. But CSI snapshots alone are not a backup strategy. They are tied to the storage backend, do not capture namespace configuration, do not move between clusters without additional tooling, and typically share fate with the cluster they live in (lose the cluster, lose the snapshots). A backup platform that orchestrates CSI snapshots and captures the rest of the workload is the right pattern. 

Can I restore a backup from one Kubernetes distribution to another? 

It depends on the backup platform. Distributions vary in their API extensions, default ingress controllers, storage classes, and security defaults. A platform that captures the workload at the Kubernetes object level (Deployments, Services, PVCs) and translates target-specific configurations during restore can move workloads between EKS, AKS, GKE, and on-prem clusters with manageable effort. A platform that captures storage snapshots at the cloud provider level cannot. The snapshots are tied to the provider. 

Where to start 

If you protect Kubernetes today, run a tabletop exercise this quarter. Take your most critical containerized application. Walk through how you would recover it to a different cluster, in a different region, with the cluster you came from no longer available. If anyone on the team uses the word "manually" during the walkthrough, you have found your gap.