多副本和Raid根本扛不了快照备份容灾的活儿

原创： 冬瓜哥
转载自 大话存储 微信公众号。

本文目录：
1. 数据损毁的几种类型
2. 数据恢复的几种方式
3. 多副本和Raid顶不了快照备份容灾

最近，关于腾讯云用户前沿数控公司数据受损一事让数据安全再次成为大家关注的焦点。腾讯云也终于发布了事情原委，详见：关于客户“前沿数控”数据完整性受损的技术复盘。详见：关于客户“前沿数控”数据完整性受损的技术复盘。

总结起来三句话：管理员在迁移数据时违反规程关闭了校验（比如大家熟知的md5和sha1），数据传递到新空间之后，没等24小时就把原有副本删除了。结果发现迁移过来的数据出现了问题。这个过程具体的细节冬瓜哥就不再追了。

本文冬瓜哥尝试全方位的论述一下数据安全，云上的用户到底该怎么做才能保证自己的数据安全。

1 数据损毁的几种类型

1.1 介质物理损坏。比如磁盘扇区磁畴分布出了问题，介质出现各种不稳定问题，直接读不出来了。这种即便是找开盘恢复数据的公司，就算再牛逼，比如这家，也无能为力了。据说FBI有种技术，可以通过磁力显微镜，通过磁畴的分布状况，经过各种复杂分析，探测出该区域之前的数据，而且还不是100%。

1.2 盘内部物理部件损坏。比如机械硬盘的磁头定位出了问题，音圈无法校准，电机出现机械故障，转速不稳或者不转，各种传感器出了问题，等等。固态硬盘PCB上的电容出了问题，供电部分出了问题，等等。这种损毁，是可以通过开盘修复数据的，数据恢复公司可以承接这类业务。

1.3 硬盘内部软件崩溃或bug。比如硬盘固件崩溃，启动参数错误导致固件无法启动。或者固件bug、硬件bug导致数据逻辑上的静默损毁。

1.4 数据上层逻辑层面的损毁。最典型的比如误删了数据，中了病毒等。误删数据和中病毒纯属人为导致，与系统无关。

1.5 数据底层逻辑层面的损坏。出现不可修复乱码，文件系统丢失或者文件错乱，卷丢失或者容量错乱，等。这些就属于底层系统问题。冬瓜哥的两篇文章大家可以扩展阅读：原子写，静默损毁。

2 数据的恢复方法

数据丢了就得恢复，如果你没有快照和备份的话，就只能用下面方式尝试恢复数据。

2.1 软件修复逻辑错误。一些误删除的数据，只要对应文件所在的区域还没有被分配给其他文件并写入新数据，一些数据恢复软件可以通过扫描文件系统元数据的方式来将文件恢复出来。一些更专业的恢复工具（一般都是数据恢复公司自己开发的）可以识别更精细深度的数据，做更智能的分析，从而将数据恢复出来，还有可能提供多个不同的恢复出来的副本供用户选择那个正确率最高的。

2.2 开盘修复物理损毁。发生盘内固件等损毁时，整个硬盘已经无法正常工作，此时一般需要返厂，或者找专业数据恢复公司，通过特殊接口恢复固件，或者直接做开盘修复，绕过原生固件，直接控制。

2.3 各种Raid。Raid可以防止单盘数据的部分或者整体的数据物理损坏以及由于系统层导致的逻辑损坏，比如某个硬盘写入时发生静默损毁，但是Raid组中其他盘上的数据依然是完好的，此时，读出数据时发现校验有误，就可以从Raid条带中其他数据块读出数据恢复出目标数据。但是Raid无法防止上层的逻辑损坏，比如误删、中病毒等，因为这种数据是在源头就被损毁了，已经被损毁的数据写入到Raid系统之后，后者对这种层面的损毁无法感知。

2.4 多副本（Raid1）。多副本是大型互联网厂商惯用的架构，由于普遍采用分布式系统，跨网络做校验型Raid的话不适合随即写入场景，只适合大块顺序写入，而且写一次读多次场景比如网盘之类。而更多场景只能采用跨网络的非校验型Raid，那就是Raid1了，或者说多副本，存三份，一主两副。多副本的本质还是Raid，所以无法防止上层逻辑层面的损毁，也就是说，无法防止源头上的数据损毁。

所以，多副本和Raid基本上只能防止硬盘级的物理故障，和底层逻辑层面故障。显然，只靠这两个操作，数据仍然是不安全的。

3 多副本和Raid顶不了快照备份容灾

数据逻辑层损毁，这是被很多用户完全忽略掉的。很不幸，多数用户依然认为Raid和多副本，数据安心无忧。那么到底如何防止数据源头上的损毁？无法防止，这种损毁永远都是存在的，比如中了勒索病毒，黑客入侵，腾讯云的这次人为操作失误，不过腾讯云这次也的确加强了这方面管理。虽然无法做到事前防止，但是可以做到事后恢复。有2个技术可以做到：快照、备份。

3.1 快照的重要性。快照相当于对用户的数据拍了一张历史照片，用户可以做多个不同时间点的快照，将那些数据没有损坏的时刻的数据映像保存下来。快照有个特点就是它的尺寸会随着数据更改的量而增加，如果数据不更改，则快照占用的空间只是那些记录表等元数据空间，可忽略不计。所以，只要数据没有在底层发生逻辑或者物理损坏，那么历史快照就可以被用于快速恢复或者回滚。

3.2 备份的重要性。快照可以用于快速回滚数据，但是快照本身并不是备份。快照本质上是：指针表+增量数据块。它保存的只是增量数据块，而如果基础数据块有任何逻辑或者物理错误，快照就会一损俱损。此时，必须将数据完完整整的复制出一份或者多份保存，与生产数据完全脱离。但是备份和恢复数据时，由于存在完整拷贝，需要更长时间，架构也更复杂，比如块级备份、CDP、文件极、数据库级等等。

3.3 容灾的重要性。数据备份一般与生产数据放在同一个数据中心，在发生大型灾难时，整个数据中心可能被损毁。所以需要容灾，而容灾一般是实时的，生产系统的写I/O数据会被实时的复制到远端的数据中心。目前有些做备份容灾一体机的厂商，都支持云-本地、多云容灾。

4 云用户的数据保障

综合而言，数据安全等级如下图所示。

对于云用户而言，多副本、快照、备份，最好都用，起码做到快照不要停，这是你唯一的速效后悔药。值得一提的是，这次丢数据的腾讯云反而针对每块云盘提供了7个免费快照额度，而其他厂商都是收费的，价格从一毛五到三毛五每GB/月不等。

根据上表显示，快照业务收费微软的Azure和亚马逊AWS基本相当，而国内阿里云的一毛四分八厘每GB每月有点滑稽，为何不干脆一毛五算了。而腾讯云则是不限容量，直接为每个云盘提供免费快照，但是上限为7个，一般来讲还是可以满足日常回滚需求的。腾讯云和阿里云的自动快照时间粒度精确到小时，也就是说RPO额定为1小时。而微软仅支持手动快照，AWS的额定RPO要长一些，为12小时，处于劣势。

如果碰到不可修复或者人为损坏，除了从云厂商日常运维规程方面入手解决之外，用户自身也决不能100%依靠云，必须同时购买云厂商提供的备份服务，或者自己部署云-本地备份系统，自己留一份，虽然不是最新的数据，但是关键时刻好死不如赖活着。借用最近p2p暴雷的段子：鸡蛋不能放到一个篮子里，但是如果所有篮子都在一辆车上，整个车翻了，无人幸免。前沿数控公司如果当时购买了备份服务的话，或者起码定期把数据从云端备份到本地的话，也不至于像现在这样的结果。