当时我们觉得“没事有备份”。结果恢复的时候发现备份是7天前的。最近一周的新增数据全丢了。用户发现政策列表突然少了1000多条开始投诉。我们花了三天时间从其他信源重新补采才把数据追回来。那次之后我们把备份策略彻底重做了。之前“有备份就行”的心态变成了“恢复要快、丢失要少”。本文复盘备份与灾备的演进过程。备份策略的3次升级第一次全量备份最基础的方案。每天凌晨2点对数据库做一次全量备份保留7天。问题恢复窗口太长。如果中午12点出问题恢复只能回到凌晨2点的状态上午10小时的数据全部丢失。备了但备得不够。第二次全量增量备份每天一次全量备份凌晨2点 每小时一次增量备份binlog。问题恢复步骤复杂。需要先恢复全量备份再按顺序回放增量日志。恢复时间很长如果增量日志有损坏恢复就会失败。而且备份文件存在本地服务器上硬盘同时损坏时备份也没了。第三次异地冷备定期恢复演练全量备份每天凌晨2点 增量备份每15分钟。备份文件实时同步到异地服务器每天凌晨自动做一次恢复验证确认备份可用性。异地冷备主数据库 → 每天全量备份 → 同步到异地服务器增量binlog每15分钟同步一次异地服务器存储最近30天的备份文件定期演练每天凌晨自动恢复一份备份到验证环境验证通过记录“备份可用”验证失败触发告警人工介入排查原因效果RPO数据丢失量从“小时级”降到“15分钟级”RTO恢复时间从“天级”降到“小时级”。关键决策决策一为什么不用云厂商的托管备份云厂商的托管备份确实省心但我们有两个考虑云厂商的备份策略是“黑盒”你无法自定义恢复粒度跨云灾备时备份格式不兼容最终选择自建云存储的组合方案。决策二冷备vs热备冷备备份数据不实时同步恢复时需要手动操作适用于非核心数据或可容忍一定丢失的数据。热备主备实时同步故障时自动切换适用于核心数据用户信息、政策正文。我们采用了混合策略核心数据用户、政策正文热备实时同步非核心数据操作日志、临时缓存冷备决策三备份放在哪里本地1份最近7天异地1份最近30天对象存储OSS1份长期归档“3-2-1”备份原则3份拷贝、2种介质、1份异地。结尾“有备份”不等于“备份可用”。定时演练是验证备份唯一可靠的方式。从“硬盘坏了才知道备份没做对”到“每天自动验证备份可用性”这条演进路径告诉我们备份策略的核心不是“备份频率有多高”是“恢复的时候能不能用”。用不了的备份等于没有备份。
