为什么必须备份 etcd
etcd 保存整个集群的全部对象状态，是唯一的权威数据源。其他组件都可以重建，它不行。因此定期导出快照并验证快照可读，是自建集群最基础的一项运维动作。恢复过程属于高风险操作，必须停掉相关组件并按顺序切换数据目录，且提前演练过才可在生产执行。
基本信息
| 适用对象 | 自建集群（托管集群由云厂商负责底层） |
|---|---|
| 备份方式 | 导出快照文件并校验完整性 |
| 访问条件 | 需要证书与密钥，以及访问接口地址 |
| 恢复特点 | 需要停止 etcd 并从快照重建数据目录 |
| 建议频率 | 每日至少一次，重要变更前额外执行 |
典型使用场景
- 日常定时备份，作为误删与故障的兜底手段
- 大规模变更（升级、批量清理）前的保护点
- 演练恢复流程，验证备份真的可用
- 集群重建或迁移时作为数据来源
- 排查数据异常时导出快照做离线分析
备份与校验
备份与校验
ETCDCTL_API=3 etcdctl --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 \
snapshot save /backup/etcd-$(date +%F).db # 导出快照
ETCDCTL_API=3 etcdctl --write-out=table snapshot status /backup/etcd-$(date +%F).db # 校验快照关键点读法
| 环节 | 要点 | 风险 |
|---|---|---|
| 备份 | 证书与端点正确、快照可读 | 证书错误会导致备份静默失败 |
| 存放 | 异地或独立存储 | 与集群同盘时磁盘故障会一起丢失 |
| 恢复 | 停服务、重建数据目录、再启动 | 操作顺序错误会导致数据不可用 |
| 演练 | 在测试环境完整走一遍 | 未演练的流程在生产上大概率出错 |
恢复前务必在测试环境演练。恢复完成后集群会回到快照时刻的状态，之后创建的对象的变更全部消失，证书与组件版本的对应关系也需要重新核对。
备份文件要定期做完整性校验，并检查导出时间点是否符合预期。只备份不校验，等到真需要恢复时才发现文件损坏的情况并不少见。