SRE自动化运维实践：让数据备份不再手忙脚乱

凌晨三点，服务器告警短信突然炸响。ref="/tag/426/" style="color:#2B406D;font-weight:bold;">数据库主从同步中断，备份任务卡在一半。值班工程师一边啃着冷掉的包子，一边在终端敲命令，心里盘算着这已经是本周第三次手动补跑备份脚本了。

别再靠人肉巡检了

很多团队的数据备份还停留在“写个脚本 + 定时任务 + 人工抽查”的模式。听起来没问题，可一旦网络抖动、磁盘满载或者权限变更，脚本就可能静默失败。等发现问题时，往往已经丢了好几天的数据。

SRE（站点可靠性工程）的核心思路是：把运维当成产品来设计。这意味着备份不能只是“能用就行”，而要像流水线一样自动运转、自我修复、持续验证。

自动化备份的三个关键动作

第一，触发自动化。除了定时任务，还要支持事件驱动。比如数据库实例扩容完成、代码发布结束、敏感操作执行后，都应该自动触发一次快照备份。

第二，过程可观测。每次备份任务都要上报状态、耗时、数据量。把这些指标接入监控系统，设置异常波动告警。不是等备份失败才通知，而是趋势异常就预警。

第三，结果可验证。备份完成了不等于数据可用。我们写了个小工具，每天随机抽取10%的备份集，自动拉起临时实例进行恢复测试。失败立即告警，并标记该备份不可信。

一个简单的恢复验证脚本示例

#!/bin/bash
# 随机选择一个昨日的备份文件
BACKUP_FILE=$(ls /backup/db_*.tar.gz | grep $(date -d yesterday +%Y%m%d) | shuf -n1)

if [ -z "$BACKUP_FILE" ]; then
  echo "No backup found for validation"
  exit 1
fi

# 启动测试容器并恢复
docker run --rm -v $BACKUP_FILE:/restore.tar.gz postgres:13 bash -c \
  "tar -xzf /restore.tar.gz && pg_restore -U appuser -d testdb dump.sql"

if [ $? -eq 0 ]; then
  echo "Validation passed: $BACKUP_FILE";
else
  echo "Validation failed: $BACKUP_FILE";
  curl -X POST https://alert-api/notify -d 'Backup validation failed';
fi

这个脚本每天凌晨跑一次，失败消息直接推送到运维群。刚开始每周都能抓出两三次问题，后来逐渐稳定。现在团队反而有点不习惯——没有告警的日子，反而会主动去查系统是不是挂了。

故障演练常态化

我们每月搞一次“删库演习”：随机选一个非核心服务，由SRE团队直接删除其生产数据库。应用团队要在30分钟内完成数据恢复并验证业务正常。

第一次演练时，有人翻出半年前的备份文档，发现路径早已变更；第二次有人忘了加密密钥存在另一个系统的配置中心。几次下来，大家终于意识到：备份策略必须和代码一起管理，随系统演进而更新。

现在所有备份相关的脚本、密钥、恢复步骤都存放在Git仓库，变更走PR流程。新服务上线时，备份方案是必须填写的 checklist 项之一。