数据不丢、服务不断：政策快报平台的冷备与灾备实践

当时我们觉得“没事，有备份”。结果恢复的时候发现：备份是7天前的。最近一周的新增数据，全丢了。

用户发现政策列表突然少了1000多条，开始投诉。我们花了三天时间从其他信源重新补采，才把数据追回来。

那次之后，我们把备份策略彻底重做了。之前“有备份就行”的心态，变成了“恢复要快、丢失要少”。本文复盘备份与灾备的演进过程。

备份策略的3次升级

第一次：全量备份

最基础的方案。每天凌晨2点，对数据库做一次全量备份，保留7天。

问题：恢复窗口太长。如果中午12点出问题，恢复只能回到凌晨2点的状态，上午10小时的数据全部丢失。备了，但备得不够。

第二次：全量+增量备份

每天一次全量备份（凌晨2点）+ 每小时一次增量备份（binlog）。

问题：恢复步骤复杂。需要先恢复全量备份，再按顺序回放增量日志。恢复时间很长，如果增量日志有损坏，恢复就会失败。而且备份文件存在本地服务器上，硬盘同时损坏时，备份也没了。

第三次：异地冷备+定期恢复演练

全量备份（每天凌晨2点）+ 增量备份（每15分钟）。备份文件实时同步到异地服务器，每天凌晨自动做一次恢复验证，确认备份可用性。

异地冷备：

• 主数据库 → 每天全量备份 → 同步到异地服务器

• 增量binlog每15分钟同步一次

• 异地服务器存储最近30天的备份文件

定期演练：

• 每天凌晨自动恢复一份备份到验证环境

• 验证通过：记录“备份可用”

• 验证失败：触发告警，人工介入排查原因

效果：RPO（数据丢失量）从“小时级”降到“15分钟级”，RTO（恢复时间）从“天级”降到“小时级”。

关键决策

决策一：为什么不用云厂商的托管备份？

云厂商的托管备份确实省心，但我们有两个考虑：

• 云厂商的备份策略是“黑盒”，你无法自定义恢复粒度

• 跨云灾备时，备份格式不兼容

最终选择自建+云存储的组合方案。

决策二：冷备vs热备

冷备：备份数据不实时同步，恢复时需要手动操作，适用于非核心数据或可容忍一定丢失的数据。
热备：主备实时同步，故障时自动切换，适用于核心数据（用户信息、政策正文）。

我们采用了混合策略：

• 核心数据（用户、政策正文）：热备+实时同步

• 非核心数据（操作日志、临时缓存）：冷备

决策三：备份放在哪里？

• 本地：1份（最近7天）

• 异地：1份（最近30天）

• 对象存储（OSS）：1份（长期归档）

“3-2-1”备份原则：3份拷贝、2种介质、1份异地。

结尾

“有备份”不等于“备份可用”。定时演练是验证备份唯一可靠的方式。从“硬盘坏了才知道备份没做对”到“每天自动验证备份可用性”，这条演进路径告诉我们：备份策略的核心不是“备份频率有多高”，是“恢复的时候能不能用”。用不了的备份，等于没有备份。