3. Snapshot 手动创建与自动化策略
etcd 快照(Snapshot)是数据恢复与集群迁移的基石。本章聚焦两种快照创建方式——手动即时备份与定时自动化策略,并给出保留周期的工程化建议。掌握这些方法,能有效应对数据损坏、误操作及集群重建场景。
3.1 手动快照:etcdctl snapshot save
手动快照适用于临时备份、升级前快照、故障现场保留等场景。核心命令为 etcdctl snapshot save,其基本语法如下:
# 单端点快照(推荐使用 leader 节点)
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/etcd/ca.pem \
--cert=/etc/etcd/etcd.pem \
--key=/etc/etcd/etcd-key.pem \
snapshot save /data/etcd-snapshots/snapshot_$(date +%Y%m%d_%H%M%S).db
# 多端点快照(自动选择可达端点)
ETCDCTL_API=3 etcdctl --endpoints=https://10.0.1.10:2379,https://10.0.1.11:2379 \
snapshot save /data/etcd-snapshots/snapshot_latest.db
最佳实践:手动快照前建议先执行
etcdctl endpoint health 确认集群健康;快照文件应写入独立磁盘或挂载点,避免与 etcd 数据目录共用 IO。
3.2 自动化策略:Cron 定时任务配置
生产环境必须建立自动化快照机制。以下为基于 Linux Cron 的典型配置方案:
3.2.1 快照脚本示例
#!/bin/bash
# /usr/local/bin/etcd-snapshot.sh
SNAPSHOT_DIR="/data/etcd-snapshots"
RETENTION_DAYS=7
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
SNAPSHOT_FILE="${SNAPSHOT_DIR}/snapshot_${TIMESTAMP}.db"
LOG_FILE="/var/log/etcd-snapshot.log"
# 创建快照
ETCDCTL_API=3 /usr/local/bin/etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/etcd/ca.pem \
--cert=/etc/etcd/etcd.pem \
--key=/etc/etcd/etcd-key.pem \
snapshot save "${SNAPSHOT_FILE}" >> "${LOG_FILE}" 2>&1
# 校验快照
ETCDCTL_API=3 /usr/local/bin/etcdctl \
--write-out=table snapshot status "${SNAPSHOT_FILE}" >> "${LOG_FILE}" 2>&1
# 清理过期快照
find "${SNAPSHOT_DIR}" -name "snapshot_*.db" -mtime +${RETENTION_DAYS} -delete
3.2.2 Cron 配置
# 每 2 小时执行一次快照(生产推荐)
0 */2 * * * /usr/local/bin/etcd-snapshot.sh
# 每天凌晨 2:00 执行一次快照(低变更环境)
0 2 * * * /usr/local/bin/etcd-snapshot.sh
# 每 30 分钟执行一次快照(高频变更环境)
*/30 * * * * /usr/local/bin/etcd-snapshot.sh
注意:Cron 环境变量与交互式 Shell 不同。脚本中必须使用路径指定 etcdctl 和证书文件;建议在脚本开头显式声明
PATH=/usr/local/bin:/usr/bin:/bin。
3.3 Snapshot 保留策略
保留策略需平衡恢复窗口与存储成本。以下为不同场景的推荐参数:
| 环境类型 | 快照频率 | 保留天数 | 存储预估(1GB 数据) | 恢复点目标(RPO) |
|---|---|---|---|---|
| 开发/测试 | 每 6 小时 | 3 天 | ~12 GB | 6 小时 |
| 生产(标准) | 每 2 小时 | 7 天 | ~84 GB | 2 小时 |
| 生产(高频) | 每 30 分钟 | 3 天 | ~144 GB | 30 分钟 |
| 合规/审计 | 每 1 小时 | 30 天 | ~720 GB | 1 小时 |
3.4 自动化快照流程架构
下图展示了从定时触发到快照清理的完整自动化链路:
3.5 快照保留策略对比
不同保留策略在存储成本与恢复能力上差异显著。以下为两种主流策略的对比:
| 策略类型 | 实现方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 时间窗口删除 | find -mtime +N -delete |
实现简单、系统资源消耗低 | 无法精确控制快照数量;时间戳跳跃可能导致保留不足 | 标准生产环境 |
| 数量上限保留 | 脚本计数 + 排序删除最旧文件 | 精确控制磁盘占用;不受时间跳跃影响 | 需要额外计数逻辑;脚本复杂度略高 | 磁盘空间敏感环境 |
工程建议:对于合规审计场景,建议采用“时间窗口 + 数量上限”双重策略:保留最近 7 天所有快照,同时确保至少保留最近 50 个快照文件,防止节假日无变更导致快照被全部清理。
3.6 快照恢复验证
自动化策略必须包含恢复验证环节。以下为验证脚本片段:
#!/bin/bash
# /usr/local/bin/etcd-snapshot-restore-test.sh
SNAPSHOT_FILE="/data/etcd-snapshots/snapshot_latest.db"
RESTORE_DIR="/tmp/etcd-restore-test"
# 清理上次测试数据
rm -rf "${RESTORE_DIR}"
mkdir -p "${RESTORE_DIR}"
# 恢复快照到临时目录
ETCDCTL_API=3 /usr/local/bin/etcdctl snapshot restore "${SNAPSHOT_FILE}" \
--name=restore-test \
--data-dir="${RESTORE_DIR}" \
--initial-cluster=restore-test=http://localhost:2380 \
--initial-cluster-=etcd-restore-test
# 启动临时 etcd 实例并验证数据
/usr/local/bin/etcd --data-dir="${RESTORE_DIR}" \
--listen-client-urls=http://localhost:12379 \
--advertise-client-urls=http://localhost:12379 &
ETCD_PID=$!
sleep 3
# 验证 key 数量
KEY_COUNT=$(ETCDCTL_API=3 etcdctl --endpoints=http://localhost:12379 get "" --prefix --keys-only | wc -l)
echo "Restored key count: ${KEY_COUNT}" >> /var/log/etcd-restore-test.log
# 清理
kill ${ETCD_PID}
rm -rf "${RESTORE_DIR}"
建议:将恢复验证脚本加入每周 Cron 任务(如周日凌晨 3:00),确保快照文件始终可恢复。验证结果应写入独立日志并接入告警系统。