Hands-on Lab·Certified Kubernetes Administrator
etcd Backup and Restore
Take a snapshot, create something after it, then restore and watch that thing cease to exist. Done on a real single-node cluster, including the three details that decide whether the restore comes back up: a version-matched binary, the member identity flags, and stopping the control plane first.
Cluster Architecture and Configuration Guide 24 of 103 Advanced
- Kubernetes1.36.4
- Cluster1 node
- etcd3.6.8
- Runtimecontainerd 2.2.6
- TimeAbout 55 min
- Reviewed21 August 2026
Written against the versions above. etcd 3.6 moved snapshot status and restore out of etcdctl. Guides written against 3.5 will not work here.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA4001 | 192.168.0.191 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
Before you start
- A kubeadm cluster you are willing to break, and root on its control plane node. Use a single-node lab, not anything you care about.
- The control plane guide. This guide moves static Pod manifests and assumes you know why that stops a component.
- A VM snapshot or equivalent escape hatch. A restore that goes wrong leaves you with no API server.
-
First problem: there is no etcdctl on the node
-
A quirk worth knowing before it bites you
-
Talk to etcd, and drop a habit from every older guide
-
Take the snapshot
-
Create something after the snapshot, so the restore is provable
-
Restore, part one: build a new data directory offline
-
Restore, part two: stop the control plane
-
Restore, part three: swap the directory and restart
-
Proof: the canary is gone