从微盟删库看CDM应急恢复拉起的重要性


今日一早运维的朋友圈就炸开了锅,网传微盟遭员工恶意“删库”导致系统瘫痪。随后中午,微盟集团发布了官方公告,称SaaS业务数据遭到员工人为破坏,导致业务系统宕机36个小时,目前微盟技术团队正在努力恢复数据,但数据恢复较慢。工程师们正在日夜赶工,尽最大努力协助微盟降低损失。


图片关键词


历史总是惊人的相似!删库跑路事件已经屡见不鲜,作为一个拥有20余年备份行业从业经历的技术老兵,已然见怪不怪了。早在18年9月,我们就报道过一起顺丰高级运维工程师误删库被开除的事件。人为的逻辑错误导致数据丢失给企业带来了不可估量的损失,这也是我们一直以来与用户反复强调的:备份,是企业IT的安全底线。


从微盟的官方公告中可得知事件发生于2020年2月23日19点左右,如果数据修复工作能够达到事故方的预期,预计到25日晚上24点,经过50多个小时的抢修,生产环境将完成修复,新用户业务可以恢复正常服务,由于老用户存在历史数据恢复问题,则需等待至28日24时。不难看出,微盟已经倾力去恢复数据,尽量挽回客户损失,但主备数据库均被删后,数据恢复的难度是可想而知的。

 

作为一个同样经历过领导站在背后、所有人都沉寂地等着数据恢复完成的工程师,甚至可以感同身受这其中的压力与煎熬。恢复存储准备到位,备份系统中最近的备份数据也已经找到,然后是各项恢复操作,数据恢复作业经开始运行!然后呢?等待… … 数据恢复的速度不会因为任何人的焦急加快分毫,在数据恢复作业开始后,我们能做的,只有等待。传统备份的恢复是无法保证一次性恢复成功的,更有甚者,恢复进行了大半才发现一开始备份数据存在问题,无法进行恢复,或者需要修正后再重新恢复。传统备份的数据恢复一旦开始,一切都是未可知。


关于数据丢失事故实际发生的远比我们知道的要多的。看着微盟言辞恳切的“系统故障的通告”,我感到的更多的是无奈。难道这一切没有办法改变了么?不,对于数据保护更全面的规划、对于备份/恢复技术的升级换代,在今天,是完全可以避免这种情况的发生的。


如果备份完成后可不经过数据恢复,直接使用备份数据,而后从容的修复生产数据,再将数据同步回修复好的生产系统并将业务切回生产的数据设备,那么整个业务恢复的时间即可大大缩短;

如果每次备份在完成之后,自动完成数据有效性验证,那么在备份恢复时就不会出现因为备份数据的问题而导致恢复失败。

 

如果… …


IT的技术发展是日新月异的,我所提出的这些“如果“,相信有不少业界的朋友已然了解,通过CDM(Copy Data Management)技术,都已经是切实可以实现的技术了。CDM是一种备份新技术,以“原格式”(Disk Native Format)和“活跃黄金副本”(Live Golden Image)为特征的数据备份方式一夜之间颠覆了沉寂了20年之久的旧备份,技术上更是囊括了备份、复制、存储、快照、虚拟化、及云管等多项特性。“原格式”使得备份数据直接可用,在逻辑错误或人为错误发生的时刻,可以不经过格式转换和IO拷贝,直接挂载到应急主机上,快速应急恢复拉起,业务RTO时间可由小时级甚至天级,缩短到分钟级。目前CDM产品与技术已经受到国内各行业用户认可,正在逐步替代传统备份方式,以创新的数据管理技术成为企业标准的、灵活的数据资源供给中心


图片关键词


此类事件,一而再、再而三,周而复始,编者已经从多年前一开始的兴奋(啊,又出事了,这是多好的备份重要性的教材啊!),到后来的自豪感(看,加了连个通宵,我们把用户的数据恢复出来了!),到今天的更为复杂的感受,我们做了备份、我们能恢复数据,但这一切还是让许多人(相信所有身在其中的人)要经历压力、煎熬和实实在在的损失。我们应该做得更好!

 

愿大家不再经历此类事件,能够拥抱新的数据管理技术,积极改变,有效规避风险,推动企业快速、健康发展。

老虫

2020年2月26日