其次，在北京、上海、南京等地区建设全备份的冷备系统架构，借助腾讯云IaaS的底层效劳才华，建设高可用的同城双活架构；所有非构造化数据使用腾讯COS对象存储系统停止归档保存并启用多异地复制功能。

扫描仍在继续测验考试，工程师们逐步发现了更大都据的踪迹。到了周三深夜，新的问题再次呈现：工程师们发现，现有的数据备份中，短少大文件数据，而这些大文件极有可能是微盟最核心的业务数据。它们没有被扫描出来。

来自微盟的这种信任是责任，也是压力。随后七天七夜，徐勇州和技术团队，与微盟一道，投入到了这场不眠不断的抢工夫救数据战斗中，竭尽全力去完成这项“不成能完成的任务”。

不寒而栗的“手术”过后，更大的挑战在于如何将数据完好地提取出来。

庆幸的是，经过排查，起因是由于新加的系统盘触发了原来效劳器中的硬件护卫机制，不难处置惩罚惩罚。半小时的技术施行后，全副数据初步正常读取。这个举措为修复抢回了一天多的工夫。

微盟即时启动紧急响应机制。由于内部相关技术才华缺乏，微盟也向腾讯云停止了紧急求援。

事后外界的各种技术解读，大多会提到一点，有没有备份数据？为什么不用备份数据快捷复原？外界并不分明的是，备份数据也被一起删除了。事情的重洪流平远超外界想象。

徐勇州是腾讯云运维中心和客户效劳部门负责人，也是微盟这场抢救流动的总指挥，就是为了“片面找回数据”这个目的，他和腾讯云的多位技术专家，结合微盟团队一起，整整奋战了七天七夜。

2月29日凌晨，恢复到最后一台效劳器时，徐勇州和技术团队盘查发现，前面找回来的那些数据只要整体数据量的70%-80%。依照前面核心数据恢复的方法推演，假如逻辑创立的话，此时恢复的数据应该是100%。

微盟在数据恢复公告的最后着重提出“最后再出格感谢腾讯云团队”，看到发出的公告，徐勇州最大的感受是，终于可以安心的睡个好觉了。

任务的十万火急，让每个人睡觉都只敢定2个小时的闹钟，闹钟一响就接着战斗。24日下午，已经连轴工作30多个小时的徐勇州，才第一次短暂休息。微盟CTO黄骏伟，也是始终保持在线，与腾讯云团队沟通修复过程中的技术问题。

深信数据必定还在的是微盟CTO黄骏伟，他一再对徐勇州和腾讯云技术团队暗示，“奉求你们必然要帮我们找回来”。

业内经常调侃的步伐员删库的事件，就如黑天鹅一般，毫无征兆地发生在微盟身上，业务霎时全线解体，数百万商家无奈成长业务。

终于，一块又一块的数据被拼接出来，核心数据逐渐被修复。“太不容易了，表情真的跟过山车一样。”

事实上，徐勇州有本人的实践：尽管文件相关的索引节点信息被删除了，但只有没有数据写入，数据块还是在的，这为修复提供了一种潜在可能。

依据微盟公告，微盟将采纳以下门径提升对数据安详的保障：首先在权限打点方面，使用腾讯云CAM权限系统停止云资源打点，严格执行分级授权和最小集权制度，对高危险动作执行二次授权制度；使用腾讯云营垒机交流自建营垒机，停止细粒度许诺权分级和授权打点。

工夫倒回至23日下午7点，其时正在停止居家隔离的徐勇州，可能也想不到接下来的七天七夜，他和30多位同事会这样度过——

徐勇州和技术团队不想放弃：核心数据找不回，股票配资网，影响的不止是微盟，还有那些商家的利益。“有一点希望都得尝尝看。”

惊醒徐勇州的，就是新系统盘装置，在濒临完成的时候，数据硬盘发出掉线警告。 “所有人的心都悬到了嗓子眼。终究这些数据可能就对应着微盟的百亿市值，不能出任何闪失。”徐勇州说。

“做到100分，在云上摈除新生的微盟”

周四上午，第一台效劳器的第一块扫描胜利，导回数据库检察是完好的。“计划一可行！大家自信心一下子又起来了。”

他们很快面临了第一个困难的抉择——

但“1*N”的工作量也不小。最大的一个文件，由7块碎片组成。找到开头以后，工程师初步扫描其他有类似性的块。运气好的时候，类似度可能只要一块，运气欠好的时候，有二三十块。每停止一次拼接，都必要把数据块从新到尾扫描一遍，验证能否匹配。这必要大量的计算力。为了加快扫描和验证，腾讯云效劳器团队还临时从上海机房调拨了100多台效劳器停止算力撑持。

数据库连同备份文件被全副删除，且数据体量到达数百T。这种状况，哪怕是专业的数据恢复公司，也只敢慎重评估20%摆布的修复预期。难度可想而知。

技术团队很快对修复计划达成一致：鉴于数据库效劳器上文件数量多，类型复杂，文件的提取和确认难度很大，而备份效劳器上文件类型单一，数据集中，且微盟数据被删后，股票配资，硬盘没有被二次写入，实践上里面可能存在相对完好的备份数据，团队决定从备份效劳器动手，测验考试恢复数据。

作为在SaaS领域无足轻重的效劳提供商，微盟有300万注册用户，以及凌驾7万的SaaS付费用户。

“这恍如就是重症病人进了手术室”。徐勇州必要去完成一场抢救，尽管看起来救回来的希望不大，但 “病人的命就在你手上，客户的存亡生死，我们不成能袖手旁不雅观”。

腾讯云监控中心发出告警，监测到微盟陈列在黑石物理效劳器上的业务呈现大面积无奈响应的状况，同时微盟也通过腾讯云售后和商务团队同步了这一信息。与此同时，微盟的商家效劳群里已经炸开了锅。

在徐勇州看来，微盟事故的发生对其他企业的数据安详护卫也敲响了警钟，数据安详事件暗地里折射出的是，仅仅依靠单点防护难以到达真正的安详防护效果，而构建基于全生命周期的安详防护成为一定选择。

在过去的一周中，所有微盟平台上的用户和商家都因为一场运维事故而被迫停滞了一周工夫。对于他们来说，效劳没有恢复的每一分每一秒都是收入和用户的丧失，用“心急如焚”来描述恐怕有过之而无不及。

然而，即即是方法论经过了验证，但就像写步伐一样，在一些轻微的处所总会有一些意想不到的bug呈现。

通常来说，数据修复的第一步是对源数据停止镜像拷贝，以制止修复过程中源数据受损的风险。假如接纳网络传输停止拷贝，以微盟的数据体量，光是数据拷贝过程就至少必要2天以上，会让数据修复的工夫进一步加长。“微盟和商家们都等不起。”

数据中心现场硬件工程师通过腾讯会议长途同步操纵细节

腾讯云安详团队与微盟技术团队随即停止结合排查。很快，溯源到微盟陈列在自建MySQL数据库上的核心业务数据，被微盟某运维人员用一种让步伐员闻风丧胆的Linux系统下文件删除命令，整体停止了不成逆的删除。

前期停顿很顺利，但在濒临完成的时候，团队最担忧的事还是发生了。25日凌晨6点钟，徐勇州趁着工作的间隙打了个盹儿。可是很快，他就在半睡半醒之间，被电脑里说什么“加载不上”吓到，一激灵就醒了。

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

团队的第一反馈是：难道腾讯云黑石物理效劳器效劳呈现问题了？徐勇州和团队很快排除了这种可能性：黑石物理效劳器集群整体运行正常，独独微盟业务大范围遭到影响，可以揣度问题应该不是出在云效劳商这侧，而是在微盟业务侧。

3月1日晚，微盟发布公告称，数据已经片面找回。同时颁布颁发根底设备全力上云。

“也就是说，即便这份数据完好，那17号到23号当天的数据也是缺失的。”徐勇州解释，“这个事情，好的一面是明确地讲述我们数据还在，恢复有希望。但是只找回一局部数据意义不大，我们必要完好的数据。”

最后，借助腾讯云数据库MySQL的数据高可用和安详体系，逐步放弃自建数据库效劳，迁移到腾讯云数据库（CDB）,提升数据库跨可用区和易地灾备的才华，同时，将原来竞争的黑石1.0物理机片面晋级黑石2.0，片面使用云主机。

就恍如整块拼图被打散扔进了大海里，一块一块打捞上来是第一步，拼接是第二步。差异的是，拼图时还能够依据外形来判断哪些可以放在下一块，而拼接数据块，基本无奈通过肉眼识别，只能靠一块块去扫描，寻找类似度高的拼接到一起，再从头扫描看断点能否能重合。

为了做到万无一失，徐勇州还邀请了腾讯内部多位硬件专家通过腾讯会议停止长途视频领导。“所有的专家都在线，几十双眼睛，在屏幕前盯着现场工程师的每一个动作，以担保精确无误。”

23号晚上，腾讯公司副总裁、腾讯云总裁邱跃鹏接到团队陈述请示。他指示团队“岂论微盟的故障是什么起因触发，腾讯云都要不惜价钱全力撑持”，并即时决定由徐勇州组建一支30多人的技术团队，与微盟一起钻研制定消费环境和数据修复计划，同时协调了内部等多个部门做好技术辅佐和资源保障。

庆幸的是微盟的备份机制还比较完备，数据的笼罩度和完好性查抄等工作都做的十分细。徐勇州发现，文件类型只要一种，那么就能很容易判断出哪块是开头，拿着开头去找剩下的块，把工作量从“N*N”降低到“1*N”。

又是一夜未眠。3月1日凌晨，终于在另一个的区段中，被遗漏的数据被“打捞”了出来。原来，有一局部数据在提取时因为环境等各种起因被忽略了，在把所有的数据都汇总整理和对齐后，很快找到了对应的那段未提取区段，然后又是停止紧张的“打捞、拼接、扫描、验证”，但这时的团队已经是技术娴熟，胸有成竹。

从可行到胜利，中间仍有困难险阻。数据公司提取出来的单一的块，从体积来看还是达不到微盟核心文件的大小。这意味着，要取得完好数据，必要停止数据“拼接”。

值得一提的是，由于团队只能长途办公，从第一天初步，腾讯会议就成为了最高效的协同工具。在整个修复过程中，腾讯会议处于7*24小时开启状态，从未持续，各个业务团队累计通过腾讯会议停止766次入会沟通。

微盟3月1日发布数据片面找回的公告

“用失望来描述其时的表情都不夸张，核心数据假如没有，等于前期的工作都白做了，其他数据恢复了都没意义。”徐勇州说。

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

“不成能完成的任务”

徐勇州通宵未眠。思量再三，决定两条腿走路：一是测验考试对磁盘的每一块（block）停止二次扫描；二是让腾讯云的操纵系统团队从OS底层动手，制定数据恢复计划PlanB，这必要极其庞大数量的测验考试和数据验证，“计划一能胜利是最抱负的，计划二就意味着数据恢复的工夫不确定，业务停摆，继续失血。”

微盟公揭暴露以后，腾讯云技术团队在微信群里收到了微盟团队的集体称谢。那个全程见证事件停顿的超长腾讯会议的会议号，被团队提议作为一个永恒的番号生存。

剩下的这些数据去哪了？到底是哪个环节出了问题？“我们的目的是要做100分，哪怕失掉5分，对一个商家来说可能就是全副。”徐勇州和团队连夜把所有的数据又从头盘点了一遍，把验证的逻辑再推导了一遍：扫描了多少？提取了多少？哪些校验过？哪些没有？

尽管最初大家并不敢断言数据是否修复，随着两边团队的独特攻坚，大家存眷的焦点逐渐酿成数据能不能做到100%的修复。

“在大海中打捞拼图”

2月28日，深夜，数据修复乐成在望。

23日晚，不眠之夜。徐勇州连夜率领团队与微盟方面停止处置惩罚惩罚计划的讨论和制定。

这样做的按照是，数据硬盘的安康度优良，最好的股票配资网，且腾讯云技术团队有丰硕的硬件办理经历，有较大掌握在源数据不损伤的前提下停止扫描。这相当于借助一根体外供血管在体内完成这场手术，通过完满的技术，实现效率与完好性兼顾。

另一种习用的办理方式是将原来效劳器上的硬盘拆装后挂载到新效劳器上，以并行的方式停止“硬盘对拷”。这样可以节约工夫，但风险是一旦半途呈现故障，源数据可能会因而完全损失。“对于仅有一次这样修复时机的微盟来说，这样做风险太大。”

徐勇州已经不记得这样的“打捞、拼接、扫描、验证，从头打捞、拼接、扫描、验证”停止了多少次，只记得每一次都是四五个小时的煎熬。“大家每隔一会儿就在腾讯会议上吼，好了没，好了没，快看看！”

2月26日，数据恢复工作已经成长了三天三夜。当天中午，第一批次的数据拿到，导入数据验证正常。但他们很快发现，他们扫描出来的最新一份数据是截止到2月17日的数据拷贝，完好性尚不确定。

一场168小时的腾讯会议

事实上，此时扫描出的数据约莫是微盟数据整体的30%摆布，已经合乎以至凌驾了此前行业对此类事故恢复水平的预期。“这难道真的是一个完不可的任务？”

3月1日晚上10点半，已经停摆一周的微盟发出公告：截止到3月1日晚8点，在腾讯云团队辅佐下，经过7*24小时的努力，我们数据已经片面找回。微盟平台上的商家和用户们，终于松了口气。 微盟3月1日发布数据片面找回的公告 作为在SaaS领域无足轻重的效劳提供商，微 ...