数据中心硬件工程师远程展示操作细节

“数据恢复过程充满挑战，团队的心情也和过山车一样。”

一位参与了微盟数据恢复过程的工程师向钛媒体表示。

2月25日，SaaS服务商微盟集团（2013.HK）发布关于系统故障的公告，称SaaS（软件即服务）业务数据遭到员工人为破坏，并表示已向上海警方报案，该员工已被刑事拘留。这一事件迅速引起业界注意，钛媒体对此事也进行了系列跟踪报道。

（详见钛媒体前文：微盟遭员工“删库跑路”：SaaS服务暂停，或涉及300万商户；微盟“删库”144小时，痛的不是股价，是信任）

微盟遭核心运维人员删库事件引发了人们对企业数据安全的一系列思考。从2月23日晚微盟事发，到3月1日晚微盟宣布数据全部找回，腾讯云以及某专业数据恢复服务商的二、三十位工程师亲历了整个数据修复过程。

钛媒体独家获悉，目前微盟的数据还无法说“完全恢复上线”：虽然核心业务数据已经恢复，但目前尚有一些数据收尾工作还在进行。只不过工程师们经过七天七夜的轮班倒，终于到了松口气的时候。

这7天24小时，微盟究竟被删了哪些数据？修复难度到底有多大？修复团队是如何抢救微盟数据库的？在“鬼门关”过了一遭的微盟为什么突然决定全面上云？

腾讯云运维中心和客户服务部门负责人徐勇州以及第三方数据恢复负责人对钛媒体的一连串问题进行了回应。

问题症结：备份一并删除，涉及大量数据拼接

在微盟事件发生的2月23日星期天下午晚上六点多，腾讯云工程师们一开始还在排查到底是哪个环节出了问题，但紧接着他们发现，所有服务器已经都处于无法响应的状态。

“然后我们就挑了其中的一台服务器去进行重启，结果重启完就发现系统所有的数据都不见了，其实那时候已经非常紧张了，而且是大面积的，说明要么就是被入侵了，要么就是被故意破坏了。”徐勇州回忆。

紧急情况下，腾讯云分开两条线：

一条线，数据线同学的确认工作，根据服务器上的那些表现判断，非常明确，服务器上所有的文件都已经全部丢失；另外一条线，安全的同学去看这中间到底发生了什么事情。

“被执行了非常非常高危操作”——这是数据恢复团队在进行现场排查后，对微盟事件的一个定性。

腾讯云发现，微盟数百T的数据被全部删除，备份数据也被一并删除，印证了此前业界对微盟事故“如果不是没有备份，就是备份也被删除”的猜测。同时也就意味着，修复将会是一项难度极大、耗时极高的工程。

就在微盟公告事故之后，腾讯云也第一时间跟进了回应：事故发生后，腾讯云的技术团队已经在第一时间与微盟对齐，研究制定修复方案。

第三方数据恢复公司的负责人也告诉钛媒体，他们在23日晚便接到了数据恢复需求，紧急调动了上海、深圳、北京的4位主力工程师通过线上协作参与了数据恢复。“因为疫情，我们的工程师没办法赶到现场，通过腾讯云搭建的线上协作环境，以及他们自己的代码协作工具，尽最大努力协助微盟降低损失。 ​​​​”

最终采用了速度快、高风险的修复方式

数据恢复需要科学的规划和合理的节奏。腾讯云和微盟以及该第三方数据恢复技术商一起制定数据恢复方案。

“尤其针对这么庞大的数据恢复，更是需要技术团队做专业规划。腾讯云团队联合微盟、以及数据恢复公司在事件发生后的第一时间就制定了一套完整的数据恢复方案。”徐勇州说道。

第一步，控制受损面。不能让现在还有机会找回数据的那些服务器再发生任何的问题，或者说数据能发生任何的问题，这是一般做数据恢复首先要做的第一步工作；

第二步工作主要是通过专业的软件，或者是专业的团队去把数据找回来，这个过程也是非常耗时间的，首先要去扫看到底还有多少数据在，然后找到这些数据之后，通过一定的方法把它恢复出来，数据找回来之后，我们要去验证，给到微盟，他要去验证这数据是不是好的，是不是能导到数据库是不是正常，加载到服务器上是不是正常；

第三步，也是最后一步，就是微盟要去进行业务的上线、联调演练一系列的这些事情。

但在进行第一步操作的时候，他们就陷入了两难的境地。

在对数据拷贝做评估时，数据恢复团队给出了两种方式：

一种方式是通过两台机器网络来对拷。团队当时计算了一下，单拷这个事情，大概要两天左右的时间，优点是相对安全。

第二种方式就是把硬盘挂载，就是硬盘从服务器里面拔出来，然后插到有更多盘的设备上，或者说用多台服务器并行的方式把每个硬盘数据给copy出来，这个方案的优点是速度稍微快一点，但是风险大，任何一步细微的失误，数据就彻底没了。

两难之下，在征得微盟方面同意后，数据恢复工程团队做了一个略显大胆的决定：越过镜像拷贝的步骤，同时不将微盟的数据盘从原有服务器上拔下来，而是将另外一块系统盘安装到原有服务器上，通过新系统盘加载OS和数据恢复软件，直接扫描提取数据盘中的“隐藏”数据。

这样速度快，但需要确保操作不出现任何问题。

“我们作出这个决定的依据，一是微盟服务器的硬盘健康度还是不错的，这给了我们一定的容错空间，二是我们有一大批硬件处理经验丰富的专家，几十个人都通过视频会议软件远程盯着。两个因素叠加，我们判断有比较大的把握去解决这个风险。”

这几十个人在远程协作的情况下，最终恢复了云端上百个TB的MySQL数据库。

挑战：没有获得事故当天的完整数据

就在数据恢复第一阶段进展顺利，进入数据提取阶段的时候，一个发现让几十位数据恢复工程师的心情陷入谷底：没有获得事故当天的完整数据。

“当我们第一批次的数据拿到的时候，我们其实是非常兴奋的，但很快发现，这是截至2月17日的数据。也就是说，我们并没有获得截止到数据丢失当天的完整数据。”

这种情况，团队只能对磁盘的每一块（block）进行扫描，打捞未获得的数据。

但是通常情况下一个磁盘扫描需要很长的事件，慢可能要24个小时左右的，快也需要12个小时。比较幸运的是，在对第一台服务器的第一块扫描成功后，团队发现导回数据库查看是完整的，这也证明了这种磁盘扫描方案的可行性。

但另一个问题也浮出水面：扫描出来的数据文件的大小，比微盟核心数据文件要小。这意味想要获得完整数据，需要进行拼接。也就是说，微盟的数据可能在打捞的时候，被打散了，需要重新像拼图一样将这些散落的数据拼接完整。

“数据越大，需要拼接的难度也越大。好在微盟的备份机制比较完整，数据类型比较统一，我们通过一系列技术手段最后也很快完美解决了这个问题，拿回了数据。”徐勇州表示。

这也就有了后面微盟最后一次公告中提到的“数据全面找回”，但是由于数据恢复后还有业务的上线、联调演练一系列的操作，所以，即便微盟已经承诺3月4日上午实现数据全面上线，但截止发稿前，仍有一些商家数据尚未完全实现业务可用。

全面上云也不能完全规避风险

在此前的报道中，钛媒体提到微盟实际上采用的是混合云架构，这次数据恢复困难的重要原因也在于微盟大部分核心数据没有上云。经过此次生死考验，微盟最终决定采用全面上云的方式，避免类似事件的发生。

但徐勇州也告诉钛媒体，实际上，无论企业把业务部署在自有的IDC，还是托管IDC里，只要暴露在公网下，都会存在威胁。

同时，作为云资源支撑方，腾讯云内部对客户微盟的这次事件也进行了盘点和梳理，给出了一些企业数据安全保护的建议和手段：

首先，对于企业使用自建数据库的情形，建议用户把应急方案“通过binlog或者其他备份文件进行恢复的详细步骤”制定成预案，并且定期演练，保证问题真正发生时能够迅速跑通。另外，针对云服务器建立数据库的场景，建议企业结合云厂商提供的定期云盘快照功能来做数据恢复。其次，建议企业从整体上梳理风险点，进而进行统筹和联动防御。并对外部、内部、大数据等不同场景建设不同解决方案。重点提醒用户做好云主机要定期快照、做好云账号权限管控、对重要数据实施分级管理并做好加密、建立全生命周期的数据安全防护。在产品层面，也会加强对云上用户对云硬盘CBS、云对象存储 COS、云数据库CDB、腾讯云数据产品系列、CAM云权限管理等产品方面的使用引导，联合用户，一起做好云端数据安全防护。

从危机之中看转机，微盟遭删库一事的的确确给行业的数据安全敲响了警钟，在与一些商户交流的过程中，钛媒体了解到，作为云服务的使用方，他们也受到了启发。

联想智慧零售转型项目乐呗商城负责人张诚告诉钛媒体：“这次突发事件也给我们敲了个警钟，关键业务系统的关键数据备份要有异地和人员隔离，确保核心数据资产安全。”

他还补充表示，他们将认真借鉴总结各团队本次灾难恢复的所有流程动作，形成规范文档SOP，与备份/恢复策略等共同形成BCP(Business Continuity Plan)，制定定期演练计划，确保今后即便有人员变动或误操作的突发情况下，也能按计划有条不紊推进平稳过渡和职责切换，对系统任何可能的异动实现迅速恢复。

徐勇州也说：“过往很多企业对于安全说实话重视不足，觉得黑天鹅事件发生在自己身上的概率太低。微盟事件其实也给这些企业敲响警钟，后续企业会更加重视安全；其次，企业对于上云这件事以及云上安全会刷新认识，经此一役，企业上云的战略更加坚定。”

实际上中国不少企业存在自建数据库、存储等情形，虽然也做了很多安全措施，但真正出现安全事件，大部分情况下，云计算公司可能比企业自己在处理这些方面更有经验。（本文首发钛媒体，作者/秦聪慧）