3月1日晚间，微盟发布公告，称在合作方腾讯云的协助下，数据已经全面找回，预计于2020年3月3日上午9点完成数据恢复上线。
腾讯云官方微博也发布消息，表示数据恢复的复杂度超出所有人想象，“连续通宵、排除万难，终于攻坚成功！”
不过，数据虽然恢复了，损失依旧惨烈。
事故发生在2月23日晚上，微盟公司的SaaS业务突然崩溃，基于微盟的商家小程序都处于宕机状态，300万家商户生意基本停摆。
而造成此次严重事故的，竟然是微盟的一名员工——凭一己之力，删除自家公司数据库，累计市值蒸发超30亿港元。
针对事故给商家造成的影响，微盟表示：
管理层深感自责和愧疚，准备了1.5亿元人民币赔付拨备金，其中公司承担1亿元，管理层承担5000万元。
经过这样“段子”一样的事件，也给企业敲响了一个警钟——“数据安全大于天”。
赔付1.5亿元，决定全面云上
今天，微盟在其官方网站上发布了自愿公告《SaaS业务生产环境和数据恢复》，描述此次事故及修复过程，以及赔付方案和数据安全保障计划。
根据茹炳晟的理解，至少要跨过下面这些技术的槛：
⑴获取全量备份，如果存在异地的冷备或者灾备，那是比较理想的情况，但是由于全量备份通常非常庞大，所以需要较长的时间完成文件的传输和校验。
⑵获取增量备份，很多时候增量备份没有来得及做异地容灾备份，所以很大概率要从磁盘恢复，这又是大量的时间消耗，而且同样不能保证100%完全恢复。
⑶获取binlog，binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE等）以及表数据修改（INSERT、UPDATE、DELETT等）的二进制日志文件。文件尺寸不小，而且个数也很多。
有了上面这些作为基本的输入，才能开始数据库层面的数据导入和恢复工作，这个过程也需要花费大量的时间，而且这是基于上述文件都可以100%得到为前提的。
数据库的数据文件和备份文件往往很大，那么只要有个别数据区出现了重写，那么恢复出来的文件就是不完整的，这个时候就需要人为介入来进行修正，这个工作量以及技术难度就会很大，有时还会需要借助专用的仪器设备。
除此之外，像微盟如此庞大的系统，各个垂直事业部可能都有各自的业务数据库，这些数据库甚至可能采用了不同的方案，这种架构上的异构性也会给恢复过程带来极大的挑战。
另外，即使部分数据恢复完成之后，也不能立即上线，而要等其他相关数据恢复，并且做好数据的交叉校验，确保数据万无一失，这些都需要大量的时间。
联想云领数据安全实验室负责人赵臻也认为，数据量规模过大，是数据恢复实施难点之一。
由于技术方案相对成熟，人工效率不是瓶颈，通过计算硬盘I/O速度，可以大致评估出整个恢复过程的时效。但是数据量规模过大会导致容错率降低，每一次人为原因或设备原因导致的错误都会增加很多额外的恢复时间。
同时数据量规模过大还会导致恢复所需资源的增加，对整个恢复的成本造成很大的影响。
数据安全大于天
经此一役，也让我们认识到了数据安全的重要性，如何预防这种数据丢失的情况，也开始被更多人讨论。
有一些过来人高赞建议：
公众号“成哥的世界”建议，企业可以使用云数据库产品，因为公有云厂商具有相对比较完善的自动备份和恢复机制，没有机会被删库；做好备份，做好全量备份、增量备份、延迟备份，而且要多机房异地备份；管理好控制权限，用主机安全管控软件或者堡垒机来拦截高危命令；进行普法宣传，给予警示告诫，防止相关人员想不开。
而知乎用户“空白白白白”则建议，企业应当建立敏感数据操作双人复核机制，需要双人审批；用异地灾备或异步通讯的方式做数据实时备份；建立关键应用业务的删库监控机制，做重要操作的时候需要确认。
而从茹炳晟对此次数据恢复技术难点的分析中，也可以看出“全上云”具有相对的安全性。
但同时，也有读者留言反馈道：
作为云管理者，全上云的数据还是能删光的。任何云都有初始化手段，全上云就是把安全交给别人。
那么问题来了，对于“全上云” or “Not 全上云”，你怎么看
本文来自投稿，不代表展天博客立场，如若转载，请注明出处：https://www.me900.com/455290.html
