etcd 3.4 End of Life: Upgrading to 3.5 and 3.6, With Backup and Restore

The short answer

etcd 3.4 is end of life. SIG-etcd shipped the final patch, v3.4.45, on 1 June 2026, nearly seven years after 3.4.0 came out in August 2019, and said no further patches would be issued. The supported branches are now 3.5, 3.6 and 3.7. The latest releases, all published on 22 September 2026, are v3.5.34, v3.6.15 and v3.7.2.

etcd supports upgrades one minor version at a time only, so a 3.4 cluster goes to 3.5 first and then to 3.6. Skipping a minor is not supported and, in the project's words, will likely fail. Take a snapshot backup before every step.

etcd versions and support status

etcd's written versioning policy is to maintain the current version and the previous release, but in practice the project still patches three branches. 3.3 and everything older are also EOL. The gap is already opening. The September releases for the supported branches moved to Go 1.26.8 and updated dependencies, including a gorilla/websocket fix in 3.5 and 3.6. None of that reaches 3.4. Every later Go or etcd security fix will widen the difference, and scanners will report it.

Where etcd 3.4 hides

• Kubernetes. etcd stores all Kubernetes API server data. kubeadm's default was etcd 3.4.3 for Kubernetes 1.17 and 1.18 and 3.4.13 for 1.19 to 1.21; 1.22 moved to 3.5.0. A cluster built on those versions and upgraded in place may still run a 3.4 etcd image.
• Patroni. PostgreSQL HA clusters often use etcd as the distributed configuration store. Check which section the Patroni config uses: etcd: talks to etcd over the v2 protocol, etcd3: over v3. Keys written through one are not visible through the other.
• Vitess. The etcd2 topology plugin stores Vitess topology in etcd 3 and later.
• Appliances and platforms that embed an etcd binary without advertising it. etcd --version on the host, or the image tag, settles it.

Step 1: back up etcd

Take a snapshot from a healthy member, ideally the leader, and check it:

etcdctl --endpoints=https://etcd1:2379 endpoint health
etcdctl --endpoints=https://etcd1:2379 snapshot save backup.db
etcdutl snapshot status backup.db -w table

A snapshot taken with snapshot save carries an integrity hash that restore checks. Copying member/snap/db from a data directory also works, but it may miss writes still in the WAL and needs --skip-hash-check at restore. The snapshot holds v3 data only.

To restore, every member restores the same snapshot into a new data directory, which creates a new logical cluster:

etcdutl snapshot restore backup.db \
  --name m1 --data-dir /var/lib/etcd-restored \
  --initial-cluster m1=https://host1:2380,m2=https://host2:2380,m3=https://host3:2380 \
  --initial-cluster-token etcd-cluster-restored \
  --initial-advertise-peer-urls https://host1:2380

For Kubernetes, the etcd docs recommend adding --bump-revision and --mark-compacted, so revisions never go backwards and controllers drop their stale caches.

Step 2: upgrade etcd from 3.4 to 3.5

First move to the latest 3.4 patch, since the project asks for the most recent patch before a minor upgrade. Then check that the cluster is healthy and every member reports 3.4.

In the general case the move is a zero-downtime rolling upgrade: stop one 3.4 member, start 3.5 on the same data directory, wait for it to rejoin, repeat. During the roll the cluster runs at the lowest common version and new 3.5 features switch on only when the last member is upgraded. Four things to check first:

• Authentication. If auth is enabled, the 3.5 guide says a rolling upgrade from 3.4 is not supported, because 3.5 changes the WAL format of auth entries. Plan a maintenance window.
• Large v2 data. A cluster serving more than 50 MB of v2 data can take up to two minutes per upgraded member to catch up. Wait between members.
• Removed and renamed interfaces. The /v3beta gRPC gateway path is gone in 3.5, and several etcd_debugging_* metrics were renamed, which breaks dashboards and alerts.
• No way back. While any member is still on 3.4 you can return to 3.4 binaries. Once all members are on 3.5, the snapshot is your rollback.

Step 3: upgrade from 3.5 to 3.6

etcd 3.6 removes the --enable-v2 flag and makes the v3 store the source of truth for membership. Before you move:

• Update every 3.5 member to 3.5.32 or later. Patches from 3.5.24 onward fix upgrade blockers, including the "zombie member" issue, where removed members reappear after the upgrade.
• If --enable-v2 or ETCD_ENABLE_V2 was ever set, run etcdutl check v2store on each member and clean up any custom v2 data it reports.
• Remove --enable-v2 from every member. A Patroni cluster still on the etcd: v2 section has to move to etcd3: before this step, because the v2 API is gone.

The roll itself works like 3.4 to 3.5. From 3.6, moving on to 3.7 is optional, since 3.6 is supported.

If you cannot upgrade yet

Kubernetes distributions pin their etcd version, and a Patroni or Vitess estate may need its own change window. OSSeva ships patched, signed etcd 3.4 builds today, so the cluster stays covered while the upgrade runs on your schedule. See etcd extended support and the etcd 3.4 end-of-life page. For Patroni on ZooKeeper, read moving Patroni from ZooKeeper to etcd.

Frequently asked questions

When did etcd 3.4 reach end of life?

On 1 June 2026, with the final patch release v3.4.45.

Can I upgrade etcd from 3.4 directly to 3.6?

No. etcd supports one minor version at a time. Go 3.4 to 3.5, then 3.5.32 or later, then 3.6.

Can I downgrade after upgrading to 3.5?

Not once every member runs 3.5. Keep the pre-upgrade snapshot; restoring it is the rollback.

How often should I back up etcd?

Before every upgrade and on a regular schedule in between. Store snapshots off the etcd hosts and test a restore, because a snapshot you have never restored is not yet a backup.

Does etcdctl snapshot restore still work?

Use etcdutl snapshot restore. From 3.5 onward the etcd docs use etcdutl for offline operations such as restore and status, while etcdctl snapshot save still takes the backup from a live member.