Kubernetes backup: protecting the four layers properly

Have backup and recovery set up dependably in your cluster? WZ-IT plans, builds and operates Kubernetes clusters including backup, restore tests and defined recovery objectives - on Proxmox, bare metal and European infrastructure. See Managed Kubernetes

"But we have snapshots" is the most common misconception about Kubernetes backup. A snapshot captures a point in time of a disk - but a cluster consists of several layers that must be protected separately. This guide shows the four layers of a complete backup, which tools cover which, and why in the end only the tested restore counts. As of July 2026.

Table of contents

• Why a snapshot is not a backup
• The four layers to protect separately
• Layer 1: etcd, the cluster state
• Layers 2 and 3: resources and volumes with Velero
• Layer 4: application-consistent database backups
• The tested restore is what counts

Why a snapshot is not a backup

A VM or volume snapshot is valuable, but it answers only one of several questions. It captures a point in time of the disks - but not automatically a consistent state of the control plane, the versioned definition of the cluster or a transactionally clean database. And it does not protect against the most common causes of loss: accidental deletion, a faulty deployment or ransomware are, with pure replication, even replicated along with the data.

A dependable backup therefore protects several layers separately and stores them on a dedicated path and target. That separation is exactly the difference between "we have snapshots" and "we can restore the cluster".

The four layers to protect separately

A complete Kubernetes backup covers four layers, each needing its own tools and cadence:

1. etcd - the entire state of the cluster (relevant only for self-hosted).
2. Cluster resources - the objects that describe the desired state (Deployments, Services, ConfigMaps, Secrets).
3. Persistent volumes - the applications' actual data.
4. Application-consistent databases - a transactionally clean state of the database contents.

Anyone backing up only one of these layers has not a backup but a partial aspect. Below, what each layer covers and with what.

Layer 1: etcd, the cluster state

etcd is the control plane's database and holds the complete state of the cluster. If it fails irrecoverably, the cluster is lost - even if all nodes are running. For self-hosted clusters, a regular etcd snapshot (etcdctl snapshot save) is therefore the basis of any recovery; the Kubernetes documentation describes backing up and restoring it.

With managed Kubernetes services the provider handles this layer. With self-operated clusters - the norm on Proxmox or bare metal - it is your responsibility and is often overlooked during setup.

Layers 2 and 3: resources and volumes with Velero

Velero is the established tool for the two middle layers. It backs up Kubernetes resources (cluster objects queried via the API) and persistent volumes to object storage, runs on a schedule, can restore selectively and migrate whole applications between clusters.

Velero thus covers the desired state (layer 2) and the payload data (layer 3) in one tool - including CSI snapshots of the volumes. The target matters: the backup storage (S3-compatible) must live separately from the cluster so that a cluster failure does not take the backup with it. Storage systems such as Longhorn add their own incremental backups of the volumes to NFS or S3.

Layer 4: application-consistent database backups

The layer where most concepts fail: a volume snapshot of a running database is not necessarily consistent - it can be taken mid-transaction. A reliable restore needs application-consistent backups: native dumps (pg_dump, mysqldump) or the database's own backup tool, triggered in a clean state.

Velero can orchestrate these steps via pre and post hooks so that the snapshot is taken at a consistent point in time. What matters is planning this layer deliberately - it is not covered by the layer 3 volume backup.

The tested restore is what counts

Backing up all four layers helps little if no one has verified the recovery. The most common critical finding when taking over inherited clusters is a never-tested restore: backups exist, but no one has ever performed a full recovery. A backup that was never restored is a guess in an emergency, not a safety net.

A dependable concept therefore tests a full restore of the critical layers - including the database - at least once per quarter, and adapts the recovery objectives (RPO, RTO) to business criticality. How this point feeds into the assessment of an existing cluster is shown in the takeover audit; which storage system carries the volumes is placed by Longhorn vs. Rook-Ceph.