「云头条」与时间赛跑：微盟的数据恢复为什么需要这么长时间( 二 ) 作者：茹炳晟

“全上云”：完全建立在云端环境之上。注意，这里的云可以是公有云，也可以是私有云。云厂商会提供全套的解决方案来支持高可用性，容量扩展和数据备份等特性。可以说，随着云计算的普及以及泛数据库类服务（DBaaS）的快速发展，越来越多的新兴企业会选择这个方案。
“假上云”：这种方案是最奇葩的，有点像用LouisVuitton的包来装菜，但在行业内也不在少数，应该说这是一个过渡阶段的产物。这种方式就是把云方案当做虚拟机来使用。这种方式和上面的“不上云”很类似，完全没有用好云端的优势，只是把数据中心的机器移到了云端而已。云方案所能提供的容灾、扩容等功能都被阉割了。
对于上面三种方式， “不上云”和“假上云”对于数据的风险相比“全上云”会更大，运维人员在“不上云”和“假上云”的情况下更容易有机会去执行类似“rm-rf/*”和“fdisk”类型的极端操作，而“全上云” ，就比较难有机会从操作系统层面执行此类命令，数据库数据也就不会被rm-rf/给删掉。
如果删除操作不是发生在操作系统的数据文件层面（备份通常是以文件形式存在的），那么我们利用数据库自身的特性来恢复误删数据的效率会大大提高。
同样，面对数据的误操作问题（比如，错误地批量update表中数据的某个字段）， “全上云”也比“不上云”和“假上云”有明显的优势。这个我是有切身经历的，以前有个项目使用自建数据库，由于某个DBA的误操作，在生产环境的数据库上执行了一条没有加where条件的update语句，直接造成竞拍商品的出价记录字段全部丢失，而后就是艰难的全量回滚和binlog重放，最终耗时4个多小时才恢复。后来同样的误操作发生在了云端数据库，回滚恢复的时间只花了几分钟。
从之前腾讯云对外的回应中，我们可以大概看到微盟被删的数据不在腾讯云上，再结合目前数据恢复的速度来看，我们几乎可以判定很大概率微盟没有采用“全上云”的架构，或者是只有部分数据在云端，而且很可能发生了比较极端的“rm-rf/*”和“fdisk”情况。那么在这种情况下，所有的主从库文件，全量备份文件，增量备份文件以及binlog都一起丢失了。
要在这种情况下恢复全部数据，可想而知技术难度是很大的。根据我的粗略理解，至少要跨过下面这些技术的槛。
获取全量备份，如果存在异地的冷备或者灾备，那是比较理想的情况，但是由于全量备份通常非常庞大，所以需要较长的时间完成文件的传输和校验。如果没有异地的全量备份可供使用，那么就必须采取更耗时，而且不能保证一定100%全量成功的磁盘恢复手段。为什么说磁盘恢复会更加耗时，我一会儿来解释。这里还有一个问题就是全量备份可能太“旧”了，这也给后面的恢复带来了更多的时间成本。
获取增量备份，很多时候增量备份没有来得及做异地容灾备份，所以很大概/p>
获取binlog ， binlog是记录所有数据库表结构变更（例如CREATE、ALTERTABLE等）以及表数据修改（INSERT、UPDATE、DELETT等）的二进制日志文件，通常以索引文件（后缀为.index）和日志文件（后缀为.00000*）的形式存在磁盘上，通常为了保证binlog记录数据变更的准确性，一般都是采用row格式的binlog ，因此文件尺寸也不小，而且文件个数也很多。
有了上面这些作为基本的输入，才能开始数据库层面的数据导入和恢复工作，这个过程也需要花费大量的时间，而且这是基于上述文件都可以100%得到为前提的，如果上述备份文件中出现数据问题，那由此带来的额外时间成本将会变得更大。
最后来说说磁盘文件的恢复。当我们对磁盘等存储介质上的文件进行删除操作，甚至是格式化操作（低级格式化除外）时，磁盘上的数据并没有真正从磁盘上消失，而只是在文件分配表中标注了一下而已，位于数据区的数据本身并没有被立即抹掉。只要文件的数据区没有被后面写入的信息覆盖，那么这些被删除的文件就是可以恢复的，这就是磁盘文件在删除后可以恢复的理论基础。