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 自动化快照流程架构

下图展示了从定时触发到快照清理的完整自动化链路:

自动化快照流程架构 Cron 定时触发 etcd-snapshot.sh 执行 环境变量 / 证书 / 路径检查 snapshot save 写入磁盘 /data/etcd-snapshots/ snapshot status 校验 校验哈希 / 版本 / 数据量 find -mtime +N -delete 清理

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),确保快照文件始终可恢复。验证结果应写入独立日志并接入告警系统。