上周我帮一个做电商的朋友处理数据库崩溃，他急得满头大汗，后台订单数据全没了，连库存表都打不开。我赶紧拿出备份文件，用几条命令把数据恢复回来，前后不到十分钟。他愣了半天，说这要是没备份，公司直接关门算了。这事让我想起很多人对MySQL备份的态度——平时觉得用不上，真出事才知道这东西比啥都重要。
备份这件事，说白了就是给数据买份保险。你每天往数据库写几千条订单、几万个用户信息，哪天真出个硬件故障或者误操作删表，没备份就只能干瞪眼。MySQL自带的mysqldump工具就是最基础的保命手段。比如你要备份整个数据库，一条命令搞定：。这命令会把所有数据库的结构和数据全倒出来，存成一个SQL文件。我习惯在凌晨三点跑个定时任务，用crontab每天自动执行一次，文件按日期命名，比如，这样哪天出问题都能找到对应的版本。
不过光用mysqldump还不够，尤其数据库大的时候，几百万行数据导出来可能要好几分钟，这段时间里用户还在往里面写数据，备份出来的文件可能就不一致了。这时候得用选项，对InnoDB表来说，这能保证备份时看到的是某个时间点的快照，不会因为同时写入数据而出错。我见过有人没加这个参数，恢复后发现订单表里少了两分钟的数据，排查了半天才找到原因。
恢复操作其实比备份更考验人。很多人以为拿到备份文件直接跑就完事了，但实际情况往往更复杂。比如你只误删了一张表，恢复整个库会覆盖掉其他正常的表，反而造成更大的损失。正确做法是先确认要恢复的范围，然后建个临时库把备份导进去，再从临时库里把那张表单独抽出来。像这样：，接着，用工具或者直接写查询把需要的表数据导出来。
还有一种更精细的恢复场景，比如你昨天下午三点误删了一批数据，但备份是凌晨做的，那恢复后这十几个小时的增量数据就全丢了。这时候binlog就派上用场了。MySQL的二进制日志记录着所有数据变更，你可以先恢复全量备份，再重放从凌晨到现在这段时间的binlog，就能把数据恢复到误操作前的那一刻。命令大致是。这个技巧我教过好几次，每次对方都惊叹原来还能这么玩。
很多人问我要不要用图形化工具，比如phpMyAdmin或者Navicat，这些确实方便，点几下鼠标就能备份恢复，但有个致命问题——它们底层调用的还是mysqldump和mysql命令，如果网络中断或者浏览器卡死，备份可能只写到一半。我在生产环境从不用图形工具，宁可多花几分钟写个脚本，确保每一步都可控。写脚本时还得注意文件权限，备份文件里包含敏感数据，存到服务器上得设成600权限，别让其他人随便看。
备份策略上我建议分层处理。核心业务库每天全量备份，保留最近7天；日志类或者不重要的库每周全量备份，保留一个月。同时搭配binlog实现增量恢复，这样既能节省存储空间，又能把数据丢失的时间窗口缩到最短。有人图省事只做全量备份，结果硬盘满了才发现备份失败，这种事我见得太多了。定期检查备份文件完整性也必不可少，比如用验证备份文件能不能正常导入，别等到要恢复时才发现文件是坏的。
说句实在的，再完美的备份方案也抵不过人为疏忽。我有次调试时忘了关自动清理脚本，把当天的备份文件删了，还好前一天的文件还在，只损失了十几个小时的增量数据。从那以后我养成了个习惯：备份文件不光存本地，还得上传到远程存储，比如云对象存储或者另一台服务器，异地容灾。这样就算机房着火，数据也能从另一个地方拿回来。数据库备份这事，你花百分之五十的精力去设计方案，剩下百分之五十得用来防自己犯蠢。
