备份与容灾：3-2-1 原则和一次真正的恢复演练

3-2-1 只说了一半

3-2-1 是：三份副本、两种介质、一份异地。它解决的是「副本会不会一起没」的问题，没有解决「副本本身是不是好的」。3-2-1-1-0 补上了后两条：一份离线或不可变，零错误——备份必须经过校验，恢复失败率要为零。

加这两条不是理论洁癖。勒索软件与误删是当下最常见的两类事故，而它们恰好能穿过前四条：同步复制的副本会被一起加密，能删生产库的账号往往也能删备份。离线或不可变那一份，是唯一能在账号被盗后还活下来的副本。

备份没验证过等于没有备份；只验证了文件存在，等于验证了一半。

先定 RPO 和 RTO，再谈方案

RPO 决定备份频率，RTO 决定恢复方式，两者都该由业务给，不能由运维猜。最常见的错位是：数据库每小时全量备份，业务方却期望丢数据不超过五分钟——这个差距只能靠 binlog 增量补上。

数据类型	RPO	RTO	典型方案
核心交易库	≤ 5 分钟	≤ 1 小时	主从 + binlog 持续归档 + 定期全量
一般业务库	≤ 1 小时	≤ 4 小时	每小时增量 + 每日全量
静态资源与对象存储	近似 0	≤ 30 分钟	版本控制 + 跨区复制
分析型与日志数据	≤ 24 小时	≤ 1 天	每日全量，允许从源头重建

写下 RPO/RTO 之后要立刻算一遍成本：RPO 从 1 小时缩到 5 分钟，增量归档频率提高 12 倍，存储与传输都会跟着涨。这个账必须在方案评审时摆出来，否则半年后会被账单倒逼着改回去。

全量、增量、差异与保留代次

全量：恢复最快，占用最大，作为基线定期做。
增量：只备变化块，最省最快，但恢复要按链回放，链上任一环损坏就断。
差异：备自上次全量以来的变化，恢复只需全量加一份差异，是可靠性与成本的折中。
保留代次：常见做法是日备留 7 代、周备留 4 代、月备留 12 代，按合规要求调整，而不是无脑全留。

增量链要定期合成全量，否则恢复时间会随链长线性增长，最后超出 RTO。这一点在小团队里极易被忽略：平时每天加一盘磁带很轻松，真出事时回放三百个增量就没人扛得住。

恢复演练的四个检查项

能否解压或解密：加密备份的密钥是否还在、权限是否还在。这一步失败的比例比想象高，尤其是密钥跟着备份一起存在同一台机器上的场景。
能否起服务：在隔离环境里真正启动应用并完成一次读写，而不是只看数据库进程有没有起来。
数据一致性：核对行数、校验和、关键业务表的最近更新时间，确认恢复到的是预期时间点，而不是「一个能连上的空库」。
耗时是否在 RTO 内：从开始恢复计时到服务可用，这才是 RTO 的真实值，不是文档上写的值。

频率建议每季度一次完整演练、每月一次抽样恢复，并把结果写成记录：谁恢复的、恢复到哪个时间点、耗时多少、发现了什么问题。没有记录的演练和没做没有区别，因为下次没人知道上次踩过什么坑。

数据库备份的一致性

热备最常见的坑是「备份能恢复，但数据不自洽」。InnoDB 表用逻辑导出必须加一致性快照参数，MyISAM 表则需要锁表。更稳的做法是物理备份加 binlog 归档：全量给基线，binlog 给时间点恢复，两者配合才能做到分钟级 RPO。

mysqldump --single-transaction --quick --routines --triggers 
  --master-data=2 --set-gtid-purged=ON 
  --databases app_db > app_db_$(date +%F).sql

--single-transaction 让整个导出落在一个一致性快照里，不锁业务写入；--master-data=2 把当时的 binlog 位点以注释形式写进备份头部，这正是时间点恢复的起点。恢复顺序是先导入全量，再用 mysqlbinlog 回放到目标时间点之前，跳过误操作那一段。

异地副本的成本取舍

异地副本的边际成本不在存储费，而在传输费和取回费。跨区复制按流量计费，冷归档取回又按请求数与时长计费，两者叠加后，一份「看起来便宜」的异地副本可能比生产存储还贵。合理的做法是分级：核心数据实时跨区，一般数据每日跨区，可重建数据只保留本地多副本。

带宽与流量的计费细节可以对照带宽与流量计费先算一遍再定架构，别等第一次全量复制把出口流量跑满才发现。

加密与权限：不要共用一把钥匙

备份加密密钥与生产密钥分离，且不要放在被备份的那台机器上。
备份账号只授予写入目标桶的权限，不给删除权限；开启对象存储的版本控制与对象锁。
恢复账号与备份账号分开，恢复操作单独留审计日志。
密钥要有托管与轮换方案，密钥丢失等同于备份丢失。

这些要求与主机侧加固是同一套逻辑：账号、端口、审计三件事先收干净，备份才有意义。可以先按云服务器安全加固清单过一遍。如果备份目标是对象存储，注意版本控制、合规锁与跨区复制在各家的实现差异，选型可参考对象存储对比；预算紧张时，用成本优化里的思路先区分冷热再决定副本数量。

常见问题

备份文件的校验和一致，就算验证通过了吗？

不算。校验和只能证明文件没被损坏，不能证明里面是完整可恢复的数据。真正有效的验证必须做一次恢复并核对业务数据，至少要能起服务、能查到最近写入的记录。

小团队没有异地机房，怎么做「一份异地」？

用对象存储的不同区域就够了，成本远低于自建机房。另一个低成本方案是定期把加密备份写到离线介质并异地存放，虽然人工，但能挡住账号被盗这类风险。

备份应该保留多久？

先看合规要求，没有要求就按「日 7、周 4、月 12」起步，即大约一年。保留期越长，越要依赖冷存储和去重，否则成本会随代次线性上涨。

云厂商的自动快照能替代自建备份吗？

不能完全替代。快照通常与实例或云盘绑定，账号级事故、误删整盘、跨账号迁移这些场景下容易一起失效。快照适合做短周期回滚，长期合规备份仍要独立存放并定期做恢复演练。