钛媒体@微盟数据修复为什么需要七天七夜？

第二步工作主要是通过专业的软件，或者是专业的团队去把数据找回来，这个过程也是非常耗时间的，首先要去扫看到底还有多少数据在，然后找到这些数据之后，通过一定的方法把它恢复出来，数据找回来之后，我们要去验证，给到微盟，他要去验证这数据是不是好的，是不是能导到数据库是不是正常，加载到服务器上是不是正常；
第三步，也是最后一步，就是微盟要去进行业务的上线、联调演练一系列的这些事情。
但在进行第一步操作的时候，他们就陷入了两难的境地。
在对数据拷贝做评估时，数据恢复团队给出了两种方式：
一种方式是通过两台机器网络来对拷。团队当时计算了一下，单拷这个事情，大概要两天左右的时间，优点是相对安全。
第二种方式就是把硬盘挂载，就是硬盘从服务器里面拔出来，然后插到有更多盘的设备上，或者说用多台服务器并行的方式把每个硬盘数据给copy出来，这个方案的优点是速度稍微快一点，但是风险大，任何一步细微的失误，数据就彻底没了。
两难之下，在征得微盟方面同意后，数据恢复工程团队做了一个略显大胆的决定：越过镜像拷贝的步骤，同时不将微盟的数据盘从原有服务器上拔下来，而是将另外一块系统盘安装到原有服务器上，通过新系统盘加载OS和数据恢复软件，直接扫描提取数据盘中的“隐藏”数据。
这样速度快，但需要确保操作不出现任何问题。
“我们作出这个决定的依据，一是微盟服务器的硬盘健康度还是不错的，这给了我们一定的容错空间，二是我们有一大批硬件处理经验丰富的专家，几十个人都通过视频会议软件远程盯着。两个因素叠加，我们判断有比较大的把握去解决这个风险。 ”
事后，赵力也向钛媒体证实，这几十个人在远程协作的情况下，最终恢复了云端上百个TB的MySQL数据库。
挑战：没有获得事故当天的完整数据就在数据恢复第一阶段进展顺利，进入数据提取阶段的时候，一个发现让几十位数据恢复工程师的心情陷入谷底：没有获得事故当天的完整数据。
“当我们第一批次的数据拿到的时候，我们其实是非常兴奋的，但很快发现，这是截至2月17日的数据。也就是说，我们并没有获得截止到数据丢失当天的完整数据。 ”
这种情况，团队只能对磁盘的每一块（block）进行扫描，打捞未获得的数据。
但是通常情况下一个磁盘扫描需要很长的事件，慢可能要24个小时左右的，快也需要12个小时。比较幸运的是，在对第一台服务器的第一块扫描成功后，团队发现导回数据库查看是完整的，这也证明了这种磁盘扫描方案的可行性。
但另一个问题也浮出水面：扫描出来的数据文件的大小，比微盟核心数据文件要小。这意味想要获得完整数据，需要进行拼接。也就是说，微盟的数据可能在打捞的时候，被打散了，需要重新像拼图一样将这些散落的数据拼接完整。
“数据越大，需要拼接的难度也越大。好在微盟的备份机制比较完整，数据类型比较统一，我们通过一系列技术手段最后也很快完美解决了这个问题，拿回了数据。 ”徐勇州表示。
这也就有了后面微盟最后一次公告中提到的“数据全面找回” ，但是由于数据恢复后还有业务的上线、联调演练一系列的操作，所以，即便微盟已经承诺3月4日上午实现数据全面上线，但截止发稿前，仍有一些商家数据尚未完全实现业务可用。
全面上云也不能完全规避风险在此前的报道中，钛媒体提到微盟实际上采用的是混合云架构，这次数据恢复困难的重要原因也在于微盟大部分核心数据没有上云。经过此次生死考验，微盟最终决定采用全面上云的方式，避免类似事件的发生。
但徐勇州也告诉钛媒体，实际上，无论企业把业务部署在自有的IDC ，还是托管IDC里，只要暴露在公网下，都会存在威胁。

钛媒体@微盟数据修复为什么需要七天七夜？ | 钛媒体独家( 二 )