干我们这行的，最怕半夜被电话吵醒。不是别的，就是数据库挂了，数据丢了。那种感觉，比失恋还难受。MySQL作为最流行的开源数据库，承载了无数公司的核心业务，但真正把备份恢复当回事儿的人，十个里面找不出三个。很多人觉得“我数据量不大，不用备份”，或者“有主从复制就够了”，等到真要恢复的时候，才发现自己连备份脚本都没写过。
先说最基础也最常用的逻辑备份工具——mysqldump。这东西用起来简单，但坑也不少。很多人直接就完事了，这在数据量小、业务低峰期没问题。可一旦数据量上了G，或者业务是7×24小时在跑，这种粗暴的方式就会带来两个问题：一是备份过程中锁表导致业务阻塞，二是恢复的时候耗时极长。正确做法是加上参数，这个参数对InnoDB表特别友好，能在不锁表的情况下获得一致性快照，配合和（如果你用GTID复制的话），基本能应对大多数场景。
但mysqldump有个天生的短板——它是逻辑备份，恢复速度慢。假设你有个50G的库，mysqldump出来的SQL文件可能就有60G，恢复的时候得一行一行执行，运气好半小时，运气不好两小时。这时候就得请出物理备份工具了，比如Percona XtraBackup，或者MySQL官方的Clone Plugin。物理备份直接复制数据文件，恢复速度比逻辑备份快一个量级。XtraBackup的用法也不复杂，一条就能搞定全量备份，增量备份用指定上一次备份目录就行。
不过说句实在话，工具只是术，真正的道在于备份策略的设计。你得想清楚三个问题：备份频率多高？保留几份？存在哪里？我见过太多公司，备份脚本是写了，但备份文件全放在同一台机器的同一块磁盘上，结果磁盘坏了，备份和主库一起完蛋。正确的做法是异地备份，至少要搞个OSS或者S3，定时把备份文件上传上去。至于保留策略，全量备份每周一份，增量备份每天一份，至少保留两周，这个算是最低配置了。
说完备份，再说恢复。恢复比备份难十倍，这话一点不夸张。备份是流程化操作，恢复是实战演练。很多人备份做得挺勤快，但从来没测过恢复，等到真要恢复的时候，才发现备份文件是坏的、或者缺了某个binlog、或者权限不对。所以我的建议是，每个季度至少做一次恢复演练，从零开始搭一个临时实例，把备份导进去，看看能不能正常启动、数据是否完整。这个习惯能救你的命，真的。
还有个细节很多人忽略——binlog。binlog是MySQL的二进制日志，记录所有数据变更操作，它是增量备份和基于时间点恢复的核心。如果你只做全量备份，不做binlog归档，那最多只能恢复到备份时刻的状态，备份之后的数据全丢了。正确做法是开启参数，并且把binlog也同步到异地。恢复的时候，先恢复全量备份，再用工具把binlog里的增量操作补上去，这样就能恢复到任意时间点。当然，这需要你平时把binlog管理好，按天归档，别让它无限增长撑爆磁盘。
再聊聊自动化。手工备份最大的问题不是懒，是忘记。人总会犯错的，服务器可不跟你讲情面。所以一定要写脚本，用crontab定时执行，每次备份完自动检查备份文件大小、校验完整性，然后推送到远端。脚本里要加日志，记录备份开始时间、结束时间、耗时、文件大小，方便排查问题。如果公司有运维平台，最好接入告警，备份失败就发钉钉或者短信通知。别嫌麻烦，真出事的时候你会感谢这些“麻烦”。
说一个很多人会踩的坑——备份恢复后的数据一致性检查。你恢复了数据，不代表数据就是对的。比如你用mysqldump备份的时候没加，备份过程中有写入，那恢复出来的数据可能就是脏的。还有，如果你用了MyISAM表，它不支持事务，备份的时候锁表是必须的，否则数据就是乱的。恢复完成后，一定要做数据校验，比如跑一下，或者对比一下关键表的行数，别等业务跑起来才发现数据不对，那时候哭都来不及。
MySQL备份恢复这活儿，说难也难，说简单也简单。难的是细节，简单的是方向。你只要把全量备份、binlog归档、异地存储、定期演练这几件事做到位，基本上就能应对99%的场景。剩下的1%，交给运气。但运气这东西，从来不眷顾没准备的人。把这篇文章收藏起来，回头把你现在的备份方案对照着检查一遍，该补的补，该改的改。别等到半夜被电话吵醒，才想起来今天这篇文章。
