如何恢复丢失的两个月数据——“下厨房”技术团队分析总结 6.26 数据库事故

下厨房是国内知名的美食社区，在 Alexa 的全球排名达到 6,469，国内排名为 769，国内注册用户 160 多万人。6 月 26 日，由于技术人员操作失误，导致近两个月数据丢失，到昨天为止，他们找回了 99% 丢失的数据。技术团队在他们的博客上分析了本次事故的经过。

文章开始简述了本次事故的具体情况：

在 6 月 26 日凌晨 12 点左右，我们在做线上数据库的备库时，误将线上数据库分区上的所有文件删除。丢失的数据时间段为 4 月 23 日至 6 月 25 日两个月。

对于事故的根本原因，文章指出：

我们对数据库迁移工作的管理存在失误，是造成事故的根本原因。没有完成数据库备份节点，迁移工作就并没有结束。我们技术团队的所有人对这个事故都负有责任，这个隐患在两个月里都可能被发现，每个人都有可能提出这个工作的高优先级。也都可能提出相应的弥补工作来保证数据安全，比如在启用从节点前延长二进制日志的保存时间等。是我们的工作失误使数据库成为系统最脆弱的环节，经受不住偶然事故的冲击。

而事故隐患在 4 月 23 日之后就已经存在了：

我们线上数据库使用的是 MySQL，在 4 月 23 日之前，我们对线上数据库主节点有三类备份。一是有一个独立的数据库从节点来备份，与线上服务器保持数据的实时同步，需要时可切换作线上使用。二是会定期把整个数据库 dump 成 sql 文件来备份，一天保存一次，备份的来源是数据库从节点。三是主节点开启有 binlog，默认是保存十天的日志，十天内有任何事故可以从日志里完整恢复全部数据。这三个备份分别存放在两台不同的物理机，三个不同的分区上，是当时想到的最安全的方式。

4 月 23 日，我们把数据库主节点迁移到一台新的物理机上，并把版本升级到 5.5。由于版本和配置的问题，原来的从节点并不能直接使用。而一天一次的备份来源是从节点（备份主节点会令网站和手机 app 有 1 小时左右的卡顿），这个备份方式也就停止了更新。只有最后一个 binlog 还在运行。数据库迁移之后应用服务器存在一些性能问题需要投入时间，包括修复 MySQL5.5 版本和原代码的兼容，以及把应用服务器从 gunicorn 换成 uwsgi，之后又陆续有一些开发任务，以致重新启用备份节点的工作一再拖延。

接下来，文章中分析了事故的发生过程：

6 月 26 日凌晨 12 点，开始重新建立备份节点工作，需要把原来的从节点删除，重新安装，所以先使用了 rm -f 方式删除备份节点分区上的所有文件。

5 分钟后，发现刚才删除的是数据库主节点的分区，为防止硬盘继续写入，就马上停止 MySQL 进程。此时采取了三个应急处理措施：

1. 整个分区 dd 成镜像，准备做将来硬盘恢复的备份。
2. 把 memcache 里的数据 dump 出来，以备可能的恢复。
3. 重新启用原来的从数据库。

至凌晨 4 点，服务器恢复访问，但数据停留在 4 月 23 日。

但提供支持的沃趣科技技术人员认为：第一时间停止 MySQL 是错误的做法，

即使分区完全没有文件，mysql 的进程继续运行，只要保留这个现场，可以从内存中获取更多的数据库结构信息，对恢复数据非常有帮助。

在应急处理过程中，紧张和沟通误解也带来了失误。

当配置从数据库的技术人员完成之后，重启了服务器和 memcache，恢复了正常访问。但是做 memcache 导出工作的技术人员还没有完成，所以最终能从 memcache 里得到的那部分数据只有一半左右。

事故发生后的数据恢复从 4 个方面入手：

1. 硬盘上数据的恢复（主线）
2. 从 memcache 导出的数据恢复
3. 从 binlog 里恢复
4. 从搜索引擎的快照里恢复页面、

详细步骤，可以参考原文。

接下来，他们要做的主要是两件事：

• 解决用户产生的新数据和恢复的旧数据之间的不兼容情况。
• 落实和第三方方的云存储方案合作，把数据备份到服务器之外的地方。

到博客文章发表时，数据已经恢复了 99%。

文章最后，感谢了杭州沃趣网络科技有限公司 ( @沃趣科技) 的陈栋（ @grassbell ）和李春（ @pickup112 ），沃趣科技是由阿里巴巴原来的 DBA 和 SA 团队核心骨干成立的创业公司，此外还有淘宝 MySQL 数据库运维负责人周振兴（ @orczhou ）、以及北亚数据恢复中心。

三年前，InfoQ 中文站曾经发表过一篇新闻：《站点恢复过程中的经验和教训》，讲述了Stackoverflow 的创始人 Jeff Atwood 的两个博客站点的事故和恢复过程。Jeff 指出：

可以肯定的是：只有在你拥有某种备份策略，并且坚持执行的时候，你才会了解它。如果备份数据看起来有点麻烦，那就对了，因为它的确是那样。

而他最后得到的教训是：

1. 我吸取教训。
2. 是的，真的，我吸取教训。
3. 不要依赖于你的提供商或者任何其他人来备份你重要的数据。而应该自己来做。如果你不能够对你自己的备份负责，那么数据丢失就不会是偶然事件了。
4. 如果你的数据真的出了问题，那么你怎么才能够恢复呢？过程是什么呢？恢复最困难的部分是什么呢？我想在我思想深处对 Coding Horror 的灾难恢复能力有错误的信心，因为我一直认为它大多数都是文本。当然，后来发现文本是其中最简单的部分。而我曾经认为是很好方式的镜像比我意识到的更加重要，而且更加难以恢复。有些人认为我们不应该讨论如何备份，而应该讨论如何恢复。
5. 定期对你的恢复过程进行检查，以确认它仍然是可用的、有效的并且功能齐备，这是非常有价值的工作。

Jeff 在这篇新闻中还提出了更多关于备份策略的技术观点，三年过去，这些观点仍不过时，感兴趣的同学请猛击此处查看更多。