我有个朋友，是小公司的技术负责人。上周半夜他给我打电话，声音带着哭腔——他们的电商数据库因为一次误操作把用户订单表清空了。整整三天没有备份，只能从日志里一点一点往回捞数据，折腾到天亮才找回七成。他跟我说，那时候真想抽自己一巴掌。其实这种事在圈里太常见了，平时觉得备份无所谓，真出事才知道有多要命。MySQL 是中小公司最常用的数据库，备份和恢复不能光靠“记得”两个字，必须有一套实实在的流程，并且要反复演练，才靠谱。
先聊聊备份最核心的原则：3‑2‑1 法则。三份备份、两种介质、一份异地，听起来简单，真正落地时很多人就糊弄了。我见过最典型的坑是，只把备份文件放在数据库服务器同一个硬盘上，以为做了 mysqldump 就万事大吉，结果硬盘坏了，备份连同数据一起报销。另一个常见情况是，备份脚本写好了，却从未验证过能否恢复。曾有客户每周做一次全量备份，坚持了半年，真正需要时恢复出来的数据全是乱码——备份时字符集没对齐。所以备份文件不是存了就完事，必须定期做恢复演练，哪怕一个月一次，也能发现很多隐藏问题。
说到具体工具，mysqldump 绝对是入门首选，用起来简单，一句命令就能把整个库倒成 SQL 文件。但它有个硬伤：对大库来说太慢。我处理过一个 500 GB 的电商库，用 mysqldump 导了整整 6 小时，中间还因为网络波动断了两次。这时就需要物理备份工具，比如 Percona XtraBackup，它直接复制数据文件，速度快得多，而且支持在线备份，不影响业务读写。不过物理备份也有门槛，恢复时要保证数据目录权限和 MySQL 版本一致。建议小库用 mysqldump 图省事，超过 100 GB 的库则使用物理备份，省得半夜等得心焦。
备份策略要根据数据的重要性和变化频率来定。我见过最笨的做法是每天做一次全量备份，结果磁盘空间三天就爆了。更聪明的做法是：全量备份一周一次，增量备份每天一次，二进制日志实时开启。增量备份只记录变化的部分，效率高很多。比如周一凌晨做全量，周一到周五每天凌晨做增量，周末再合并一次。但要注意，增量备份依赖全量备份的完整性；如果全量备份损坏，后面的增量全都白费。所以每次全量备份完成后，我都会立刻验证一下，至少把核心表恢复出来检查数据是否正确。
恢复操作是真正考验人的时候。我分享一个真实案例：某家公司业务系统挂了，需要把数据库恢复到昨天下午 3 点的状态。他们手头有昨天凌晨的全量备份和今天凌晨的增量备份，但中间还有 16 小时的二进制日志。恢复流程是：先恢复全量备份，再应用增量备份，最后用 mysqlbinlog 把二进制日志里从昨天凌晨到今天凌晨的变化全部回放。这一步最坑的是，二进制日志里包含了所有操作，包括导致事故的错误操作。因此在回放前必须找到误操作发生的时间点，用 参数停下来，否则白忙活。时间点记不准，就得重复好几次，每次恢复都要耗费几个小时，压力巨大。
除了常规的数据库恢复，还有一种更让人头大的情况：整个服务器挂了，连操作系统都得重装。这时备份文件的存储位置就特别关键。建议把备份文件同时放在本地、内网另一台机器以及云存储上，至少两个不同物理位置。恢复时，先在新服务器上装好 MySQL，版本要和原服务器一致，然后停掉 MySQL 服务，把备份文件拷贝到数据目录，修改权限，再启动服务。如果使用 XtraBackup 的流式备份，恢复命令要先 ，让数据文件达到一致性状态，否则启动时 MySQL 会报“数据损坏”。
唠叨几句预防措施。备份恢复归根结底是管理问题，而不是单纯的技术问题。我见过太多团队，工具选得高大上，脚本写得花里胡哨，却从未真刀真枪演练过恢复。等到出事那天，才发现脚本路径写错、远程存储密码过期。我建议每季度做一次完整的恢复演练，从模拟数据丢失开始，逐步找回备份文件并在新环境恢复，随后跑几个业务查询验证数据完整性。这个过程能暴露很多平时想不到的坑。另外，备份脚本里一定要加报警机制，失败就发短信或钉钉通知，别等到下次备份时才发现上一次根本没成功。数据库备份这事，宁可用不上，也不能没有。等到真需要的时候，你会发现平时多花的那点功夫，绝对值得。
