我刚入行那会儿，带我的老DBA说了一句话，到现在都记得：“数据库崩了不可怕，可怕的是你不知道怎么把它救回来。”这话糙理不糙。做数据库运维的，谁没经历过几个惊心动魄的夜晚？系统挂了、磁盘坏了、人为误操作了，这时候能不能把数据捞回来，靠的不是运气，是平时对日志和备份策略的理解。说白了，数据库恢复的基础就两条腿走路：一条是日志，一条是备份。你这两条腿站不稳，恢复就是空谈。今天咱们就掰开揉碎聊聊，这俩东西到底怎么撑起数据库恢复的底气。
先说日志。很多人觉得日志就是个记录工具，没啥技术含量。可真到了恢复场景，你才发现日志才是真正的“时光机”。数据库里常见的日志分两种：重做日志和回滚日志。重做日志记的是你做的每一次修改，比如你更新了一条记录，数据库先把操作写到日志里，再改数据文件。这么做的目的是啥？万一数据文件写一半断电了，系统重启后，它能靠重做日志把没写完的操作补上，保证数据不丢。回滚日志则相反，它记录的是修改前的旧值，用来支持事务回滚。比如你执行了一个事务，中间出错了，数据库能靠回滚日志把数据恢复到修改前的样子。这两种日志配合起来，构成了数据库恢复的基础机制。没有日志，你就像在黑夜里走路，摔了都不知道怎么爬起来。
但光有日志不够，日志本身不是万能的。你想象一下，如果数据库运行了一整年，重做日志积累了海量数据，这时候系统崩了，你要从日志里恢复所有操作，那得等到猴年马月去？这就是备份存在的意义。备份相当于给你的数据库拍了一张“快照”，把某个时间点的完整数据保存下来。常见的备份方式有全量备份和增量备份。全量备份就是把整个数据库一股脑全拷出来，优点是恢复起来快，缺点是占空间、耗时间。增量备份只备份自上次备份以来修改过的数据，速度快、体积小，但恢复起来得一层层叠加上去，比较麻烦。聪明点的DBA会组合使用，比如每周做一次全量备份，每天做一次增量备份，这样既节省资源，又能在恢复时快速定位到最近的时间点。
说到备份策略，很多人容易犯一个错误：只备份，不验证。我见过不止一个团队，辛辛苦苦搭了备份脚本，定时跑了好几个月，结果真出事了，恢复出来的数据是坏的。为什么？因为备份文件可能损坏，或者备份过程中出了错，但没人发现。所以好用的备份策略必须包含验证环节。每次备份完成后，自动校验一下文件完整性，甚至定期做一次恢复演练，模拟真实故障场景。别嫌麻烦，这种“脱裤子放屁”的举动，关键时刻能救命。还有一个容易被忽略的点：备份要异地存储。如果机房着火了、硬盘阵列全坏了，你备份和主库放一起，那就真叫“一锅端”。所以至少要把备份放到另一个物理位置，甚至上云。
接下来聊一个实战中特别容易踩的坑：日志和备份的配合时机。很多人以为只要做了全量备份，恢复时就万事大吉了。其实不然。假设你凌晨2点做了全量备份，系统在上午10点崩溃了。这时候你用全量备份恢复，只能恢复到凌晨2点的状态，中间8个小时的数据全丢了。怎么办？这时候就需要日志来补。如果你开启了归档日志模式，数据库会把所有修改操作都记录到归档日志里。恢复时，先加载全量备份，再依次应用从凌晨2点到上午10点之间的归档日志，就能把数据恢复到崩溃前的一刻。这就是所谓的“时间点恢复”。但注意，归档日志不能无限保留，否则磁盘会被撑爆。所以你需要根据业务容忍度，设定日志保留期，比如保留7天或30天，既保证恢复能力，又控制存储成本。
说到时间点恢复，还有一层更深的逻辑：日志的有序性和原子性。数据库恢复时，日志必须严格按时间顺序应用，不能跳跃，否则数据会乱套。这个特性在分布式数据库里尤其重要。比如你有一个主库和多个从库，主库写日志，从库同步日志。如果主库崩了，你要从从库恢复数据，就得确保从库的日志应用顺序和主库完全一致。万一某个从库的日志因为网络延迟少了一段，恢复出来的数据就是错的。所以很多数据库系统会引入“全局事务ID”或“日志序列号”，用来标记每一条日志的全局顺序。恢复时，系统会检查所有节点的日志序列号，确保大家对齐到同一个时间点。这个过程叫“一致性恢复”，是数据库高可用架构的基石。
还有一点容易被忽视：日志和备份策略要跟业务场景匹配。不同业务对数据丢失的容忍度不一样。比如银行交易系统，丢一分钱都可能出大事，那你就得用“同步复制+实时归档”的策略，确保每次写入都同时写到主库和备份，日志也实时同步到异地。这种配置下，恢复点目标能接近零，但代价是性能损耗大、存储成本高。反过来，一个内部论坛或者日志分析系统，丢几小时数据无伤大雅，那你可以用“异步复制+每日全量备份”，省资源又省心。所以不要盲目追求所谓的“最佳实践”，先问自己：业务能接受丢多少数据？能接受停多久？这两个数字直接决定了你的日志和备份策略该怎么设计。
说一句实在话：数据库恢复这件事，技术层面其实不难，难的是你在事故发生前就想清楚每一步。日志和备份策略就像你给数据库买的保险，平时看不见摸不着，但出险的时候，保单条款写得清不清楚，直接决定你能不能拿到赔款。别等到系统挂了才去翻文档，也别指望靠“人品”扛过故障。把日志和备份的机制吃透，再根据业务场景搭一套合理的策略，定期演练验证，这才是数据库恢复的真正底气。记住：恢复不是玄学，是科学。你准备得越充分，翻车的概率就越小。
