上周五晚上十一点，朋友老张给我打电话，声音都快哭了。他公司数据库崩了，所有订单数据、客户资料全没了。运维小哥吓得手抖，老板在群里骂人，整个团队连夜从床上爬起来救火。老张问我能不能帮他恢复数据，我第一反应是：“你们有备份吗？”他说有，但备份文件也坏了。第二反应是：“你们有灾备方案吗？”他说有，但灾备服务器同步延迟了三个小时。这就尴尬了，备份和灾备都失效，就像买了保险，结果保险公司说保单是假的。数据库恢复方案平时没人当回事，真出事才发现，所谓的“恢复”根本不是点一下按钮那么简单。
很多人以为数据库恢复就是“把备份文件拷回去”，这是最大的误解。备份文件本身可能损坏、被加密，甚至版本不兼容。我见过一家创业公司，每周做全量备份，看起来很规范，结果数据库崩溃后，运维小哥发现备份文件是空的——因为脚本配置错误，备份命令根本没执行。更夸张的例子是某电商公司每天凌晨做增量备份，但增量日志只保留48 小时。数据库在第三天下午四点出问题，他们只能恢复到两天前的凌晨，丢失的几十个小时交易记录直接导致双十一活动数据全乱套。所以，真正的恢复方案不是“有备份就行”，而是“备份能恢复且恢复后数据完整”。这需要定期做恢复演练，就像消防演习，不能等火灾发生时才发现灭火器是坏的。
备份策略本身就有讲究。全量备份最安全，但耗时长、占用空间大，不适合高频业务。增量备份速度快、占用小，但恢复时必须从全量备份开始，逐个应用增量日志，一旦中间某个增量文件损坏，整个链条就断了。差异备份介于两者之间，恢复逻辑稍微复杂。很多公司图省事，只做一周一次的全量备份，结果遇到问题只能恢复到一周前，期间的数据全丢了。对银行、电商这种高频交易业务来说，哪怕丢失一分钟数据都可能造成重大损失。正确的做法是“全量+增量+差异”组合，并根据业务重要程度设定不同的备份频率：核心数据库每15 分钟做一次增量备份，次核心每小时一次，非核心每天一次。这样即使出问题，最多也只会丢失15 分钟的数据。
备份文件的存储位置也是个坑。很多人把备份文件和数据库放在同一台服务器上，觉得方便，结果服务器硬盘坏了，数据库和备份一起报销。还有公司把备份放在本地 NAS 上，机房漏水、火灾、断电时备份同样会完蛋。靠谱的做法是“异地多活”存储：本地磁盘一份、同城另一机房一份、异地云存储一份。这样即便某个机房被雷劈，其他地方还有备份。另外，备份文件要加密存储，防止泄露。我认识一家金融公司，备份文件没有加密，运维人员离职前拷走了所有客户数据并卖给竞争对手，教训非常惨痛。
备份文件定期做恢复测试，这个环节90 %的公司都没做。备份文件是否完整、恢复流程是否顺畅、恢复后数据是否一致，这些不测试根本不知道。我帮一家物流公司做恢复演练时发现，他们的备份文件在恢复过程中报错，因为数据库升级后，备份文件使用了旧版格式，新版数据库不兼容。还有一家医疗公司，恢复后数据校验发现部分字段丢失，因为备份脚本漏掉了某些表。这些问题在演练时发现还能补救，真正出事时就只能祈祷了。因此，建议每个月至少做一次恢复演练，包括全量恢复和增量恢复，并验证恢复后数据是否完整、业务能否正常运转。
恢复方案还要考虑时间成本。不同恢复策略的时间差异巨大。全量备份恢复可能需要几个小时甚至十几个小时，增量恢复时间取决于日志数量和大小。对业务连续性要求高的公司来说，恢复时间越长，损失越大。比如电商平台，宕机一小时可能损失几百万。所以，恢复方案要明确 RTO（恢复时间目标）和 RPO（恢复点目标）。RTO 决定你多久能恢复业务，RPO 决定你最多能丢失多少数据。对核心业务，RTO 最好控制在 30 分钟内，RPO 控制在 5 分钟内。这需要投入更多硬件和运维资源，但与业务损失相比，这些投入是值得的。
灾备方案和恢复方案是两回事。很多人把灾备等同于恢复，实际上灾备只是恢复的前置条件。灾备是指随时可用的备用环境，恢复是把数据和应用迁移到备用环境。有些公司做了双机热备，以为万事大吉，结果主库崩溃后，备用库虽然自动切换，但数据比主库落后十分钟，这十分钟的交易全丢了。更麻烦的是，备用库的配置和主库不完全一致，切换后某些功能无法正常使用。因此，灾备方案不仅要保证数据同步，还要定期做切换演练，确保备用环境能够真正接替主库工作。
数据库恢复方案涉及成本和风险的权衡。全量备份 + 异地灾备 + 定期演练，这套方案下来，硬件、带宽和人力成本都不低。小公司可能承受不起，但也不能不做。折中方案是：核心数据库做异地多活，非核心数据库做本地备份并定期恢复测试。同时，利用云服务的自动备份和灾备功能，成本相对可控。但要注意，云服务商的备份和恢复功能未必完全满足你的需求，例如有的云服务只能恢复到整库级别，无法做单表恢复。购买云服务时，一定要弄清楚其恢复能力的边界。
说一句，数据库恢复方案不是单纯的技术问题，而是管理问题。很多公司出事后才发现，根本症结在流程和意识上。备份脚本没人维护、恢复演练没人执行、运维人员对恢复流程不熟悉，这些才是真正致命的点。我见过一家公司，数据库崩溃后，运维小哥花了四个小时才找到备份文件的存放位置，因为他平时只管备份，没想过怎么恢复。所以，建议把恢复方案写进运维手册，定期培训，让每个运维人员都熟悉恢复流程。毕竟，数据库恢复这种事，平时可能一辈子用不上，但一旦用上，就必须万无一失。
