本文经授权转自公众号 "CSDN"（ID：CSDNnews）。

受访者 | 腾讯云技术人员

记   者 | 胡巍巍

出   品 | 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夜不间断工作，他们像极了“救火队员”。 每一次互联网事故的修复，网友能看到的，是产品又能重新使用，看不到的则是工程师们在背后的废寝忘食。 这位工程师，可能是你的家人，可能是你的同事，也可能是你的朋友......我们身边从来不缺乏这样的“救火队员”，所以以后对程序员们少些调侃 （秃头） ，多些爱护吧！
声明： 本文转自公众号 “CSDN” （ID： CSDNnews） ，未经 授权 禁止 转载 。

往期精彩：

• Ubuntu 对比 CentOS 后该如何选择？

• 漫画：什么是公有云、私有云和混合云？

• 漫话：全球 IPv4 地址正式耗尽？是时候说说到底什么是 IPv4 和 IPv6 了！

• Linux 服务器更换主板后，网卡识别失败的处理方法

• CentOS Linux 7 安全基线设置

• 一次"幸运的"集群操作与修复经历

你点的每一个在看，我认真当成了喜欢