etcd 快照备份是什么
Kubernetes 的全部集群状态都存在 etcd 里：对象、配置、密钥、Service 定义都在其中。etcdctl snapshot save 能在线生成一份一致性快照，恢复时用 snapshot restore 生成新的数据目录再指向它启动。对 K8s 集群来说，定期做 etcd 快照并验证，是灾备里投入最小、底线收益最大的一件事。
基本信息
| 适用平台 | Kubernetes（kubeadm 自建集群、托管控制面之外的场景）与独立 etcd 集群 |
|---|---|
| 必要参数 | --endpoints、--cacert、--cert、--key：需与集群证书一致，否则连不上 |
| 频率建议 | 按集群变更频率定；变更少也建议至少每日一次，重大变更前加做一次 |
| 保管要求 | 快照放到与控制面不同的故障域，并与集群备份记录一起登记 |
典型使用场景
- 控制面灾难恢复：etcd 数据损坏或误删对象后重建集群状态
- 升级与变更前留底：集群版本升级、大规模变更前先做一份快照
- 迁移控制面：把集群状态搬到新节点或新集群
- 审计与比对：用快照状态确认某次变更前后的对象差异
- 演练验证：定期恢复到隔离环境，证明快照真的可用
保存与校验快照
保存与校验快照
# 生成一致性快照，证书路径以本机 kubeadm 部署为准
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%F).db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# 校验快照：关注哈希、修订号与总大小
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-2026-10-13.db --write-out=table
# 查看快照文件与备份记录的对应关系
ls -lh /backup/etcd-*.db恢复（需停止控制面组件）
恢复（需停止控制面组件）
# 1) 停止 API Server 与 etcd 进程，避免写入干扰
# 2) 用快照生成新的数据目录（不要覆盖到运行中的目录）
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-2026-10-13.db \
--data-dir=/var/lib/etcd-restore --name=<节点名> \
--initial-cluster=<节点名>=https://<节点IP>:2380 \
--initial-advertise-peer-urls=https://<节点IP>:2380
# 3) 让 etcd 指向新数据目录并启动，再启动 API Server
# 4) 用 kubectl get nodes / get pods -A 验证集群状态snapshot status 输出读法
| 字段 | 含义 | 正常/异常 |
|---|---|---|
| Hash | 快照内数据的哈希值 | 与备份记录登记值不一致说明文件被改动或损坏 |
| Revision | 快照对应的 etcd 修订号 | 明显小于当前集群修订号说明快照较旧 |
| Total keys | 快照中的键总数 | 数量异常偏低可能是采集不全或集群本身被清空 |
| Total size | 快照文件大小 | 与文件实际大小差异过大时需排查采集过程 |
备份脚本要使用与集群一致的证书与端点；kubeadm 集群的证书默认路径见官方文档，托管控制面的集群则由平台负责 etcd，不需要自建快照。
恢复前先备份现场：错误地覆盖运行中的数据目录会让集群状态无法再回到当前版本，恢复操作应在隔离环境演练过再上生产。