去年一个客户半夜打电话给我，声音发抖：“数据库被人删了，快帮我恢复。”
我问他：“备份有吗？”
“有，RDS自动备份，每天都跑。”
“那你恢复一下试试？”
二十分钟后他回电：“恢复不了。备份文件是坏的，从三个月前就开始坏了。”
那天晚上，他们团队从binlog里手工捞数据，折腾到天亮，最后丢了将近一天的核心订单。第二天复盘，发现一个扎心的事实：RDS自动备份开了三年，从来没人恢复验证过。
这不是RDS的错，是人的错。
今天聊聊云上数据库备份与恢复。不是那种“备份很重要”的废话，而是实打实的：怎么设策略、怎么验证、怎么在真出事的时候不慌。
01 自动备份不等于自动可用
很多人以为开了RDS自动备份就万事大吉了。这是最大的幻觉。
RDS自动备份做了三件事：每天一次全量备份、实时增量备份、保留N天。但“备份成功”只代表文件写进去了，不代表文件是好的，更不代表能恢复出来。
反常识观点：开了自动备份，不等于你有了可靠的备份。 从“备份跑着”到“能恢复”，中间差了一个验证环节。
那家客户就是这样。备份日志天天显示“成功”，但没人去验证。三个月前的一次底层存储故障，把备份文件写坏了，但RDS没报错，因为备份“流程”走完了。直到出事那天，才发现三个月的数据等于没备份。
第一条铁律：定期验证恢复，比备份本身更重要。
02 备份策略不是“全量+增量”就完了
数据库备份不是打开自动备份就完事，要回答三个问题。
问题一：全量备份多久一次？
RDS默认每天一次全量。数据量小，可以。数据量大（几TB以上），每天全量可能扛不住——备份时间太长，影响业务。可以改成每周全量 + 每天增量。
问题二：日志备份保留多久？
日志备份是实现时间点恢复（PITR）的关键。保留越长，能恢复到的时间点越细。但日志保留是有成本的，而且恢复时日志应用很慢。一般保留7-30天。超过30天的需求，用全量备份就够了。
问题三：备份保留多久？
核心业务：保留30-90天
一般业务：保留7-30天
合规要求：按行业规定（如金融7年）
分层存储：最近7天的备份放热存储（恢复快），7-30天的放温存储，超过30天的归档到冷存储（便宜，但恢复慢）。
03 恢复验证：别等出事才试
怎么验证备份可用？三个方法，按成本和可靠性排序。
方法一：抽检验证
每个月选一个非核心数据库，从备份恢复到一个临时实例，跑几条查询看看数据对不对。耗时1-2小时，成本低，能发现大部分问题。
方法二：自动化验证
写脚本，自动恢复最新备份到临时实例，跑数据校验，然后销毁实例。集成到CI/CD或定时任务里，每周自动跑。成本稍高，但能持续覆盖。
方法三：灾备演练
完整模拟一次生产故障：停止写入、从备份恢复、验证数据、切换流量。一年做1-2次，能发现流程和权限问题。
那家丢了数据的客户，后来每季度做一次完整恢复演练。第一次演练，从备份恢复到业务可用花了4小时。第二次2小时。第三次45分钟。现在他们敢拍胸脯说“30分钟内能恢复”。
04 时间点恢复：能回到过去，但有限制
时间点恢复（PITR）是RDS最强大的功能之一：能恢复到过去任意一秒的状态。
但有两个限制：
只能恢复到日志备份保留期内的时间点。比如日志只保留7天，那7天前的时间点恢复不了。
恢复时间取决于日志量。一天有几百GB日志，恢复可能要几小时。
最佳实践：核心业务日志保留至少7天。如果业务能接受丢失最多5分钟数据，日志备份频率设5分钟。设1分钟虽然丢得更少，但RDS性能开销更大。
反常识观点：时间点恢复不是无限回溯，也不是瞬间完成。 恢复前先算好要回到哪个时间点，评估恢复时间，别临时抱佛脚。
05 常见坑：你踩过几个？
坑一：只备份了数据库，没备份配置
数据库恢复了，但用户权限、参数组、告警规则都没了。RDS恢复实例时可以选择“连同参数组一起恢复”，但手动备份要留意。建议把数据库配置（IAM、参数组、告警）也纳入IaC管理。
坑二：跨区域备份成本被低估
开启跨区域备份后，存储费翻倍，还要付跨区域流量费。只对核心数据库开跨区域备份，一般的不用。
坑三：备份窗口和生产高峰重叠
RDS默认备份窗口是系统随机选的，可能正好是业务高峰。检查一下，挪到低峰期。备份期间IO会增加，对延迟敏感的业务有影响。
坑四：忘了加密备份
RDS备份默认和实例同加密状态。实例加密了，备份就加密。但手动快照要单独确认。检查：所有备份、快照、跨区域副本，加密是否都开了。
06 一个真实案例：备份救了他们，也差点害了他们
去年一个电商客户，促销期间误操作删了商品表。他们有RDS自动备份，日志保留7天，于是执行时间点恢复到删除前一秒。
恢复过程很顺利，数据回来了。但他们忘了一件事：商品表有自增主键，删除期间有新订单写入。恢复后的数据和新订单的主键冲突了。他们花了半天手工合并数据，促销页面挂了半天。
教训：恢复不是简单的“回到过去”，还要处理恢复期间的新数据。 设计恢复方案时，要把“恢复期间的增量数据怎么处理”想清楚。常见方案：恢复到一个新实例，然后和原实例做数据对比、合并，再切换。
写在最后
数据库备份这件事，平时看不见，出事才要命。但真到那时候，没人给你第二次机会。
那家丢了数据的客户，现在每个月跑一次自动化恢复验证，每季度一次完整演练。备份策略也改了：核心库开跨区域备份，日志保留30天，每年做一次归档。
安全负责人后来说了一句话：“以前觉得备份是买个保险，现在觉得备份是买个能赔的保险。能不能赔，自己说了算。”
你的数据库备份，上次恢复是什么时候？今天就可以试试。挑一个非核心库，从备份恢复到一个临时实例，看看数据对不对。用不了半天，但能让你今晚睡踏实点。
毕竟，数据丢了，才知道有多疼。
