备份策略：3-2-1 原则的落地

备份策略最怕两个极端：完全不备份，或者备了但从没验证过能不能恢复。3-2-1 原则是把「有备份」变成「可恢复」的最小框架。

3-2-1 的含义

• 3 份数据：生产 + 至少两份备份；
• 2 种介质：比如磁盘 + 对象存储，避免同一介质整体故障；
• 1 份异地：机房级灾难（火灾、误删云盘、勒索加密）也recover。

对个人和小团队，务实版本是：服务器本地一份 + 对象存储（OSS/COS）异地一份，加密传输。

备份什么

按恢复价值排序：

1. 数据库：逻辑备份（mysqldump）便于跨版本恢复，量大时用物理备份（xtrabackup）。务必加 --single-transaction 避免锁表；
2. 配置与代码：代码本来就该在 Git；nginx/php/系统配置用 etckeeper 或脚本导出；
3. 上传文件：增量同步（rsync / OSS sync）；
4. 别忘了：crontab、数据库账号、SSL 私钥的备份——丢了这些，数据回来了也起不来。

mysqldump --single-transaction --routines --triggers \
  -u backup -p"$PW" mydb | gzip > /backup/db-$(date +%F).sql.gz

三个必须检验的指标

• RPO（能丢多少数据）：决定备份频率。每天一备 = 最多丢一天；
• RTO（多久能恢复）：决定恢复流程的自动化程度；
• 可恢复性：每月做一次恢复演练，把备份在测试机还原并抽查数据。没演练过的备份不可信。

留存策略

参考 GFS：日备留 7 天、周备留 4 周、月备留 6-12 个月。对象存储开启版本控制，防误删；备份账号用只读或独立凭证，防止勒索软件顺着 root 权限把备份一起加密。

自动化与监控

备份脚本进 crontab/timer，输出重定向到日志，失败必须告警（接 webhook 到IM）。再加一个独立的「备份新鲜度检查」：备份文件超过 26 小时没更新就告警——备份任务悄悄失败两周而无人知晓，是真实发生过的事故。

一句话：备份的价值不在于备份动作，而在于恢复演练的通过记录。