数据库备份这事儿，说起来挺枯燥的，但真出了事，能把人急哭。我见过太多开发团队，平时对备份方案爱答不理，等到某天误操作删了表，或者硬盘突然挂了，才手忙脚乱地翻文档。更惨的是，翻出来发现备份策略根本不对——要么备份文件损坏，要么恢复流程压根没验证过。MySQL 作为最常用的开源数据库，它的备份恢复方案其实没那么复杂，但关键是要弄清楚业务到底需要什么。比如一个电商网站，凌晨两点丢了五分钟数据，可能就损失几十万订单；而一个内部论坛，丢了一天数据也无所谓。所以，备份方案不是技术选型的问题，而是风险定价的问题。
先聊聊最基础的逻辑备份，也就是用 mysqldump 这种工具把数据导出成 SQL 文件。这个方法好处是简单直观，导出来的文件能直接查看，还能按表拆分。但坑也不少：如果数据库有几百 GB，mysqldump 会把整个库锁住或使用事务隔离，生产环境里这么搞，业务直接卡死。而且恢复时得一条条执行 SQL，速度慢得让人抓狂。我有个朋友，公司库是 1.2 TB，用 mysqldump 导了六个小时，恢复用了三天，中间还因为字符集问题报错。所以逻辑备份更适合数据量小、对恢复时间不敏感的场景，比如测试库或每天只跑一次报表的小系统。真要上生产，得搭配其他方案。
物理备份是更狠的路子，直接拷贝数据库的底层文件。像 XtraBackup 这种工具，可以在线热备，不锁表，速度还快。原理挺巧妙：它先记录当前数据文件的快照，同时捕捉这段时间的 binlog 变化，把这两部分拼起来。这样备份出来的文件，恢复时直接拷贝回去，再应用增量日志，数据库就回来了。我见过一个案例，某视频网站用 XtraBackup 每天做全量备份，每半小时做增量备份，恢复时全量加增量，一个小时内就能把 2 TB 的库恢复出来。但物理备份也有门槛——操作系统和 MySQL 版本必须一致，否则文件格式不兼容会直接崩掉。而且恢复过程需要手动操作，一步出错就完蛋。
现在很多团队喜欢用 binlog 做细粒度的恢复。binlog 是 MySQL 的二进制日志，记录了所有数据变更。如果你有全量备份，再加上 binlog，理论上可以把数据库恢复到任意时间点。比如上午十点全量备份，下午三点误删了表，那就把全量恢复，然后应用十点到三点之间的 binlog，跳过删除的那条 SQL，数据就救回来了。这个方案特别适合对数据一致性要求高的场景，比如金融系统。但 binlog 的坑在于日志文件会越堆越大，如果不定期清理，磁盘会被撑爆。而且 binlog 的解析和回放需要脚本支持，手动操作很容易出错。我见过一个 DBA 为了恢复一条记录，逐条翻 binlog，翻了两个小时才找到，结果发现那条 SQL 被事务包裹，已经回滚。
备份恢复里还有个容易被忽略的环节：恢复演练。很多公司备份做得勤快，但从未真正恢复过。等到出事了，才发现备份文件是坏的，或者恢复流程根本跑不通。我认识的一位运维总监，每周五下午强制团队做一次恢复演练：从备份机拉数据，到新实例上恢复，再验证数据一致性。刚开始大家觉得浪费时间，但半年后真遇到一次磁盘阵列故障，恢复流程跑了三十分钟就搞定，旁边的团队还在手忙脚乱地查文档。所以，备份方案里一定要加入定期演练，而且演练要模拟真实故障，比如突然断电、网络中断、主库崩溃，这样才有效。
备份存储也是个大学问。很多人觉得备份文件丢在本地磁盘就行了，但本地磁盘一旦坏了，备份和数据一起完蛋。合理的做法是把备份文件异地存储，比如上传到对象存储或另一台服务器。但异地存储要考虑网络带宽和传输时间，比如每天凌晨三点开始传，如果文件太大，传不完就会影响第二天备份。我见过一个团队用 rsync 增量同步，每天只传变化的部分，效率高了很多。另外，加密也是必须的——备份文件里可能有用户手机号、身份证等敏感数据，如果不加密，泄露就是合规事故。建议用 GPG 或 openssl 对备份文件加密，密钥单独保管。
还有一个实战技巧：备份任务要错开业务峰值。很多公司习惯凌晨两点跑备份，因为那时是业务低谷，也是系统维护窗口。如果备份太慢，占用了磁盘 I/O，会影响其他任务。我见过一个案例，某游戏公司凌晨三点开新服，结果备份任务还在跑，导致新服数据库响应慢，玩家骂声一片。后来他们把备份时间改到凌晨五点，避开维护窗口，问题就解决了。另外，备份期间要监控磁盘空间和 CPU 负载，防止备份任务把系统拖垮。可以在 crontab 加个检测脚本：如果负载超过 80%，就暂停备份，等负载降下来再继续。
聊点实在的：别迷信任何一套方案。MySQL 备份恢复没有银弹，关键是根据业务场景组合使用。比如核心交易库，用物理全量备份加 binlog 增量——每天一次全量、每 15 分钟一次增量，恢复时间控制在半小时内；而日志分析库，用逻辑备份每周一次全量就行，丢了也无所谓。备份文件要保留多个版本，至少三天内的全量加最近一天的增量，这样即使某次备份坏了，还能用前一天的。最重要的是，把备份恢复方案写成文档，贴在团队 Wiki 上，让每个开发都知道怎么操作。别等出了问题才去翻 GitHub 上的技术文章，那时候黄花菜都凉了。
