4. etcd 数据备份原理：快照与 WAL 日志的协同机制
etcd 作为分布式一致性的基石，其数据安全依赖于 快照（Snapshot） 与 WAL（Write-Ahead Log） 的协同工作。理解两者的配合机制，是制定灾备策略的前提。
4.1 核心组件：WAL 日志与快照
| 组件 | 作用 | 存储内容 | 关键特征 |
|---|---|---|---|
| WAL 日志 | 记录所有写入操作的持久化日志 | 每次 put、delete、事务等操作的序列化记录 | 顺序追加写入，是数据恢复的“重放”依据 |
| 快照（Snapshot） | 某一时刻的完整数据状态 | 整个 key-value 存储引擎的压缩快照 | 用于截断 WAL，加速重启恢复 |
关键认知： WAL 是“操作日志”，快照是“状态快照”。没有快照，WAL 会无限增长；没有 WAL，快照无法保证数据一致性。
4.2 协同机制：快照与 WAL 的配合流程
etcd 在运行时，数据写入先追加到 WAL，再应用到内存中的 bbolt 存储引擎。当 WAL 文件达到阈值（默认 10,000 条记录）或触发手动备份时，etcd 会创建快照。
协同流程：
- 写入请求 → 先写入 WAL 文件（持久化）
- 应用状态 → 将 WAL 中的操作应用到内存 bbolt 树
- 触发快照 → 当 WAL 条目数达到 10,000 或手动触发
- 创建快照 → 将当前 bbolt 数据写入 snapshot.db 文件
- 截断 WAL → 删除快照点之前的 WAL 文件，释放磁盘空间
4.3 备份的一致性保证
etcd 的快照备份是 崩溃一致性 的，这意味着备份时刻的数据状态与 WAL 中的操作序列严格对应。
- 原子性： etcdctl snapshot save 命令在 etcd 内部会冻结当前状态，确保快照不包含部分写入。
- 事务边界： 快照总是在完整的事务边界上创建，不会出现跨事务的不一致状态。
- WAL 校验： 恢复时，etcd 会校验快照文件与 WAL 文件的哈希值，确保数据未被篡改或损坏。
重要提醒： 仅备份快照文件（snapshot.db）而不备份 WAL 文件，在恢复时可能丢失快照创建后到最新状态之间的少量写入。生产环境建议同时备份快照和 WAL 文件。
4.4 备份频率与存储策略
备份频率直接影响 RPO（恢复点目标）和存储成本。以下为推荐的策略对比：
| 策略 | 备份频率 | RPO | 存储开销 | 适用场景 |
|---|---|---|---|---|
| 高频快照 | 每 5-15 分钟 | ≤ 15 分钟 | 高（快照文件较大） | 核心交易、金融级业务 |
| 中频快照 + WAL 归档 | 每小时快照 + 持续 WAL 归档 | ≤ 1 小时 | 中（WAL 增量较小） | 大多数生产环境 |
| 低频快照 | 每 6-24 小时 | ≤ 24 小时 | 低 | 开发测试、非关键业务 |
4.5 存储策略最佳实践
- 本地 + 异地： 快照文件先写入本地磁盘，再通过脚本同步到对象存储（如 S3、OSS）或远程 NFS。
- 保留周期： 建议保留最近 7 天的每小时快照，最近 30 天的每日快照，超过 30 天的快照可删除或归档到冷存储。
- 压缩： 快照文件默认未压缩，建议在备份脚本中添加 gzip 压缩，可减少 60%-80% 的存储空间。
- 命名规范： 使用
etcd-snapshot-{集群名}-{时间戳}.db.gz格式，便于自动化管理和恢复。
# 示例：带压缩的备份脚本
ETCDCTL_API=3 etcdctl snapshot save /tmp/snapshot.db
gzip /tmp/snapshot.db
aws s3 cp /tmp/snapshot.db.gz s3://my-bucket/etcd-backups/
压测复盘提示： 在压测环境中，高频快照（≤5 分钟）会显著增加 etcd 的 CPU 和磁盘 IO 开销。建议在压测前将备份频率调整为 30 分钟一次，压测结束后再恢复生产策略。