做数据库运维的人，谁没在深夜里盯着屏幕发过呆？MySQL备份这事儿，看着简单，坑却一个比一个深。我见过太多人，白天自信满满地说“备份都做好了”，半夜数据库一崩，才发现备份文件不是损坏就是恢复不了。那种感觉，就像你明明带了伞，雨来了才发现伞是漏的。
备份到底要怎么做才靠谱？很多人第一反应是mysqldump，这工具确实经典，导出SQL文件，轻量又好理解。但它的软肋也很明显——数据量一大，导出慢得像蜗牛爬，恢复时更是灾难，一个几G的SQL文件往数据库里灌，搞不好要等几个小时。而且，mysqldump会锁表，线上业务高峰期你敢跑？客户那边正下单呢，你这边把表一锁，等着挨骂吧。所以，真正懂行的人，生产环境里很少单靠mysqldump，更多是拿它做小数据量的逻辑备份，或者配合其他方案。
那物理备份呢？直接拷贝数据库文件目录，速度快，恢复也快。但问题在于，你得保证拷贝的时候数据是一致的。MySQL在运行的时候，内存里还有没写进磁盘的数据，你直接cp文件，拿到的可能就是残缺品。这时候就得靠工具了，比如Percona XtraBackup，它能在不锁表的情况下做热备份，原理是记录下所有数据文件的变更，再加上二进制日志的配合，保证备份点的一致性。我有个朋友，公司电商网站每天几百万订单，用的就是XtraBackup每周全量、每天增量的方案，恢复时间控制在分钟级。
但备份不是存了就完事。我见过最夸张的案例，一家创业公司每天定时跑mysqldump，备份文件堆了半年，结果数据库崩了，恢复时才发现某个备份文件因为磁盘坏道已经损坏，而他们从来没验证过备份的可用性。所以，备份之后必须做恢复演练。这不是走过场，是真要找个测试环境，把备份文件完整恢复一遍，然后跑几个关键查询，确认数据没问题。频率至少一个月一次，核心业务系统最好每周一次。别嫌麻烦，等你真正需要恢复的时候，会发现这些演练就是救命稻草。
恢复策略也得提前想明白。很多人以为恢复就是把备份文件倒回去，实际上，你还要考虑恢复的时间点。比如你凌晨3点做了全量备份，中午12点数据库坏了，直接恢复凌晨的备份，那从3点到12点这9个小时的数据就全丢了。所以，必须结合二进制日志来做时间点恢复（PITR）。二进制日志记录着所有数据变更，你先把凌晨的备份恢复，然后从备份点开始，重放二进制日志直到崩溃前的那一刻。操作起来不算复杂，但需要提前把二进制日志保存好，别等出事了才发现日志已经被自动清理了。
说到清理，备份文件的保留策略也很关键。有人喜欢把备份存一堆，觉得越多越安全。结果磁盘空间很快被占满，新备份写不进去，旧备份又因为太旧恢复起来意义不大。合理的做法是，根据业务需求定保留周期。比如保留最近7天的每日全量备份，最近4周的每周备份，最近12个月的每月备份。超出周期的自动删除。这样既保证有足够的历史数据应对各种恢复场景，又不会浪费存储。还有，备份文件千万别和数据库放在同一台机器上，硬盘坏了，数据没了，备份也跟着没了，那才叫绝望。
异地备份这事儿，很多人觉得成本高，懒得搞。但你要想想，火灾、洪水、机房断电这些极端情况虽然概率低，一旦发生，本地备份全完蛋。我认识一个运维，公司数据中心在南方，夏天一场雷暴把机房搞瘫痪了两天，幸好他们有异地备份，从另一个城市把数据拉回来，业务才没彻底断掉。异地备份可以用工具自动同步，比如rsync或者专门的备份软件，关键是要保证网络带宽够，别让同步变成瓶颈。而且，异地备份的恢复流程也得演练，别到时候发现网络不通或者权限配错，干着急。
别忘了监控和告警。备份任务跑没跑成功，备份文件大小是否正常，这些都需要监控到位。我见过有人写脚本每天检查备份日志，发现报错就发邮件。但邮件经常被淹没在垃圾箱里，等发现的时候已经连续几天没备份成功了。更好的做法是用即时通讯工具的机器人告警，比如钉钉、企业微信、Slack，直接@负责人，逼着你去看。还有，备份文件的大小突然变小，可能是数据没导全，赶紧查原因。这种异常比直接失败更隐蔽，也更危险。
回到最根本的问题：你备份是为了什么？不是为了存文件，是为了在灾难发生时能快速恢复业务。所以，别把备份当成例行公事，每次调整数据库结构、升级版本、修改配置，都要重新审视备份策略是否还合适。比如你从单机切到了主从复制，备份策略就得调整，是不是可以利用从库做备份来减轻主库压力？你上了分库分表，备份是不是也要跟着拆？数据库在变，备份方案也得跟着变。这活儿没什么一劳永逸的解法，但只要你把“可恢复”当成唯一标准，每一步操作前都问一句“真要出事了，我能靠这个活过来吗”，至少能避开90%的坑。
