前两天跟一个做电商的朋友吃饭，他跟我吐槽，说凌晨三点被电话吵醒，数据库崩了，订单表全没了。他当时第一反应是找备份，结果发现上周的备份文件还是坏的。那一刻他跟我说，感觉天都塌了。我问他有没有开binlog，他说什么是binlog。这顿饭吃完，我觉得有必要写点什么。数据库恢复这事儿，说穿了就两个词：冗余备份，日志重放。听起来跟IT术语似的，但本质就跟咱们过日子一样——你得有存粮，还得记得粮食放在哪儿、怎么吃。
先说冗余备份。很多人觉得备份就是定期把数据库导出成文件，存到某个硬盘里，完事儿。但真正的冗余备份，讲究的是“冗余”这两个字。什么意思？就是你不能只有一条活路。我的一个做运维的朋友，他们公司做过一次演练，把主库的物理备份、从库的逻辑备份、还有云上的快照全列出来，结果发现三个备份放在同一个机房。那机房后来因为施工断了电，三个备份全趴窝。冗余备份的核心不是“有备份”，而是“备份之间要互相独立”。你存一份在本地，就得再存一份在异地；你做了物理备份，就得再留一份逻辑备份。就像你出门带钥匙，不能只带一把，也不能把备用钥匙藏在同一个兜里。
但光有备份够不够？不够。因为备份是“点”的概念，它是某个时间点的快照。你凌晨三点做的备份，那备份完之后的两个小时里，系统又写了几万条记录，这些记录在备份文件里根本没有。这时候就需要日志重放。日志是什么？是数据库自己记账的本子，每一笔操作，不管是插入、更新还是删除，它都记下来。出了事儿，你就拿备份把数据库恢复到凌晨三点，再把三点之后的日志一条条重放，把记录补回去。这个过程听起来简单，但实际操作中，日志重放最考验人的是细节。
我见过一个案例，某公司数据库崩溃后，技术团队找到了备份，也找到了日志，但恢复出来的数据对不上。查了半天，发现是日志的时间戳和备份的时间点之间有重叠——备份文件生成的那几秒钟里，数据库还在写日志，结果有些操作在备份里已经有了，又在日志里重放了一遍，数据就重复了。这种问题，靠的就是对日志序列号的精确认知。所以日志重放不是像放电影那样按个播放键就完了，你得搞清楚日志的起点、终点、还有和备份之间的衔接点。这就像拼图，备份是底图，日志是碎片，你得把碎片对准位置放进去，而不是随便往上糊。
说到这儿，得提一个很多人会犯的错：备份和日志分开管理。有的团队，备份归DBA管，日志归运维管，出了事故，两边互相扯皮，说对方的文件不全。但数据库恢复这事儿，备份和日志是一个整体，缺了哪个都不行。你备份做得再好，没有日志，恢复只能回到备份那一刻，之后的数据全丢；你日志记得再全，没有备份，日志就没法重放，因为重放需要一个基态。所以好的系统设计，一定是把备份和日志的生成、存储、校验放在同一个流程里，甚至同一个脚本里。我见过一些成熟的做法，备份完之后自动校验日志的连续性，确保这两者能对得上。
还有一个实操里的坑，就是“备份成功了”不等于“备份可用”。很多团队只关注备份任务跑没跑完，却很少做恢复演练。我认识一个技术负责人，他每个月都会做一次“灾难日”，就是把数据库弄到一台全新的机器上，用备份和日志完整恢复一遍，看看能不能跑起来。他跟我说，第一次做的时候，发现备份文件里有坏块，日志也有断档，问题一大堆。但正因为每月演练，真出事那天，他们只用了四十分钟就恢复了。而那些从不演练的团队，往往在事故现场才第一次尝试恢复，结果打开备份文件，发现格式不对、版本不兼容、甚至是加密密钥丢了。备份不是做给人看的，是拿来救命用的，你不试，就永远不知道它能不能救命。
回到开头那个朋友。后来我帮他理了一下思路：第一，检查现有的备份策略，把全量备份和增量备份分开，全量每周一次，增量每天一次；第二，开启binlog，确保日志从备份的准确时间点开始记录；第三，把备份文件复制到两个不同的存储位置，最好是跨地域的；第四，每个月做一次恢复演练，把恢复时间控制在半小时以内。他听完说，原来数据库恢复不是靠运气，是靠这些基础工作堆出来的。我点头，确实是这样。
数据库恢复的基础是什么？冗余备份是你的底气，日志重放是你的精度。底气保证你不至于归零，精度保证你能回到事故发生前的那一刻。这两样东西，缺一个，恢复就是碰运气；两个都有，恢复就是走流程。你可能会觉得这些道理说起来简单，但真正做到位的团队，十个里面可能只有两三个。剩下的，都是在事故之后才想起“备份”和“日志”这两个词。
所以，如果你现在负责一个数据库，或者将来要负责，不妨今天就打开你的备份系统看一眼：备份文件在哪儿？日志有没有开？上次恢复演练是什么时候？这三个问题，答不上来任何一个，都说明你的系统还处于“裸奔”状态。冗余备份加日志重放，听起来是技术问题，其实是管理问题——你有没有把恢复当作一个必须验证的流程，而不是一个碰运气的预案。备份不冗余，恢复就冒险；日志不完整，恢复就缺角。这两条腿，缺一条，你站不稳。
