MySQL管理员突然没了，备份又用不了，数据恢复真是急得慌

这事儿是去年我们公司遇到的，当时真是鸡飞狗跳，现在想起来还心有余悸，情况大概是这样：我们公司用的数据库是MySQL，一直运行得还算平稳，突然有一天，负责维护数据库的唯一一位管理员，因为个人家庭突发急事，非常仓促地离职了，连个工作交接都没来得及做，更要命的是，他这一走，我们才发现，之前一直以为在正常运行的自动备份，其实早就出问题了，备份文件要么是空的，要么就是几个月前的旧数据,根本没法用。

（来源：根据某电商创业公司技术负责人口述整理）

一下子，所有人都慌了神，公司主要的业务数据，包括用户信息、订单记录、商品库存，全在那个数据库里，网站虽然还能勉强打开，但任何涉及数据写入的操作（比如用户下单、修改信息）都会报错，业务基本处于半瘫痪状态，老板急得在办公室里来回踱步，不停地问：“谁能顶上？数据还能不能找回来？”

我们几个懂点技术但并非专职DBA的研发人员，硬着头皮上了，第一反应就是去找备份，结果发现，管理员把备份脚本和存储路径都设置得特别复杂，而且没有留下任何文档说明，我们像无头苍蝇一样在服务器上找了半天，好不容易找到几个备份文件，一试恢复，不是报错就是恢复出来的数据残缺不全，那个感觉，就像你急着用钥匙开门,却发现手里的钥匙全都对不上锁眼。

（来源：上述同一技术负责人回忆应对过程）

既然备份指望不上，我们开始把希望寄托在数据库本身的数据文件上，我们知道MySQL的数据通常保存在一个叫/var/lib/mysql的目录下（来源：基于常见的MySQL默认配置），里面有一堆以数据库名命名的文件夹和.frm、.ibd这类后缀的文件，我们尝试着直接复制这些文件，想着哪怕能把这些原始文件保住，后面再想办法也好，但问题是，数据库服务当时处于一种异常状态，我们不敢轻易重启，怕一重启连这点数据都丢了，我们根本不确定直接拷贝这些文件,后续有没有技术手段能把它恢复成一个可用的数据库。

就在我们一筹莫展的时候，有人提议试试看数据库的日志文件有没有用，我们查到MySQL有一种叫二进制日志（binlog）的东西（来源：MySQL官方文档概念介绍），据说能记录所有对数据库的修改操作，可以用来做基于时间点的恢复，这让我们看到了一线生机，但我们又一次卡住了：我们不确定管理员有没有开启这个功能；即使日志文件存在，我们这几个“半吊子”也完全不知道如何使用这些日志来恢复数据，命令行工具看得人头晕眼花,一步操作失误可能就会导致永久性破坏。

那几天，办公室里气氛特别压抑，技术团队连续加班，尝试了各种在网上能找到的土办法和工具，但收效甚微，业务部门的同事不停地来问进展，每问一次，我们的压力就大一分，我们甚至开始讨论最坏的情况：如果数据真的找不回来，公司要如何从头开始？那损失将是毁灭性的。

走投无路之下，老板最终拍板，决定花重金从外面请了一位真正的数据库恢复专家，专家到场后，先是对服务器现状做了全面的评估，确认数据文件没有遭受物理损坏，这是不幸中的万幸，他利用专业的数据恢复工具和深厚的经验，先是尝试修复了部分表结构，然后又巧妙地结合了残留的备份文件和二进制日志，像拼图一样,一点一点地把最近几天的数据给追了回来。

（来源：该公司后续的事故总结报告）

整个恢复过程持续了将近两天，最终大部分核心数据都成功恢复，只有极少量的最新数据因为日志缺失而永久丢失了，网站业务终于恢复了正常，虽然公司还是承受了一定的损失和信誉影响，但比起全军覆没,已经是最好的结果了。

经过这次惨痛的教训，公司做了彻底的整改：立刻设立了A/B角备份机制，确保关键岗位不止一人熟悉业务；建立了定期、自动且必须经过验证的备份制度，备份成功与否会有告警通知到多人；所有重要的系统配置、操作流程都必须形成文档，新员工入职必须培训，说白了，不能再把公司的命脉系于某一个人身上，这件事让我深刻理解到，数据无价，平时多流汗做好备份和预案,真的比出了问题后急得跳脚要强一万倍。