文章摘要：根据微盟发布的通告来看：23日傍晚时分出的事儿；与腾讯云技术团队一起研究修复；老用户数据修复时间预计在28日24点前完成基本上这波删库跑路是“伤筋动骨”的类型。就这几点，基本可以看出来备份数据应该也被一并删除了，这次事件直接影响了300万左右的商家。微盟是做什么的？微盟是为中小企业提供微商城、智慧零售、餐饮o2o、小程序等一体化解决方案的，也就是说，微盟提供了一个类似淘宝的平台。单看微商城这一条，
根据微盟发布的通告来看：
- 23日傍晚时分出的事儿；
- 与腾讯云技术团队一起研究修复；
- 老用户数据修复时间预计在28日24点前完成
基本上这波删库跑路是“伤筋动骨”的类型。
就这几点，基本可以看出来备份数据应该也被一并删除了，这次事件直接影响了300万左右的商家。
微盟是做什么的？微盟是为中小企业提供微商城、智慧零售、餐饮o2o、小程序等一体化解决方案的，也就是说，微盟提供了一个类似淘宝的平台。
单看微商城这一条，顾客无法正常下单购买。对于这300万左右的商家来讲，如果数据无法恢复，当前又处于疫情期间，商户业务将直接停摆。如果数据恢复异常甚至丢失，对商户的打击是毁灭性的。
对微盟来讲，也势必将流失一大波客户。不管出于什么原因，微盟一家上市公司，为300多万家商户微服务的企业，居然会发生删库这种恶性事件，足以说明微盟在管理上、在技术上都存在很大的隐患。
对删库的员工来讲，牢狱之灾是躲不过了。至于他到底为什么要这么做，以及背后有什么隐情，那不是我这个回答所关心的事情。人嘛，做了错事就要认，挨打要站好。
对微盟的竞争对手有赞来讲，这无疑也是给他们敲响了一次警钟。除了这么一次查漏补缺的机会之外，带来的可能还有在微盟落难的不少商户入驻，这也算是一个发展的机会。
至于，未来微盟跟有赞之间的差距会不会因此拉开，那是后话了。毕竟这次事件总归属于人为的偶然事件，波动是正常可预想的。
只是苦了那些商家和急着购买的顾客们……
作为信息安全运维话题的活跃用户，我们也来详细聊聊如何避免企业数据被删的问题吧
说实话，第一次听到微盟这家公司，对其业务模式不太熟悉，如果猜错请见谅
其业务应该是To B型，所以其数据量的大小应该不大
因为不像大部分To C的互联网公司那样有海量用户、百万日活、千万并发之类的情况
说这个有什么含义呢？
这意味着，其数据备份机制在技术层面会更加容易实施
To C型业务，除了数据量大，而且变更频繁，以MySQL为例，一天的binlog（即数据变更日志）数据都会非常大
我们备份通常是全库冷备+binlog热备的形式
全库冷备一般是每天凌晨定时调度执行，这种模式备份出来的文件我称为A，然后binlog是每隔一段时间，可能是几分钟到几小时生成一个文件，就将这个文件备份到其他地方，这个文件成为B
那么运维或者DBA的职责就是尽量地保障这份A和B绝对冗余与安全，另外，A和B可能有很多个版本，因为我们是每天备份的
有一些常规的方法，例如多副本保存、异地保存、线上线下保存、文件加密权限隔离等等
如果A和B的文件不大，比如一天不超过1个G的话，做这些冗余备份的措施是很方便的
因为一旦文件大了，你得额外考虑存储成本、带宽峰值是否能满足我们所设定的备份文件保留期限
但99%的中小企业都不会做这些看起来相当麻烦的事情
原因有一些，比如高层重视度不够、运维团队经验不足、企业抱有侥幸心理等等
据说这个运维当事人，是一位只有2年运维经验的同学，已经是该公司的“核心运维”了
那该公司出现数据丢失这样的系统性灾难，也真是迟早的事情
除了备份，还有恢复也是需要定期演练，否则有可能关键时刻，这个备份文件竟然是用不了的
比如数据错乱、乱码、版本不兼容等等的可能性
所以一个月做一次数据恢复演练，应该列为运维团队的日常安排里面
否则，如果有一两个别有用心的运维人员，想做什么坏事的话，应该不是难事！
洞察眼MIT系统作为信息安全运营商，前几期详细讲述过如何防止企业内部数据泄密的问题，可以根据不同行业的企业定制数据防泄密解决方案，部署数据防泄露系统，该系统可以对电脑中的全盘文件或指定类型的文件，加密文件在公司内部正常使用，不改变员工的操作习惯。 未经领导批准，擅自将文件传输到企业外部，将无法打开，显示为乱码，从根本上保证数据的安全。同时可对企业文件数据自动定时备份。完全可以避免因数据被删造成企业运维瘫痪事件的发生。
同时发给客户等第三方的文件在得到领导批准后可以进行解密。 另外，对于发送的文件，可以控制对方的阅计次数、时间限制、打印禁止、复印禁止、截屏禁止、修正禁止等权限操作。 彻底阻止数据的二次泄露。
建议企事业单位及早部署文件加密软件，对文件加密，图纸加密，文档加密，各类研发文件加密,同时支持加密各类自定义格式文件。
