宝塔服务器面板，一键全能部署及管理，送你10850元礼包，点我领取

　　受访者腾讯云技术人员

　　记者胡巍巍

　　出品 CSDN（ID：CSDNnews）

　　766 次在线会议、临时调拨 100 多台服务器，“调兵”四地工程师，这是腾讯云“救援”微盟的付出。

　　3 月 1 日，“微盟删库”事件收尾，并制定 1.5 亿元赔付计划。这，不啻于一场血的教训。

　　此次灾难，对于有着 300 万注册用户、超 7 万的付费用户的上市公司微盟，后果非同小可。

　　金钱上如此，时间上更是成本巨大。作为国内开发界的佼佼者，即便是腾讯云工程师出马，也花费整整 7 天 7 夜才搞定。

　　那么这次删库到底有多复杂？腾讯云又是如何做完这场堪称技术界的“心脏手术”？

　　CSDN 采访本次参与救援的腾讯云工程师，力图为读者复原“抢救”全过程，也希望能为开发者和企业，带来以此次事件为圆心的建设性建议。

　　事发后，三方组队救援

　　事故发生于 2 月 23 日周日晚上六点多，腾讯云基本和微盟同时发现，随后双方立马建立虚拟团队商量对策。

　　腾讯云投入大约三十多位来自服务器技术、IDC 现场、售后专家、安全、存储、数据库、网络、基础 IaaS 研发运维等团队工程师，这些工程师分别来自北上广深四地。7 天 7 夜中，他们时刻在和时间赛跑。

　　由于任务十万火急，大家睡觉只敢定 2 小时的闹钟，闹钟一响就接着战斗。腾讯云副总裁王慧星，也多次连夜进行技术指导，有次一直忙到凌晨 6 点多。

　　而这次救援的总指挥——腾讯云运维中心和客户服务部门负责人徐勇州，在事件发生后，连续工作至少 36 个小时，才去稍微睡一会。

　　微盟 CTO 黄骏伟，7*24 小时全天在线，为的就是及时和腾讯云团队，沟通修复过程中的技术问题。

　　救援很火急，在分工上需要做更专业的规划，故此腾讯云、微盟以及数据恢复公司技佳瑞康，以最快的时间排查原因、并制定出一套完整的数据恢复方案。

　　排查原因：微盟账号被执行高危操作

　　在排查到底哪个环节出问题时，工程师们发现所有服务器，都处于服务无法响应的状态，是的，所有！

　　然后，他们选其中一台服务器进行重启。重启后，发现系统所有数据都不见了，这说明数据库要么被入侵，要么就是被故意破坏。

　　此时，腾讯云鼎实验室应急专家团队与微盟技术团队随即联合排查，很快就溯源到微盟部署在自建 MySQL 数据库上的核心业务数据，被微盟某运维人员用一种让程序员闻风丧胆的 Linux 系统下文件删除命令，整体进行了不可逆的删除。 

　　后续在对外公告中，微盟也披露了该细节。确定原因后，腾讯云开始制定救援方案。

　　方案分三个步骤：

　　第一，控制受损面。不能让还有机会找回数据的服务器，再出现任何闪失。

　　第二，把数据找回来。这个过程非常耗时，首先要去看到底还有多少数据在，找到数据后再把它恢复出来。恢复之后，还要给微盟验证数据是否完好、导入到数据库是否正常、以及加载到服务器上是否正常。

　　第三，调试数据。数据验证结束后，微盟要根据数据，进行业务上线和联调演练。

　　但是，恢复过程也并非一帆风顺，因为以往没有任何可参考的案例，只能摸着石头过河。

　　数据恢复：行走在危险的边缘

　　找出原因后，就是艰难的数据恢复过程。

　　腾讯云先是把微盟服务器上的源数据镜像，拷贝一份出来，以便保护好源数据。

　　微盟有接近数百T的数据，数据拷贝很花费时间，因此工程师们想了两种拷贝方式。

　　第一种方式，是通过两台机器网络来对拷。他们计算了一下，正常情况下，大概得两天左右，优点是相对安全。

　　第二种方式，是把硬盘挂载。把硬盘从服务器里拔出来，插到有更多盘的设备上，即用多台服务器并行的方式，把每个硬盘数据复制出来，虽然速度快、但是风险大，任何一步细微失误，数据可能就彻底没了。

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

　　确定数据拷贝方式后，腾讯云立即组织团队，进行设备准备。

　　由于是远程结合现场的方式来进行救援，难免要进行远程沟通。远程连线的工程师们，一直用腾讯会议来开会、现场指导、以及战况汇报。

腾讯云数据中心硬件工程师，通过腾讯会议远程展示操作细节。

　　在一些关键操作上，往往是几十双眼睛盯着会议直播画面，因为任何失误，都会带来不可逆的后果。

　　7 天 7 夜里，他们随时起会，腾讯会议也默默记录着事态的进展，开远程会议的账号7*24 无中断。各业务团队通过腾讯会议，累积进行 766 次会议沟通。而这个会议号，也将作为这场战斗的番号永久保留。

　　最担心的事情发生！

　　好在前期进展很顺利，但进行到最后三块系统盘安装时，团队最担心的事情还是发生了——新系统盘安装后，数据硬盘出现掉线。

　　庆幸的是，经过排查，挂载不上的原因，是由于新加的系统盘，触发了原来服务器中的硬件保护机制。

　　确定故障后，工程师们迅速施策，并对全部数据进行读取。相比通常的数据镜像进程，节省 70% 以上的时间。

　　这其中遇到的最大难题是，当肇事者把数百T数据删除后（含备份数据），工程师们再在这么短的时间内恢复起来，其数据量之大、难度之高，远超他们的经验。

　　正式进入数据提取过程时，微盟的大文件未能提取出来，这意味想要获得完整数据，就得进行拼接。

　　这好比整块拼图，被打散扔进大海，不仅得打捞出碎片，还得一片片重新拼图。

　　并且，数据越大，拼接难度也越大。好在微盟的备份机制比较完整，数据类型也比较统一，所以很容易就能判断出哪块是开头，拿着开头去找剩下的块，就会比较容易。

　　这其中，最大的一个文件，由 6 块原始碎片组成。找到开头后，腾讯云开始扫描其他相似的块。运气好的时候，打捞出来的数据，只有一块和原始碎片相似（那肯定就是它了），运气不好的时候 ，有二三十块都是相似的。

　　所以，每进行一次拼接，都要把数据块从头到尾扫描一遍，目的就是验证一下是否匹配。

　　扫描需要大量的计算力，为此腾讯云从上海机房临时调拨 100 多台服务器来支持扫描和运算。

　　团队的心情，也好比坐过山车，每当一个难题被打败，大家就觉得数据恢复有望，立马就嗨起来。但是又出现问题时，心情又跌到谷底。

　　好在最后恢复了 100% 的数据，所有辛苦和付出都值得。

　　7 天 7 夜一百多个小时，这对于所有救援者的体力和意志力，都是巨大的考验。而经此一役，腾讯云工程师的能力再次得到验证，同时参与救援的工程师，也想借 CSDN 表达一些肺腑之言。

　　养兵千日，用兵一时

　　实际上，无论企业把业务部署在自有 IDC（Internet Data Center，互联网数据中心），还是放在外部托管 IDC 里，只要暴露在公网下，都会存在威胁。

　　所以，建议企业从整体上梳理风险点，进行统筹和联动防御，并对外部、内部、大数据等不同场景，准备出相应的解决方案。

　　如果企业已经上云，就要做好云主机的定期快照、云账号权限管控，并对重要数据实施分级管理，同时还要做好加密，从而建立全生命周期的数据安全防护。

　　如果企业使用自建数据库，建议把通过 Binlog 或其他备份文件进行恢复的详细步骤制定成预案，并且定期演练，毕竟养兵千日，用兵一时。

　　对于开发者，可以多关注云计算领域的最新进展，包括云安全、数据防护、加密、恶意攻击等知识，还可以多关注数据恢复的案例实践。

　　上云的紧迫性和必要性

　　此外，没上云的企业，也可以考虑上云。

　　以腾讯云硬盘来说，其采用分布式块存储架构，每个数据块在可用区有个 3 副本，因此可以规避物理磁盘故障和宕机故障导致的数据损坏。

　　另外，通过云硬盘的快照技术，可实现数据“秒级”恢复到一小时内的状态。

　　更重要的是，腾讯云还有数据安全产品，能对安全事件实现全面监控、告警和事后审计等功能。

　　而腾讯云堡垒机，其结合人工智能技术，可以为企业提供运维人员操作审计，还能对异常行为进行告警，进而防止内部数据泄密。

　　坦白讲，过往很多企业，对于安全重视不足。而“微盟事件”依然在鸣叫的警钟，正是为我们敲响。

　　人常说，吃一堑长一智，但最省心的，难道不是他人吃堑你长智吗？可以说，微盟的天价学费，不只是为自己而交，更是为全行业而交。

　　最后，也为所有参与救援的工程师点赞，如果没有他们，微盟的损失可能会更大。7 天 7 夜不间断工作，他们像极了“救火队员”。

　　每一次互联网事故的修复，网友能看到的，是产品又能重新使用，看不到的则是工程师们在背后的废寝忘食。

　　这位工程师，可能是你的家人，可能是你的同事，也可能是你的朋友……我们身边从来不缺乏这样的“救火队员”，所以以后对程序员们少些调侃（秃头），多些爱护吧！