上周三凌晨两点，朋友老张给我发来一条语音，声音里带着明显的疲惫和无奈：“数据库崩了，备份文件居然也坏了，老板说三点前恢复不了就让我走人。”我问他什么类型的故障，他说是存储设备物理损坏，RAID卡故障导致数据丢失。我帮他远程看了一下，还好他公司用的是MySQL，而且启用了binlog，我让他从两天前的全量备份恢复，再重放增量日志，折腾到早上六点总算搞定。老张说这件事让他失眠了三天，也让他意识到：故障恢复不是等出了事再想怎么办，而是要在系统设计阶段就把“如果挂了怎么救”想清楚。
数据库故障恢复策略，说白了就是一套应急预案。但很多公司把它当成“备份脚本”或者“定期导出SQL文件”那么简单，这种想法太天真了。真实的故障场景五花八门：硬件坏了、网络断了、数据被误删了、系统升级出bug了，甚至还有被黑客删库跑路的。你不可能一个策略打天下。比如老张遇到的物理损坏，就得靠异地备份或者RAID冗余；如果是误操作删除了一张表，那得靠闪回或者时间点恢复（PITR）；要是机房断电导致文件系统损坏，那又得用到fsck或者第三方工具。每种场景下的恢复手段、耗时、数据丢失量都不一样，你得先搞清楚你面对的敌人是谁，才能选对武器。
我见过最离谱的案例，是一家电商公司把全量备份放在同一台服务器上。结果这台服务器磁盘阵列坏了，备份和源数据一起灰飞烟灭。这叫“把鸡蛋放在一个篮子里，篮子还放在悬崖边”。真正靠谱的备份策略，得遵循“3-2-1”原则：至少三份副本，两种不同存储介质，一份异地存储。举个例子，你可以每天凌晨在本地磁盘做一次全量备份，同时每6小时做一个增量备份，然后把全量备份同步到对象存储或者另一个机房。这样即使本地机房被水淹了，你还能从异地拉回数据。而且备份不是做完就万事大吉了，你得定期做恢复演练。很多公司备份文件一存就是半年，但从来没验证过能不能恢复。等真出事才发现备份文件损坏、格式不兼容、依赖的软件版本不对——这种教训我见过太多次了。
恢复速度也是个要命的问题。业务部门不会管你数据量有多大，他们只关心“什么时候能上线”。所以你得在恢复策略里明确目标：RTO（恢复时间目标）和RPO（恢复点目标）。RTO是多久能恢复业务，RPO是能容忍丢失多少数据。比如银行交易系统，RTO可能要求15分钟以内，RPO要求零丢失，那你就得用同步复制加自动切换的方案，比如Oracle Data Guard同步模式。但大部分中小公司没这个预算，RTO可以放宽到4小时，RPO容忍丢失1小时数据。那就用异步复制加定期备份就够了。别盲目追求“零丢失”，那意味着你要付出极高的成本和复杂度。你公司一年利润才几百万，花几百万买一套容灾方案，老板不骂你才怪。
说到具体技术选型，不同数据库的恢复策略差异很大。MySQL常用的就是全量备份加binlog，InnoDB的redo log还能保证崩溃时事务不丢失。PostgreSQL有WAL日志和连续归档，可以实现任意时间点恢复。MongoDB的副本集加oplog也能做到类似效果。但有一类场景特别棘手，就是大规模分布式数据库，比如TiDB或者CockroachDB。这些系统本身有Raft协议做多副本复制，节点挂了会自动切换，数据一致性有保证。但如果你不小心执行了一条错误的批量更新语句，比如把价格字段全体乘以0.5，那就得靠快照备份或者时间点恢复了。分布式系统恢复起来更复杂，因为要协调多个节点的状态，而且恢复过程中可能产生数据不一致的风险。
我去年帮一个游戏公司处理过故障：他们用阿里云RDS，DBA误操作删了一个核心表。他们没开闪回功能，也没做跨区域备份，只靠云平台的默认备份。结果默认备份保留7天，但恢复出来发现少了最近两天的数据。游戏玩家在论坛上骂翻了天，老板差点让DBA直接走人。后来他们痛定思痛，加了三个措施：一是开启RDS的闪回功能，可以回滚到任意SQL执行前的时间点；二是每天把备份文件同步到另一个区域的对象存储；三是写了一个自动化脚本，每天凌晨模拟一次小规模故障恢复。用他们CTO的话说：“花在备份上的每一分钱，都是给未来买的保险。”
说点实在的：故障恢复策略不是写一份文档放在共享文件夹里吃灰，而是要变成团队的操作习惯。我建议每季度做一次故障演练，模拟不同的场景：比如模拟硬盘损坏、模拟网络分区、模拟恶意删除。让团队在实际操作中磨合流程，发现文档里没写清楚的细节。演练完还要复盘，把流程优化到“傻瓜也能照着做”的程度。记住，真正的数据库高手不是在故障发生时临危不乱的那个，而是提前把“乱”的可能性降到最低的那个。你写再多策略，不如让团队真的跑通一次恢复流程。毕竟，数据不会说谎，它只会在你最自信的时候，给你一个响亮的耳光。
