3月1日晚上10点半，已经停摆一周的微盟发出公告：“截止到3月1日晚8点，在腾讯云团队协助下，经过7*24小时的努力，我们数据已经全面找回。”微盟平台上的商家和用户们，终于松了口气。

打开百度APP，查看更多高清图片

作为在SaaS领域举足轻重的服务提供商,微盟有300万注册用户,以及超过7万的SaaS付费用户。在过去的一周中,所有微盟平台上的用户和商家都因为一场运维事故而被迫停滞了一周时间。对于他们来说,服务没有恢复的每一分每一秒都是收入和用户的损失,用“心急如焚”来形容恐怕有过之而无不及。微盟在数据恢复公告的最后着重提出“最后再特别感谢腾讯云团队”,看到发出的公告,徐勇州最大的感受是,终于可以放心的睡个好觉了。徐勇州是腾讯云运维中心和客户服务部门负责人,也是微盟这场抢救活动的总指挥,就是为了“全面找回数据”这个目标,他和腾讯云的多位技术专家,联合微盟团队一起,整整奋战了七天七夜。“不可能完成的任务”时间倒回至23日下午7点,当时正在进行居家隔离的徐勇州,可能也想不到接下来的七天七夜,他和30多位同事会这样度过——腾讯云监控中心发出告警,监测到微盟部署在黑石物理服务器上的业务出现大面积无法响应的情况,同时微盟也通过腾讯云售后和商务团队同步了这一信息。与此同时,微盟的商家服务群里已经炸开了锅。团队的第一反应是：难道腾讯云黑石物理服务器服务出现问题了？徐勇州和团队很快排除了这种可能性：黑石物理服务器集群整体运行正常,独独微盟业务大范围受到影响,可以推断问题应该不是出在云服务商这侧,而是在微盟业务侧。

事故发生之初微盟在官网发出公告腾讯云安全团队与微盟技术团队随即联合排查。很快，溯源到微盟部署在自建MySQL数据库上的核心业务数据，被微盟某运维人员用一种让程序员闻风丧胆的Linux系统下文件删除命令，整体进行了不可逆的删除。业内经常调侃的程序员删库的事件，就如黑天鹅，毫无征兆地发生在微盟身上，业务瞬间全线崩溃，数百万商家无法开展业务。事后外界的各种技术解读，大多会提到“有没有备份数据？为什么不用备份数据快速还原？”外界并不清楚的是，备份数据也被一起删除了。事情的严重程度远超外界想象。微盟立刻启动紧急响应机制。由于内部相关技术能力缺乏，微盟也向腾讯云紧急求援。23日深夜，腾讯公司副总裁、腾讯云总裁邱跃鹏接到团队汇报，他指示团队 “不管微盟的故障原因是什么原因触发，腾讯云都要不惜代价全力支持”,并立刻决定由徐勇州组建一支30多人的技术团队，与微盟一起研究制定生产环境和数据修复方案，同时协调了内部等多个部门做好技术协助和资源保障。数据库连同备份文件被全部删除，且数据体量达到数百T。这种情况，哪怕是专业的数据恢复公司，也只敢谨慎评估20%左右的修复预期。难度可想而知。“这好像就是重症病人进了手术室”。徐勇州需要去完成一场抢救，虽然看起来救回来的希望不大，但 “病人的命就在你手上，客户的生死存亡，我们不可能袖手旁观”。坚信数据肯定还在的是微盟CTO黄骏伟，他一再对徐勇州和腾讯云技术团队表示，“拜托你们一定要帮我们找回来”。来自微盟的这种信任是责任，也是压力。随后七天七夜，徐勇州和技术团队，与微盟一道，投入到了这场不眠不休的抢时间救数据战斗中，竭尽全力去完成这项“不可能完成的任务”。一场168小时的腾讯会议23日晚，不眠之夜。徐勇州连夜带领团队与微盟方面进行解决方案的探讨和制定。任务的十万火急，让每个人睡觉都只敢定2个小时的闹钟，闹钟一响就接着战斗。24日下午，已经连轴工作30多个小时的徐勇州，才第一次短暂休息。微盟CTO黄骏伟，也是始终保持在线，与腾讯云团队沟通修复过程中的技术问题。事实上，徐勇州有自己的理论：虽然文件相关的索引节点信息被删除了，但只要没有数据写入，数据块还是在的，这为修复提供了一种潜在可能。技术团队很快对修复方案达成一致：鉴于数据库服务器上文件数量多，类型复杂，文件的提取和确认难度很大，而备份服务器上文件类型单一，数据集中，且微盟数据被删后，硬盘没有被二次写入，理论上里面可能存在相对完整的备份数据，团队决定从备份服务器入手，尝试恢复数据。他们很快面临了第一个艰难的抉择——通常来说，数据修复的第一步是对源数据进行镜像拷贝，以避免修复过程中源数据受损的风险。如果采用网络传输进行拷贝，以微盟的数据体量，光是数据拷贝过程就至少需要2天以上，会让数据修复的时间进一步加长。“微盟和商家们都等不起。”另一种惯用的处理方式是将原来服务器上的硬盘拆装后挂载到新服务器上，以并行的方式进行“硬盘对拷”。这样可以节约时间，但风险是一旦中途出现故障，源数据可能会因此完全丢失。“对于仅有一次这样修复机会的微盟来说，这样做风险太大。”两难之下，在征得微盟同意后，团队做了一个大胆的决定：越过镜像拷贝的步骤，同时不将微盟的数据盘从原有服务器上拔下来，而是将另外一块系统盘安装到原有服务器上，通过新系统盘加载OS和数据恢复软件，直接扫描提取数据盘中的“隐藏”数据。这样做的依据是，数据硬盘的健康度良好，且腾讯云技术团队有丰富的硬件处理经验，有较大把握在源数据不损伤的前提下进行扫描。这相当于借助一根体外供血管在体内完成这场手术，通过完美的技术，实现效率与完整性兼顾。为了万无一失，徐勇州还邀请了腾讯内部多位硬件专家通过腾讯会议进行远程视频指导。“所有的专家都在线，几十双眼睛，在屏幕前盯着现场工程师的每一个动作，以保证准确无误。”

数据中心硬件工程师通过腾讯会议远程展示操作细节前期进展很顺利，但在接近完成的时候，团队最担心的事还是发生了。25日凌晨6点钟，徐勇州趁着工作的间隙打了个盹儿。可是很快，他就在半睡半醒之间，被电脑里说什么“加载不上”吓到，一激灵就醒了。惊醒徐勇州的，就是新系统盘安装，在接近完成的时候，数据硬盘发出掉线警告。 “整个团队的心都悬到了嗓子眼。毕竟这些数据可能就对应着微盟的百亿市值，不能出任何闪失。”徐勇州说。庆幸的是，经过排查，原因是由于新加的系统盘触发了原来服务器中的硬件保护机制，不难解决。半小时的技术实施后，全部数据开始正常读取。这个举措为修复抢回了一天多的时间。值得一提的是，由于团队只能远程办公，从第一天开始腾讯会议就成为了最高效的协同工具。在整个修复过程期中，腾讯会议处于7*24小时开启状态，从未间断，各个业务团队累计通过腾讯会议进行766次入会沟通。

“在大海中打捞拼图”

小心翼翼的“手术”过后，更大的挑战在于如何将数据完整地提取出来。2月26日，数据恢复工作已经开展了三天三夜。当天中午，第一批次的数据拿到，导入数据验证正常。但他们很快发现，他们扫描出来的最新一份数据是截止到2月17日的数据拷贝，完整性尚不确定。“也就是说，即便这份数据完整，那17号到23号当天的数据也是缺失的。”徐勇州解释，“这个事情，好的一面是明确地告诉我们数据还在，恢复有希望。但是只找回一部分数据意义不大，我们需要完整的数据。”扫描仍在继续尝试，工程师们逐步发现了更多数据的踪迹。到了周三深夜，新的问题再次出现：工程师们发现，现有的数据备份中，缺少大文件数据，而这些大文件极有可能是微盟最核心的业务数据。它们没有被扫描出来。“用绝望来形容当时的心情都不夸张，核心数据如果没有，等于前期的工作都白做了，其他数据恢复了都没意义。”徐勇州说。事实上，此时扫描出的数据大约是微盟数据整体的30%左右，已经符合甚至超过了此前行业对此类事故恢复程度的预期。“这难道真的是一个完不成的任务?”徐勇州和技术团队不想放弃：核心数据找不回，影响的不止是微盟，还有那些商家的利益。“有一点希望都得试试看。”徐勇州彻夜未眠。思量再三，决定两条腿走路：一是尝试对磁盘的每一块(block)进行二次扫描；二是让腾讯云的操作系统团队从OS底层入手，制定数据恢复方案PlanB,这需要极其庞大数量的尝试和数据验证，“方案一能成功是最理想的，方案二就意味着数据恢复的时间不确定，业务停摆，继续失血。”周四上午，第一台服务器的第一块扫描成功，导回数据库查看是完整的。“方案一可行！大家信心一下子又起来了。”从可行到成功，中间仍有艰难险阻。数据公司提取出来的单一的块，从体积来看还是达不到微盟核心文件的大小。这意味着，要获得完整数据，需要进行数据“拼接”。就好像整块拼图被打散扔进了大海里，一块一块打捞上来是第一步，拼接是第二步。不同的是，拼图时还能够根据形状来判断哪些可以放在下一块，而拼接数据块，根本无法通过肉眼识别，只能靠一块块去扫描，寻找相似度高的拼接到一起，再重新扫描看断点是否能重合。庆幸的是微盟的备份机制较为完备，数据的覆盖度和完整性检查等工作非常细致。徐勇州发现，文件类型只有一种，那么就能很容易判断出哪块是开头，拿着开头去找剩下的块，把工作量从“N*N”降低到“1*N”。但“1*N”的工作量也不小。最大的一个文件，由7块碎片组成。找到开头以后，工程师开始扫描其他有相似性的块。运气好的时候，相似度可能只有一块，运气不好的时候 ,有二三十块。每进行一次拼接，都需要把数据块从头到尾扫描一遍，验证是否匹配。这需要大量的计算力。为了加快扫描和验证，腾讯云服务器团队还临时从上海机房调拨了100多台服务器进行算力支持。徐勇州已经不记得这样的“打捞、拼接、扫描、验证，重新打捞、拼接、扫描、验证”进行了多少次，只记得每一次都是四五个小时的煎熬。“大家每隔一会儿就在腾讯会议上吼，好了没，好了没，快看看！”终于，一块又一块的数据被拼接出来，核心数据逐渐被修复。“太不容易了，心情真的跟过山车一样。”2月28日，深夜，数据修复胜利在望。“做到100分，在云上迎接重生的微盟”虽然最初大家并不敢断言数据能否修复，随着两边团队的共同攻坚，大家关注的焦点逐渐变成数据能不能做到100%的修复。然而，即便是方法论经过了验证，但就像写程序一样，在一些细微的地方总会有一些意想不到的bug出现。2月29日凌晨，恢复到最后一台服务器时，徐勇州和技术团队盘查发现，前面找回来的那些数据只有整体数据量的70%-80%。按照前面核心数据恢复的方法推演，如果逻辑成立的话，此时恢复的数据应该是100%。剩下的数据去哪了?到底是哪个环节出了问题?“我们的目标是要做100分，哪怕失掉5分，对一个商家来说可能就是全部。”徐勇州和团队连夜把所有的数据又重新盘点了一遍，把验证的逻辑再推导了一遍：扫描了多少?提取了多少?哪些校验过?哪些没有? 又是一夜未眠。3月1日凌晨，终于在另一个的区段中，被遗漏的数据被“打捞”了出来。原来有一部分数据在提取时因为环境等各种原因被疏忽了，在把所有的数据都汇总整理和对齐后，很快找到了对应的那段未提取区段，然后又是进行紧张的“打捞、拼接、扫描、验证”,但这时的团队已经是技术娴熟，胸有成竹。3月1日晚，微盟发布公告称，数据已经全面找回。同时宣布基础设施全力上云。

根据微盟公告，微盟将采取以下措施提升对数据安全的保障：首先在权限管理方面，使用腾讯云CAM权限系统进行云资源管理，严格执行分级授权和最小集权制度，对高危险动作执行二次授权制度；使用腾讯云堡垒机替换自建堡垒机，进行细粒度许可权分级和授权管理。其次，在北京、上海、南京等地区建立全备份的冷备系统架构，借助腾讯云IaaS的底层服务能力，建立高可用的同城双活架构；所有非结构化数据使用腾讯COS对象存储系统进行归档保存并启用多异地复制功能。最后，借助腾讯云数据库MySQL的数据高可用和安全体系，逐步放弃自建数据库服务，迁移到腾讯云数据库(CDB),提升数据库跨可用区和易地灾备的能力，同时，将原来合作的黑石1.0物理机全面升级黑石2.0,全面使用云主机。在徐勇州看来，微盟事故的发生对其他企业的数据安全保护也敲响了警钟，数据安全事件背后折射出的是，仅仅依靠单点防护难以达到真正的安全防护效果，而构建基于全生命周期的安全防护成为必然选择。微盟公告发出以后，腾讯云技术团队在微信群里收到了微盟团队的集体致谢。那个全程见证事件进展的超长腾讯会议的会议号，被团队提议作为一个永久的番号保留。

从微盟删库事件谈数据修复的技术原理与时效挑战

微盟删库事件至今发生已快1周时间，根据微盟公告介绍，官方正在紧锣密鼓的进行着数据恢复工作。本篇文章，联想数据恢复中心专家赵榛为这次的数据恢复工作做简单技术分析，帮助更多关心数据恢复这件事的人能够更好的理解技术原理和时效挑战等热点问题。

针对人为恶意删除数据库

人为恶意删库在国内IT圈已经不是第一次发生了，此类事件由于其高破坏性、高突发性、高随机性，给众多中招企业带来了不可承受的打击。

从数据恢复技术的角度来讲，行业内针对这种问题的解决方案都是根据具体场景来制定的。

在技术难度上，Windows系统低于Linux系统和Unix系统，Sql数据库低于Oracle数据库和MySql数据库。

数据能否恢复的主要难点：数据被删除后新写入的数据量，是否使用SSD

数据能否成功被拯救，需要评估数据丢失后数据环境的破坏程度。不同的丢失原因，评估的方向不同，下面主要介绍针对此次丢失原因的评估方向，这就要涉及到操作系统的部分知识了。

我们常见的数据储存介质分为HDD硬盘（机械硬盘）、SSD硬盘（固态硬盘）等，而两种硬盘处理删除文件的机制却大不相同：

HDD硬盘：我们之所以可以将删除的数据重新恢复出来，是因为在操作系统的删除逻辑里，只是把数据打上了删除标记，数据并没有真正从硬盘中删除。但此时，如果操作系统写入新的数据，就有很大机率将这些被标记为已删除的数据覆盖掉，而一旦发生覆盖，数据就彻底丢失了。

SSD硬盘：由于SSD自身机制原因，为了提高SSD写入效率，操作系统开发了Trim指令来帮助SSD提效。但这种提效的方式会导致每一次数据被标记为被删除后，SSD便会在很快的时间里对这一区域做清除操作，彻底销毁这些数据。此时，除非在系统层面关闭Trim指令，不然SSD针对人为删除这种情况几乎是无法恢复数据的。

鉴于微盟并没有直接对外宣布数据丢失，而是花费了几天时间进行数据抢救和恢复，可以判断，微盟并非这种情况，以下两种情况的概率更大。一，使用的是HDD硬盘，二，使用SSD服务器但没有开启Trim指令。这两种情况都为数据恢复留下了一线生机。

另外，通过总结之前发生过的人为恶意删库事件，可以看出这种破坏多发生在非工作时间，用户、业务管理者、运维人员很难第一时间发现，难以及时停机或由于业务连续性因素即便发现也无法停机，或多或少会导致数据覆盖的现象发生，这给数据恢复造成了很大的困难，难以保证将100%的数据完美恢复。

当然，在删库同时将业务环境也破坏，使整个业务系统瘫痪，这会阻止新数据的写入，反而对数据恢复成功率和完整性有了很大的帮助。

数据恢复实施流程：环境克隆、工具扫描、数据导出、数据整理、数据还原

1. 环境克隆：针对LUN做克隆，使整个恢复操作在镜像版本中进行，避免破坏原数据环境，降低恢复失败的风险。如果LUN容量大太，无法有同等空间存储镜像，也可以克隆每一块物理硬盘，但克隆完成后需要在恢复环境虚拟重组成RAID阵列，才能对LUN展开恢复。由于多了虚拟重组的步骤，因此会额外增加恢复时间。

2. 工具扫描：根据用户使用的文件系统对文件的组织方式，使用通用或定制开发的工具对LUN进行扫描，寻找被删除的数据，此过程视LUN容量大小决定扫描所需时间。

3. 数据导出：将工具扫描找到的被删除数据导出到第三方存储空间，此过程视找到的数据量大小决定导出所需时间。

4. 数据整理：对导出的数据库或非结构化数据做校验、归档。

5. 数据还原：将数据库或非结构化数据重新导入原系统环境，使业务系统重新上线，此过程视需还原数据量大小决定所需时间

数据恢复实施难点：数据量规模过大、潜在硬件故障风险

1. 数据量规模过大：由于技术方案相对成熟，人工效率不是瓶颈，通过计算硬盘I/O速度，可以大致评估出整个恢复过程的时效。但是数据量规模过大会导致容错率降低，每一次人为原因或设备原因导致的错误都会增加很多额外的恢复时间。同时数据量规模过大还会导致恢复所需资源的增加，对整个恢复的成本造成很大的影响。

根据微盟的上市公司公告，微盟有300万注册用户，以及7万付费用户，据此估计，微盟被删的数据体量应该非常大，甚至有可能达到百T级别。如果按照整个恢复过程不出任何错误，同时恢复资源完全到位，所以数据并行同步恢复的的状况来评估，至少也需要5到7天的时间来完成。而每一次微小的差错都有可能增加1到2天的额外恢复时间。截至当前，微盟仍未能完全恢复数据，想必也是因为数据量规模过大造成的。

2. 潜在硬件故障风险：了解数据中心运维的人都知道，企业级设备最怕关机重启。多年运转顺利的设备，可能因为一次关机维护反而暴发了硬件故障。因此在环境克隆这个阶段，有一定几率会遇到硬盘I/O错误或其他硬件类问题，这种故障轻则导致恢复时间延长，重则影响镜像完整性，给数据恢复的成功率和完整性造成很大的影响。

联想数据恢复中心专家赵榛认为，此次微盟数据修复工作是一个较大的工程。为了争取数据修复的实效同时保证修复的效果，相信微盟每一步都非常谨慎，争取在不耗费额外时间的前提下，将丢失的数据找回来。我们目前还很难对最后的结果做预测，但作为从业者，还是由衷的祝愿微盟可以早日渡过这个艰难的时刻。