从微盟被删库谈数据灾难的灾后重建

本文主要是介绍从微盟被删库谈数据灾难的灾后重建，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

近日，微盟官方发布：微盟研发中心运维部核心运维人员贺某，“由于个人生活等方面压力” 于2020年2月23日晚7点，利用VPN登录公司内网的管理机，然后对微盟线上生产环境进行了恶意破坏，导致微盟业务停摆。官方公告如下：

“MySQL数据库从入门到删库”，曾几何时，这个看似段子的说法，多次真实上演。

恢复时间比较长
数据就是金钱，然而很多人只是嘴上说说
资产数字化综合征
云平台依然是个好的避难所

下面冬瓜哥就展开谈一谈。

恢复时间比较长

RTO，Recovery Time Objective，指的是在设计灾备系统时，从灾难发生一直到业务恢复所消耗时间的期望值。RTO包含两部分时间，分别是数据恢复时间和业务恢复时间。前者是指将备份数据导入到生产系统中的过程，后者是指在恢复之后的数据基础上，每个节点上的应用系统顺利启动，并最终重新组合成集群，最终恢复业务。一般来讲，数据恢复时间比业务恢复时间要长一些

从这次的RTO判断，老贺这位兄弟这次玩的估计比较大，应该不是个把数据库的删库操作，而是大范围全删，甚至可能连带应用系统文件、周边数据一起删了。其实，全删了反而更好解决，怕的是大范围随机爆破，为什么呢？举个例子，原本的数据是：12345678，这是一组相互匹配、一致的数据，在被定点随机删除之后成为：1x3x5xx8，此时，你可能倾向于从备份集中抽出2、4、6、7这四组数据定点恢复，如果当时的备份粒度并没有这么细，那就没法单独抽出，就只能整体恢复。

上述其实就是“一致性组”，在一个复杂系统中，数据之前是有关联的，不能孤立的单独备份，而要统一在一个同步点上开始备份，所有这些关联在一起的数据组成了“一致性组”。恢复时必须将整个一致性组完全恢复，才具有上层业务一致性。

如果破坏者用更细粒度的定点删除，弄一个复杂脚本，比如删除某个表中的特定数据，等等。此时你光是前期排查过程就得花费更多时间，而且如果你想单独把这些窟窿补上，那真是比从乱麻中抽丝还难，所花费的时间成本可能会超出整体恢复。

纵观这些年的一些灾难，本次的RTO相对还是比较长的。甚至有人怀疑，老贺把备份数据都跟着删除了。冬瓜哥推测了一下几种可能性供大家参考：

只删了某个关键库及其备份。微盟属于电商平台，大凡电商平台的数据库数据量都非常庞大，繁枝末节的业务和数据关系，如果是留有备份，则基本步骤就是拷贝库文件和redo log，然后执行log重放。假设数据恢复和业务恢复时间比例为8:2，拷贝文件和log重放的时间占比为8:2，那么拷贝文件耗费,81.6小时，假设核心数据库集群节点数量64，每节点配备万兆网卡，那么恢复吞吐量约100MB/s，总恢复量约为29TB。作为微盟这类二三线电商平台，核心数据库应该不至于这么大的容量，所以怀疑这次连备份都被删，而只能从其他途径将数据从其他库或者数据源进行导入，重新生成数据库，这种方式非常缓慢。
大范围删库但没删备份。另一个可能性，备份都还有，但是线上数据几乎都被删除，所以也需要耗费很长时间。
大范围删库及删备份。这个就更麻烦了，有可能还会导致有些数据永久丢失。
删了云端的数据但是数据备份在本地且没删。这个可能性也是存在的。目前一些企业也多采用这种方式，或者云端部署生产系统，而本地保留备份数据，或者相反。这样的话，将备份数据通过广域网上传云端，速度就非常慢，除非临时从运营商处开通裸光纤专线。
数据库和应用系统关键文件被删。此时，业务恢复在RTO中的占比将大大增加，而这种操作牵扯到一系列复杂配置部署，可能比单纯恢复数据要麻烦的多。尤其是互联网平台，各种子系统多如牛毛，关系复杂，架设之后，还需要互通性测试，都是耗时耗力的活。
RPO太高，缺失近几天的数据。这个也是潜在可能性之一，系统的全备份可能一周一次，其他时候都是每天增量备份，如果增量备份和线上数据一同被删除，那么从原始数据源导入重建数据库，又是耗时耗力的事情了。
可能使用了自建数据库。如果使用了自建数据库，那么备份恢复等流程就无法与云平台兼容适配，这可能进一步增加了恢复的复杂度。

最差的情况是，连同数据源一同销毁。所谓数据源头，比如银行各分支保留的本地数据库以及纸质单据凭证等等，这些数据可以重新汇总到总行重建数据库，哪怕只留有纸质单据，也可以靠扫描提取或者人工录入，虽然过程极慢，但是总可以回血。而如果这些数据也一同被删除，那就非常危险了，此时需要底层数据恢复，牵扯到更复杂高技术含量的手段，而且恢复概率并不是100%，详见这篇文章。不过有一点庆幸的是，如果真的发生了，业务停摆之后，就不会对硬盘进行写入操作，此时“原地满状态复活”的概率还是有的。这也是最好的结果了。

数据就是金钱，很多人只是嘴上说说

冬瓜哥近几年也逐渐看透了，也就是，没有经历过灾难、苦难的人，你和他描述灾难的黑暗，他会认为你是精神病，甚至和你决裂。只能痛醒，绝不可叫醒，否则他会恨你打扰了他的美梦。数据容灾这件事情上，也是同样的道理。

冬瓜哥早年曾经在某银行分行担任系统管理员，当时的系统很老，服务是两台SCO UNIX做冷备，也就是其中一台开机但不启动应用，主机出事后，手动切换到备份机，后来才上的一套Infosave HA软件实现把上述切换过程自动化处理，这是业务容灾。对于数据容灾，冬瓜哥每天用DTX磁带机将服务器硬盘上的数据备份两份，其中一份要交给分行副行长，并让他携带回家保存。当然，这种级别的数据和业务容灾已经是相当高水准了。即便管理员作死删了库，那么高层管理者家中异地永远都会保存有最起码前一天的数据全备份，除非管理员和他串通，而这种概率几乎为0。所以这里面可以看到分权的制约的重要性所在了。

银行系统的两地三中心经典备份方案，也可以从中借鉴一些，比如数据实现两地三份，同城的两地保留各一份，异地保留一份，离生产中心越近的那份的RPO越小。另外，提供能够随时将异地备份用货车直接运送到生产系统做本地恢复的条件，这样在大数据量恢复时可以极大降低RTO。

一线互联网企业在数据容灾这部分做得已经相当到位，但是并不能说没有漏洞，一切内部主动破坏的风险还是很高，如何杜绝这些漏洞，真是一个值得思考的问题。目前看来，建立分级授权机制是个可行的方法，高危操作需要多人仲裁表决才可以执行。

综合来讲，冬瓜哥对数据资产容灾方面有一些建议供大家参考：

防物理损毁。使用Raid卡或者软Raid或者多副本技术，以及远程复制容灾技术，让数据在不同的地点有多份副本，可容忍单块甚至多块硬盘故障，甚至容忍机柜级甚至数据中心级故障。根据成本等条件需求综合分级部署。
防逻辑损毁。数据的逻辑损毁典型的例子比如误删除、误改动且保存、静默损毁。这些变化将会一同保留在数据备份中，即便恢复也是错误的。为此可以做高频备份，出错后使用之前的备份覆盖，但是这样成本较高。一个低成本解决办法是使用快照，快照占空间小，而且回滚速度快。快照详细原理可见《大话存储终极版》一书。对于云用户而言，多副本、快照、备份，最好都用，起码做到快照不要停，这是你唯一的速效后悔药。
防恶意篡改。这种场景本质上也是一种逻辑损毁，但是带有恶意性质。目前业界有一些方案，比如WORM（Write Once Read Many）技术，其在底层硬件层面只允许追加写，不允许覆盖写和删除操作，除非能获取底层固件级权限，已达到防篡改目的，不过这个场景应用有限，因为多数业务都是需要覆盖写入的。

资产数字化综合征

再来分析老贺，不管这老兄是处于什么原因，像官方说的生活压力也好，或者是工作压力或者矛盾也好，这种发泄或者报复，在网络上会被放大。假设，如果让老贺当面把数据中心给炸了，他绝对要考虑考虑而且精密策划，而且很有可能还没开始就放弃了，因为现实是沉重的。但是如果这一切能够通过在网络上敲一条命令来搞定，自己坐在电脑前，喝着茶，就能决胜千里，犹如网游中的杀怪升级一般，这个精神门槛是非常低的。

再比如，网购。如果在实体店里，让你哗哗点钞票付款，你估计会多考虑一些的。而在网络上，宣传图都是经过去噪点美白高亮高对比度处理的，你下意识会认为这就是好货，值！就是想买，无非就是敲几个密码的事情。所以购物门槛就降低了。

再比如赌场为何不用现金，一是不方便，二是为了让你看不到真金白银，看到的只是一堆塑料筹码，你在all in时都没有疼痛感。

可以将这种心理称为“资产数字化综合征”，当资产变成数字化符号化之后，会陷入一种不当回事的轻飘状态，很容易掉以轻心。对于数据，也是如此，每一个字节都是钱，然而只有当它们突然没了的时候，亡羊补牢。

越来越多的东西其实都被数字化了，比如你的言论、你的人生总结、朋友关系等等。除了具有放大效应之外，也同时具有被一锅端的风险，而端你的人也丝毫不把你的这些数字资产当回事的，认为这无非就是一些数据而已，又不是钱，是么？

云平台依然是个好的避难所

最后，数据放在云端的保险系数还是相对较高的，因为云端有足够多的公共资源作为支撑。在数据安全方面，目前所有的云提供商都提供了快照，或收费或免费，快照是个很好的技术，像这种数据删除操作，使用快照可以迅速恢复或者回滚到某个历史时刻，然后再通过其他方法补平到最新数据状态。微盟入驻的是腾讯云，但通过数据恢复的进度判断，微盟很可能没有充分用到云上的备份功能。目前各家云厂商均提供了备份功能，比如虚拟机的镜像备份，硬盘快照备份，数据库备份等等。以各家云硬盘的快照备份为例：