Backing Up a Small Cluster: etcd and Manifest Backups

Your cluster state lives in etcd — the control plane database holding every Deployment, Service, ConfigMap, Secret, and more. On a single node, losing the disk can mean losing all of it. A small cluster needs two complementary backups: an etcd snapshot capturing all cluster state, and a manifest export of the resources you care about, so you can rebuild even if the snapshot is unusable.

Backing up etcd with k3s

k3s wrappers etcd operations so you can snapshot without gymnastics. Run this on the node to write a timestamped snapshot, then copy it off-box.

sudo k3s etcd-snapshot save --name post-test
sudo k3s etcd-snapshot ls
# copy it to safe storage:
scp /var/lib/rancher/k3s/server/db/snapshots/* post-test /backup/host/

Schedules can automate this, but a manual snapshot plus off-box copy is a fine start.

Backing up manifests

A manifest export gives you readable, restorable definitions and records what you intended to run.

kubectl get all -A -o yaml > cluster-all.yaml
kubectl get configmaps,secrets -A -o yaml > cluster-config.yaml
kubectl get pvc -A -o yaml > cluster-pvc.yaml
# take inventory of custom resources and namespaces too:
kubectl get namespaces -o yaml > namespaces.yaml

Restoring etcd from a snapshot

Restoration rebuilds the control plane from the snapshot on a fresh or repaired node. k3s peels the snapshot and rewrites etcd before starting the API.

sudo k3s server   --cluster-init   --etcd-snapshot-restore /backup/post-test-snapshot-etcd

The backup strategy in one picture

Two backup kinds, one caveat

The etcd snapshot restores cluster definitions fast. But PersistentVolume contents live on the node disk, not in etcd — you must back those up separately if the data matters. For each important PVC, back up the underlying directory or run app-level backups (like a database dump).

# example: dump an app database and move it off-box
kubectl exec deploy/db -- pg_dumpall > db-dump.sql
scp db-dump.sql /backup/host/

Think beyond the cluster

The cluster is configuration; your actual data is separate. Redundancy only counts when backups live outside the node itself, so a disk failure cannot take both the cluster and its backup with it.

Takeaway

Back up a small cluster twice: an etcd snapshot for fast full recovery and a manifest export for readable rebuilds — then copy both off the node. Back up PVC data separately, because etcd does not hold file contents. Set the habit on your k3s VPS at Netbay so a disaster is a restorable event, not a starting-over moment — netbayhosts.in.