If you run your own Kubernetes control plane, etcd is the cluster's memory, and a tested etcd snapshot is your cluster backup. The snapshot also holds Secrets, so treat the file like a credential. Managed services often handle this for you, but check what they actually cover.
What etcd holds
etcd stores the state of the cluster: object definitions, configuration, and Secrets. It does not hold your application databases or persistent volume contents. Those need their own backups.
Lose etcd with no snapshot and the nodes may keep running containers for a while, but you cannot change anything, and you have no record of what should be running.
Backup options
The Kubernetes documentation lists three approaches: a built-in snapshot, a volume snapshot, and a snapshot using etcdctl options. It says that if etcd is your backing store, you should have a backup plan for that data. It also recommends a five-member cluster in production and periodic backups.
Pick based on how you run etcd:
- Built-in snapshot, taken from a running member, is portable and simple.
- Volume snapshot works when etcd sits on storage that supports consistent snapshots.
- Scripted etcdctl snapshots suit self-managed clusters where you control the schedule.
Treat the snapshot as a secret
A snapshot is a copy of everything the API server knows. If Secrets are encrypted at rest, you also need the encryption configuration and its keys to read them after a restore. Store those separately from the snapshot, and test that you can find them without the cluster being alive. The same lesson applies to backup encryption keys.
Limit who can read the backup bucket. Turn on versioning and a retention lock so an attacker with cluster access cannot delete your recovery path. See immutable versus offline backups.
Restore is a different tool
The same documentation notes that etcdutl works on data files, including restoring snapshots, while etcdctl is for network operations. Check the page for the commands that match your etcd version. It lists 3.4.29 and 3.5.11 as minimum recommended production versions.
Plan the restore as a rebuild:
- Stop the API servers.
- Restore the snapshot into a fresh data directory.
- Start etcd, then the control plane.
- Check that nodes rejoin and workloads match what you expect.
Prove it with a drill
A snapshot you have never restored is a guess. Once a quarter, restore into a scratch cluster, then list namespaces and deployments and compare them with production. Record how long it took. That number is your real recovery time, which you can compare with the target from setting RPO and RTO.
Also keep your manifests and infrastructure code in version control. Rebuilding from code is often faster than restoring state, and it catches drift.
If you want to see what is in your clusters and images before you plan recovery, Safeguard offers asset discovery and a free scan at https://gold.safeguard.sh/scan.
Quick check
Does an etcd snapshot back up my databases?
No. It holds cluster state only. Application data on persistent volumes and in databases needs separate backups.
Why is the snapshot sensitive?
It contains cluster state including Secrets, so anyone who can read it may recover credentials.
Sources
Last reviewed: 19 October 2026.
