How to Restore the Kubernetes etcd Data in an NSP Cluster

Learn how to restore the Kubernetes etcd data in an NSP cluster step-by-step with real commands, quick fixes, and tips to bring your cluster back fast. Our Kubernetes Live Support Team is always herte to help you.

When a Kubernetes control plane stops responding or a cluster state becomes corrupted, the first thing every admin wants to know is how to restore the Kubernetes etcd data in an NSP cluster without losing critical configuration. Since etcd holds the “source of truth” for every pod, node, and service, restoring it safely isn’t optional, it’s survival.

This guide walks you through the exact process, including every command, so you can bring your cluster back even on your worst day. And yes, this is written in a clean, human tone so you can follow it without stumbling through robotic jargon.

Before we begin, remember: you must restore the Kubernetes etcd data in an NSP cluster with careful attention, because one wrong overwrite can take down the entire environment.

What is etcd, and Why Does It Matter?

etcd is the distributed key-value store behind Kubernetes. It keeps everything, cluster configuration, node details, API objects, service definitions, and more. Therefore, if you want a healthy control plane, you safeguard etcd. And when disaster hits, you restore the Kubernetes etcd data in an NSP cluster using a valid snapshot.

Steps

Identify the NSP Backup Pod

First, log in to the NSP host as root or the NSP admin user.
Run:

kubectl get pods -A | grep nsp-backup

You’ll see something like:

nsp-psa-restricted nsp-backup-storage-0 1/1 Running 0 5h16m

Record the namespace value.

Locate the Snapshot

Next, list the snapshot stored inside the backup pod:

kubectl exec -n <namespace> nsp-backup-storage-0 - ls -la /tmp/backups/nsp-etcd/

Look for the file in the format:

nsp-etcd_backup_timestamp.tar.gz

Record the exact filename.

Copy the Snapshot to Your Machine

Use:

kubectl cp <namespace>/nsp-backup-storage-0:/tmp/backups/nsp-etcd/<snapshot_file> <local_path>/<snapshot_file>

Make sure the destination directory is empty.

Collect Cluster Details

Run this on an etcd cluster node:

grep ETCD_INITIAL /etc/etcd.env

You’ll see lines like:

ETCD_INITIAL_ADVERTISE_PEER_URLS=https://local_address:port

ETCD_INITIAL_CLUSTER_STATE=existing

ETCD_INITIAL_CLUSTER_TOKEN=k8s_etcd

ETCD_INITIAL_CLUSTER=etcd1=https://address_1:port,etcd2=https://address_2:port,etcd3=https://address_3:port

Record all values, you’ll need them during the database restore.

Stop etcd on Every Member

Run the following on each etcd node:

systemctl stop etcd

After this point, your etcd cluster will be unreachable until the restore is finished.

Transfer the snapshot file to each member.

Extract and Restore the Snapshot

Navigate to the directory containing the snapshot.

Extract it:

tar xzf <path>/nsp-etcd_backup_timestamp.tar.gz

Restore it:

ETCDCTL_API=3 etcdctl snapshot restore etcd.db --name <member> --initial-cluster <initial_cluster> --initial-cluster-token <token> --initial-advertise-peer-urls <URL>

This step rebuilds the database for the specific member.

Replace Old Database Files

Create a directory to store the old database:

mkdir <path>/old_etcd_db

Move old files:

mv /var/lib/etcd/* <path>/old_etcd_db

Move the new restored files:

mv ./member.etcd/* /var/lib/etcd/

Start etcd and Verify

Start etcd:

systemctl start etcd

Check status:

systemctl status etcd

Make sure you see:

Active: active (running)

Repeat this across all nodes, and your cluster returns to life.

Conclusion

If you follow every step carefully, you can restore the Kubernetes etcd data in an NSP cluster without panic, downtime, or data loss. Moreover, now that you know how to restore the Kubernetes cluster confidently, you’re much better prepared for real-world failures. And lastly, always keep multiple snapshots, because the moment you skip one is the moment you’ll need it.