在6月26日凌晨12点左右，我们在做线上数据库的备库时，误将线上数据库分区上的所有文件删除。丢失的数据时间段为4月23日至6月25日两个月，在经过7天的努力后，恢复了99%以上的数据。（具体见下面的统计）。

下面把整个事故过程记录下来，令关心本次技术事故的人们知晓。

一. 事故隐患

现在回顾，事故隐患在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进程停止了。所有技术人员开始应急处理。一是把整个分区dd成镜像，准备做将来硬盘恢复的备份。二是把memcache里的数据dump出来，以备可能的恢复。三是重新启用原来的从数据库，由于数据时间只到4月23日，需要调整近两月表结构变更，让最新的代码可以跑起来。

当天的应急工作至凌晨4点，服务器都恢复访问，但数据停留在4月23日。

在整个应急过程中，部分是紧张，部分是沟通上存在误解，还是出现了失误。当配置从数据库的技术人员完成之后，重启了服务器和memcache，恢复了正常访问。但是做memcache导出工作的技术人员还没有完成，所以最终能从memcache里得到的那部分数据只有一半左右。

事后从沃趣科技的数据库工程师那里得知，我们第一时间停止MySQL防止硬盘继续写入这个应急措施是错误的，即使分区完全没有文件，mysql的进程继续运行，只要保留这个现场，可以从内存中获取更多的数据库结构信息，对恢复数据非常有帮助。

三. 事故后恢复工作

事故后恢复工作从数据来源分为4条线索进行：

1. 硬盘上数据的恢复（主线）

2. 从memcache导出的数据恢复

3. 从binlog里恢复

4. 从搜索引擎的快照里恢复页面

以下按时间详细叙述：

• 6月26日8点，我们去机房把服务器硬盘取出来，送到了一家硬盘数据恢复公司。到下午5点左右恢复出ibdata1文件，文件可能破损。
• 6月26日12点，为了预防新插入的内容和原内容的冲突，我们把所有表的id都加到一个大值，半天的内容随后做特殊处理。
• 6月26日23点，导入完了所有memcache里的数据。
• 6月27日上午，从硬盘里又恢复出部分.ibd文件，也包含部分数据信息。已确定包含数据的ibdata1和.ibd文件有破损，无法直接使用，只能尝试从破损文件中提取部分有效信息。
• 6月27日下午，联系上杭州沃趣网络科技有限公司的陈栋、李春，开始对数据的提取工作。至凌晨1点，提取出.ibd文件的数据，恢复部分表。
• 6月28日全天，沃趣科技开始对ibdata1文件的提取，至29日凌晨1点，他们已经提出大部分数据。
• 6月28日下午，得到阿里巴巴集团的周振兴的友情支持，他开始帮忙做ibdata1文件的提取工作，至凌晨4点，他完成部分带二进制段的数据表的修复，提取到了相关内容。
• 6月28日下午，我们联系上北亚数据恢复中心，开始再次尝试对硬盘文件的恢复。
• 6月28日晚，我们把所有从binlog来的数据导入完，完整恢复了最后10天的数据。
• 6月29日中午，从沃趣科技得到的优先级较高的数据表已经恢复完成，开始恢复次优先级的数据。
• 6月30日中午，提取完所有能从6月27日获取的破损数据库文件里的所有内容。至此这一阶段提取到缺失总数据量的近70%。
• 6月30日下午，开始从搜索引擎快照里抓取部分菜谱重要页面，修补缺失的内容。并联系上某搜索引擎的快照部门，希望获取我们网站的全部页面快照。
• 7月1日上午，北亚数据恢复中心取得很大的进展，提取到几乎是完整的ibdata1文件，至下午6点，提取到除了收藏和赞的所有数据表，我们开始把数据导入，至凌晨4点，恢复完得到的所有数据。
• 7月2日整天，由于导入的旧数据和新注册的用户存在部分数据不一致，我们尽力配合用户恢复。
• 7月2日下午4点，北亚提取到ibdata1剩下的文件碎片，得到了完整的ibdata1文件，mysql无报错启动，我们得到了6月26日凌晨事故前的完整数据库。至凌晨2点，我们提取出剩下的收藏和赞，恢复到数据库里。至此损失的数据内容已经恢复到99%。

下一阶段：

• 在丢失两个月数据的这一周时间里，用户新产生的数据和恢复的旧数据会有少量不兼容的情况，我们会全力帮助用户找回自己的全部数据，出现的错误敬请用户包涵，帮助我们走过这一过渡阶段。
• 除了原先的三种备份方式外，我们会继续落实和第三方的云存储方案的合作，把数据备份到我们的服务器之外的地方。

四. 所缺失的近两月数据当前的恢复情况

至今，内容大多得到了99%左右的恢复。缺失部分并不是来自硬盘数据丢失，而是6月26日12点前id移位至大值前，半天创建的内容和原位置内容的冲突，我们还在尽力修补。

以下是当前主要内容的恢复情况：

五. 致谢

特别感谢一下三个公司和个人在这7天的恢复工作中对我们的帮助。

杭州沃趣网络科技有限公司(@沃趣科技)是来自原阿里巴巴DBA/SA团队核心骨干组建的创业公司，提供数据库和系统相关的专业服务和产品，陈栋（@grassbell）、李春（@pickup112）对破损的数据库文件进行了灾难修复，提取出绝大部分数据表的内容。

周振兴（@orczhou）是淘宝MySQL数据库运维负责人，他对破损文件中部分带二进制段的数据表进行了修复，提取到了相关内容。

北亚数据恢复中心是来自前信息产业部职鉴中心，专门从事数据恢复服务的技术公司。张宇，刘子龙对硬盘文件进行了完整的恢复，使我们得到了数据库的全部数据。