数据库灾备；能恢复才算真备好

备份任务天天跑，监控一片绿，真出事那天打开备份目录，才发现能用的东西不多。这场景我见过不止一次，有的是文件解不开，有的是解开了但库里少了半张表的数据。数据库灾备这四个字，很多人第一反应就是“备份有没有在跑”，可备份只是前半程，能不能把库拉起来、拉起来之后数据对不对，才是一条线能不能过去的关口。

数据库灾备的分水岭在恢复，不在备份

备份是动作，恢复是结果。这两件事在系统里常被当成一件，因为脚本写完会返回一个成功，任务管理器里就是绿色的。可这个成功只代表 dump 进程正常退出，不代表文件完整、不代表版本匹配、不代表目标机器装得下、也不代表账号权限够用。我见过备份把 / 分区撑满，后面几天的备份全失败，告警埋在邮件里没人翻。等真正要用的时候，手里躺着的是几天前的半截文件。

备份文件不真恢复一次，等于没验证

验证这件事没什么技巧，就是老老实实起一个临时实例，把文件导进去。mysql < backup.sql，或者解压 xtrabackup 的物理备份，然后看几样东西：表数量对不对，关键业务表的自增 ID 和主库差多少，字符集和排序规则有没有变，视图、存储过程、触发器这些非表对象在不在。mysqldump 默认不带存储过程和触发器，加个 –all-databases 就以为万事大吉的人不少，参数还是得逐条看。这些检查每一条都不复杂，问题是没有任何一条能被“备份成功”四个字替你回答。

数据库灾备最贵的成本是时间，不是硬盘

老板问的从来不是备份存在哪，是“多久能恢复”和“会丢多少”。方案里写成 RTO 和 RPO，说人话就是一个是停机时长，一个是数据缺口。一个几十 G 的库，全量恢复加上索引重建、配置修正、业务侧验证，几个小时打不住，而硬盘一年也没多少钱。预算该花在哪，得看业务能忍多久。有些日志表丢两小时无所谓，订单表丢十分钟就要出事，那就别拿一套策略套所有库。

全量、增量、binlog，别只留一层

常见做法是每周一次全量，每天一次增量，binlog 留着做按时间点恢复。三层作用不一样：全量是地基，增量省时间，binlog 能把你捞到某条误操作语句之前。麻烦在于保留周期和版本一致性。历史版本别只留最近一份，误删的数据可能要回到更早的时间点；跨版本恢复比如从低版本导进高版本，得先走升级流程，直接倒进去报的错五花八门，字符集、认证插件、系统表都可能卡人。

演练别在脑子里过一遍

演练最容易走形式，几个人对着架构图说“到时候切到备库就行”，说完各自散了。像样的演练得有人打开终端，按文档一步步做，中途把不认识的密码、找不到的配置文件、联系不上的负责人全暴露出来。文档要写清楚谁有权限、去哪拿密钥、恢复完怎么通知业务方、回切怎么做。人一紧张准漏步骤，靠记忆不如靠一行一行的清单。

异地不是万能，先看复制延迟

加了异地机房不等于高枕无忧。主从复制的延迟是个活的东西，写压力大的时候 Seconds_Behind_Master 会往上跳，跨地域网络抖一下也跳。真到切换那一刻，从库可能比主库少一截，业务方看到订单号对不上，问题就从“数据库挂了”变成“数据对不上”，后者更难收场。所以切换前得有个判断：这点延迟能接受多少，超过阈值是不是宁可只读也不切。半同步、组复制各有取舍，具体参数和适用场景以官方文档说明为准，别照着别人的博客配一遍就上生产。

备份别和库放同一个篮子

这条老生常谈，但依然有人这么干：备份文件写在库所在的机器上，同一块盘、同一个机房、同一个账号密码。机器一坏、盘一挂、勒索软件一进来，库和备份一起没。备份目录的权限也要单独管，能删备份的账号不该和跑业务的账号是同一个。备份要不要加密、密钥放哪，同样得提前定，一堆加密文件在手却找不到密钥，跟没备份差别不大。

小团队能落地的几件事

不用一上来就搞复杂架构。先把备份任务的失败告警接到一个真有人看的地方；每季度挑个非高峰时段，把生产备份恢复到临时机器上，跑一遍关键业务查询；把恢复步骤写成文档，让没参与搭建的人照着做一次；保留周期至少覆盖一个完整业务周期，大促、批量导入、上线变更之前手动补一份全量；灾备负责人写清楚一个正主一个备份，别写成“运维组”三个字。

下次备份跑完，别急着关窗口，随手起个临时实例导一遍。花不了多少工夫，但真出事那天，你能少掉一层冷汗。