备份翻车，通常不是技术问题，而是流程问题

备份翻车，通常不是技术问题，而是流程问题

我们团队只有 6 个人，没有专职运维，数据库、对象存储和代码仓库全靠自己维护。三年前的一次事故让我们彻底改变了备份策略：当时误执行了一条 rm -rf 命令，删除了生产环境的一张核心业务表，而所谓的“每日备份”其实已经停摆了近两周——因为脚本在某次系统更新后悄悄挂了，我们却一直没发现。

从那以后，我们总结出一套适合小团队的备份方案，不复杂，但每一步都踩过坑。核心原则只有一条：备份不是“做完就行”，而是“随时能恢复”。

先定策略：3-2-1 规则，但简化到能落地

小团队最容易犯的错误是照搬大厂的 3-2-1 规则（3 份数据、2 种介质、1 份异地），结果资源不够，最后变成“备份了个寂寞”。我们简化后的落地方式是：

• 数据本身一份（生产环境）；
• 本机备份一份（同机磁盘，用于快速恢复，但不作为唯一依靠）；
• 异地备份一份（对象存储或另一台云主机，必须和源不在同一个可用区）。

如果连异地备份都做不了，至少把备份文件定期上传到 minio 或 s3 的独立桶里，并设置版本控制。注意：备份文件不能放在和生产数据同一个挂载点下，否则磁盘满或误删时会一起遭殃。

把备份变成“无人值守”的自动化任务

手动备份等于没有备份。我们所有备份都写成脚本，用 cron 定时执行。一个典型的 MySQL 备份脚本核心部分大概长这样：

• 先 mysqldump --single-transaction --routines --triggers 导出，避免锁表；
• 输出文件按日期命名，如 backup-20250101.sql.gz，保留最近 7 份；
• 导出后立即校验文件大小，小于某个阈值就触发告警；
• 用 gzip -t 验证压缩包完整性，防止出现坏文件；
• 最后通过 rclone 同步到异地存储。

光有脚本还不够，必须验证“恢复”这个动作本身。我们每季度会选一个周六，在测试库上跑一次完整的恢复流程，包括导入数据、检查表行数、抽查关键业务字段。这一步虽然耗时，但能发现 90% 的备份隐患。

别把备份和主数据放在同一个篮子里

早期我们犯过一个低级错误：把数据库备份文件放到应用服务器的数据盘上，结果那台机器的磁盘被日志塞满了，备份写了一半就失败，而监控只报了磁盘告警，没报备份失败。等我们发现时，最近一份可用备份已经是 9 天前了。

现在我们的原则是：备份目标必须具备“防误删”和“防加密”属性。异地存储桶开启对象锁或版本控制，本地备份目录设置 chattr +i 防止被误改；同时给备份脚本的 cron 任务加上 MAILTO 和失败重试机制，一旦备份脚本返回非零退出码，马上推送钉钉告警。小团队人手少，不可能天天盯日志，必须让系统自己报信。

最后一条防线：监控备份本身

不要以为备份脚本运行了就万事大吉。我们在 prometheus 里加了一个简单指标：每天凌晨 2 点检查备份文件的时间戳，如果最新文件超过 26 小时没有更新，就触发 Warning 告警。这个检查比看备份日志有效得多，因为它验证的是“结果”而非“过程”。

另外，我们还做了一件事：把恢复手册写成一张 A4 纸，贴在机柜门上。内容包括如何登录备份服务器、如何找到最近的文件、用哪条命令恢复数据库。因为小团队最大的风险是——唯一会写备份脚本的人离职了，剩下的人连备份文件在哪儿都不知道。

总结成一句话：备份不是技术活，是纪律活。与其追求复杂的备份工具，不如把简单的备份做对、做勤、做可验证，这样才能在翻车时真正救回来。