Why protecting etcd matters
etcd stores the entire state of a distributed system, e.g. in a Kubernetes cluster, that means every workload, configuration, secret, and policy. Its built-in replication handles partial failures well, but it has limits:
- Quorum loss: If too many nodes fail at once, etcd cannot recover without external intervention. Without a snapshot, the cluster state is gone.
- Logical corruption: A bad write, a botched upgrade, or a misconfigured operator can corrupt cluster state in ways that replication spreads rather than prevents.
- No point-in-time recovery: etcd does not natively provide a way to roll back to an earlier known-good state. Without snapshots, there is no recovery point to return to.
For any system that relies on etcd, an independent backup is the last line of defense.
What happens when etcd is lost?
In a Kubernetes cluster, losing etcd without a backup means losing everything the API server knows about: deployments, services, secrets, namespaces, RBAC policies, and custom resources. The underlying workloads may still be running, but the cluster cannot manage, schedule, or recover them.
Rebuilding from scratch takes time and risks missing configuration that was never captured in source control. A Plakar snapshot lets you restore the cluster to a known state instead.
How Plakar protects etcd
Plakar connects to one or more etcd nodes, takes a consistent snapshot of the cluster, and stores it in a Kloset — encrypted, deduplicated, and independent of the cluster itself.
Snapshots can be stored on any supported backend: local storage, S3-compatible object storage, SFTP, or cold storage. Because Plakar snapshots are immutable, they remain intact even if the cluster or its storage is compromised.
Restoring etcd from a Plakar snapshot uses the standard etcdutl recovery workflow. Plakar retrieves the snapshot from the Kloset store and writes it to disk, from where the native etcd tooling takes over.
