Etcd auf Debian: Drei Knoten, ein Quorum und kein Drama

Etcd ist dieser kleine, unscheinbare Key-Value-Store, der bei HA-Setups plötzlich das Gehirn der Operation spielt. Kubernetes, Patroni, Service Discovery: Alle wollen irgendwo zuverlässig Zustand ablegen. Also bauen wir uns auf Debian einen sauberen 3-Node-Cluster. Ohne Magie. Mit Quorum.

Grundsetup auf drei Debian-Servern

Wir nehmen drei Nodes:

- etcd1 mit 10.0.0.11

- etcd2 mit 10.0.0.12

- etcd3 mit 10.0.0.13

Wichtig: Port 2379 ist für Clients, 2380 für die Peer-Kommunikation. Wenn deine Firewall dazwischenfunkt, macht etcd beleidigt einfach gar nichts.

Installation:

apt update
apt install -y etcd-server etcd-client
systemctl stop etcd

Jetzt konfigurieren wir pro Node /etc/default/etcd. Beispiel für etcd1:

# /etc/default/etcd
ETCD_NAME="etcd1"
ETCD_DATA_DIR="/var/lib/etcd"

ETCD_LISTEN_CLIENT_URLS="http://10.0.0.11:2379,http://127.0.0.1:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.11:2379"

ETCD_LISTEN_PEER_URLS="http://10.0.0.11:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.11:2380"

ETCD_INITIAL_CLUSTER="etcd1=http://10.0.0.11:2380,etcd2=http://10.0.0.12:2380,etcd3=http://10.0.0.13:2380"
ETCD_INITIAL_CLUSTER_TOKEN="plutex-etcd-cluster-01"
ETCD_INITIAL_CLUSTER_STATE="new"

Auf etcd2 und etcd3 ersetzt du ETCD_NAME, LISTEN_* und ADVERTISE_* entsprechend. Das ETCD_INITIAL_CLUSTER bleibt auf allen Nodes identisch.

Dann starten:

systemctl enable --now etcd
systemctl status etcd

Gesundheitscheck:

ETCDCTL_API=3 etcdctl \
  --endpoints=http://10.0.0.11:2379,http://10.0.0.12:2379,http://10.0.0.13:2379 \
  endpoint health

Wenn alle drei healthy melden, darfst du kurz zufrieden nicken. Nicht zu lange. Backup fehlt noch.

Quorum: Demokratie, aber mit harten Regeln

Etcd nutzt Raft. Heißt: Ein Cluster braucht Mehrheit. Nicht „wäre nett“, sondern mathematisch zwingend.

Bei 3 Nodes liegt das Quorum bei 2. Ein Node darf sterben, der Cluster bleibt schreibfähig. Bei 5 Nodes brauchst du 3 Stimmen, darfst aber 2 verlieren.

Deshalb sind 2-Node-Cluster eine Falle mit hübscher Verpackung. Fällt ein Node aus, bleibt nur einer übrig. Einer ist keine Mehrheit von zwei. Ergebnis: keine Writes. HA-Cosplay.

Kurzregel:

- 1 Node: kein HA

- 3 Nodes: gut für viele Setups

- 5 Nodes: robuster, aber mehr Latenz und Betriebsaufwand

- 2 oder 4 Nodes: meistens Unsinn

Test: Key schreiben und lesen

Kleiner Funktionstest:

ETCDCTL_API=3 etcdctl \
  --endpoints=http://10.0.0.11:2379 \
  put /plutex/test "it lives"

ETCDCTL_API=3 etcdctl \
  --endpoints=http://10.0.0.12:2379 \
  get /plutex/test

Wenn it lives zurückkommt, repliziert der Cluster. Sehr schön.

Backup: Snapshot statt Datenverzeichnis-Klau

Bitte nicht einfach /var/lib/etcd von einem laufenden Node kopieren. Das ist wie eine Datenbank per cp sichern und hoffen, dass die Bits gute Laune haben.

Etcd bringt Snapshots mit:

mkdir -p /var/backups/etcd

ETCDCTL_API=3 etcdctl \
  --endpoints=http://10.0.0.11:2379 \
  snapshot save /var/backups/etcd/etcd-$(date +%F-%H%M).db

Prüfen:

ETCDCTL_API=3 etcdctl snapshot status /var/backups/etcd/etcd-2026-11-03-1200.db

Den Snapshot danach bitte runter vom Server: Backup-Storage, Object Storage, Tape, Runensteinplatte — Hauptsache nicht nur lokal auf dem Node, der gerade Feuer fängt.

Restore im Ernstfall

Restore passiert in ein neues Datenverzeichnis. Beispiel für etcd1:

systemctl stop etcd
rm -rf /var/lib/etcd-restore

ETCDCTL_API=3 etcdctl snapshot restore /var/backups/etcd/etcd-2026-11-03-1200.db \
  --name etcd1 \
  --initial-cluster "etcd1=http://10.0.0.11:2380,etcd2=http://10.0.0.12:2380,etcd3=http://10.0.0.13:2380" \
  --initial-advertise-peer-urls http://10.0.0.11:2380 \
  --data-dir /var/lib/etcd-restore

Danach ETCD_DATA_DIR auf /var/lib/etcd-restore setzen und auf allen Nodes passend wiederherstellen. Wichtig: Restore ist Cluster-Operation, kein „ich fummel mal nur an einem Node“.

Für Produktion kommt noch TLS dazu. Ohne TLS ist okay fürs Lab. Im echten Netz ist Klartext-Raft eher Kategorie „bitte nicht dem Auditor zeigen“.