关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问

[mhycy]

前言

源公告贴地址在此： 关于客户“前沿数控”数据完整性受损的技术复盘

昨日在 "腾讯云的事，是不是很多人以为三副本就是备份，不应该丢数据，很靠谱...." #28 帖子中做出了一些个人的推断

甚至有点怀疑是不是有人手动的“ rm -rf ”然后后续业务直接写花了集群

今天的这份公告的信息算是印证了部分的猜测

正文

公告中提到的部分细节因经验不足产生疑问，希望各位大佬可拍砖指教

---

疑问 1

在 14:05 时，运维人员从仓库Ⅰ选择了一批云盘搬迁至新仓库Ⅱ，为了加速搬迁，手动关闭了迁移过程中的数据校验；

一个按照高可用、高可靠、数据可信的原则构建的存储架构
显然读取过程中的块级校验是必不可少的，否则数据的可信性无从谈起
（因为根本不知道读取出来的数据是否为异常数据）

校验过程必然需要消耗一定的资源
类似于 ZFS, 需要大量的 CPU 资源进行读取过程中的校验
所以一般的实现方案会把存储与计算分离开来, 降低互相之间的影响

在公告中提到的一点 "为了加速搬迁"
为了实现读取过程中的校验，必然需要消耗一定的资源
独立的存储平台，自然也需要为了这个消耗的资源配备足量的运算资源
读取校验理应默认开启, 且对性能影响近乎无感 (增加了运算延迟)
而在这个公告中提到的"为了加速搬迁"...
那么....

• 什么情况下关闭校验可以加速搬迁？

---

疑问 2

在 20:27 搬迁完成之后，运维人员将客户的云盘访问切至仓库Ⅱ，同时为了释放空间，对仓库Ⅰ中的源数据发起了回收操作；

• 什么情况下才能让运维人员那么着急回收空间释放资源？

---

疑问 3

在 20:27 搬迁完成之后，运维人员将客户的云盘访问切至仓库Ⅱ 到 20:30 监控发现仓库Ⅱ部分云盘出现 IO 异常。

• 在线迁移为什么 14:05 分开始的数据迁移要到 20:30 分才发现 IO 异常？

(不了解腾讯云底层的实现架构, 学艺不精没想通, 望各位大佬回帖指教)

[firefox12]

不知道 都在讨论些什么东西，首先 腾讯不能承认 自己没有 3 备份， 也不能承认是存储程序出现问题。因为第一 如果存储程序出现问题，那么其他所有人的数据怎么办？这个后果太可怕。 如果没有 3 备份，那么就是虚假宣传，这也是不能接受的。3 备份的话，以我的经验看，其实很少有存储这么做了，因为成本太高。现在都是 9+3 这种所罗门做法。 好了 就算它是 3 备份，其实逻辑上也是不对的，因为 3 备份都是程序自己实时备份的，从来没听说过 ops 手动备份的，即使要迁数据，也是程序迁。因为如果备份靠 ops 手动备份的话，3 备份的意义就不存在了。你 ops 一天没有备份，你的 3 备份意义何在？

所以 以上 2 点不能触碰的前提下，只能让一个操作人员背一下，其实最容易出问题的就是操作人员，他手一抖可能就真的没了。因为架构设计上的问题，也许很多东西就真的找不回来了。 也许真相就是操作手抖，但是这个宣布出来，腾讯的声郁 也就完了，因为你不知道 那天你的数据就会被手抖，所以 运维手抖也是不能被提及的。 所以 目前的解释 是最好，也是最可以说得通的。至于背后的真相 只有他们内部知道了。

最后说一下 赔偿，这里的人觉得 1000 多万的赔偿请求是合理的，这种人不是傻就是坏。 你也买过硬盘，你硬盘坏过没有？你让希捷 西数赔你 100 个亿了？ 腾讯的云计算没有打保票说 100% 安全，该赔多少按照法律来。我在 aws 上运行个虚拟机，突然卡死了里面运行的程序说不定能让中国超过美国呢， 我是不是要让 aws 赔个 10 亿给我？

说起这个 我只想说腾讯的危机处理真的太弱了， 阿里家直接把用户的可执行程序都删除了，那家要求赔钱了？谁敢要求赔 1000 万啊？ 谁说可执行程序没有价值吗？万一世界上就这么一份了呢？

[mhycy]

@firefox12
请求科普 9+3 所罗门做法

[firefox12]

最后提一句 如果是 3 备份方式，有一块硬盘静默错误，但是备份应该是实时发生的，至少另 2 块盘的数据应该是正确的，并不会出现 3 块盘都有问题数据的情况。所以 这份通告 看看就可以了。

[johnjiang85]

@firefox12 云的块存储因为要求高 IOPS，一搬都是 3 副本的。EC 纠删码性能要比三副本低很多，尤其是在数据有频繁随机读写（主要是修改）的时候，性能差距太大，一般用在对成本控制比较严且对随机读写性能要求不高的场景。

[firefox12]

@johnjiang85 但是出问题的是对象存储吧？

[johnjiang85]

这里貌似迁移的过程中关闭了校验，且正好选中了静默错误的这块盘作为迁移源，没有和其他 2 个正确副本做校验，直接读取到了错误的数据(磁盘静默错误会导致数据块本身的 hash/crc 校验失效不会报错，除非存储系统自己加了额外的数据块校验信息并且进行校验)，写入到了仓库 2 的 3 个副本中就都是错误的，因为分布式存储一般写入只会写入校验信息，并不会进行实际的校验，只有读取的时候才会做数据校验

[johnjiang85]

@firefox12 出问题的是 CBS，块存储，且是系统盘。

[johnjiang85]

@johnjiang85 腾讯云的对象存储叫 COS，默认高频是 3 副本，低频是 EC 纠删码存 1.33 份，可以自己选。

[xud6]

@firefox12
这里的 3 备份是三向镜像，类似 raid，和一般的备份不是一回事。而且这次是从一个存储系统迁移到另一个存储系统，而三向镜像发生在存储系统内。

[mhycy]

@firefox12
出问题的是块存储 #24 回复没有问题，但是 #15 的回复。。
说实在点开个人信息看发帖历史的时候我是吓到了
希望这不是腾讯云的真实做法.....

[azh7138m]

@mhycy 参考七牛的处理
9+3 差不多意思就是 9bit 数据 3bit 校验位

[xud6]

@mhycy
fletcher4 的性能也不是好到免费，而且腾讯也有可能用的 SHA256

[johnjiang85]

@mhycy 我并不是做存储的，主要是做网络的，存储了解，但没做过，具体架构细节我也不清除。

[johnjiang85]

@mhycy 存储了解的意思是了解部分分布式存储的原理，但不了解出问题的 CBS 的架构。

[xud6]

@mhycy
前面忘了打，假设是 zfs 或类似系统的情况。

[firefox12]

@johnjiang85 好吧 cbs 块存储， 你家的 3 备份机制，写的时候不校验 checksum 就直接写进去的？ 一块硬盘静默错误，写的时候数据是对的，但是那读的时候读不出来，但是另外 2 块写的也是正确数据。否则 3 备份的内容不一致了，最后听谁的？对了 你会说延迟写， 你延迟多久啊？一天一个月？ 你一个月备份一次 那叫 3 备份？

好了 按照这个通告说法， 磁盘静默错误， 本身第一块盘的数据全掉，然后读的时候，关掉了校验，但是也能读出来，什么错也没有，所以也没有发现问题，然后错误的数据把 2 块本来有好的数据的盘也覆盖了。然后又删除了第一块磁盘的数据。 怎么说 另外 2 快盘上还应该能恢复出上次备份的一个版本。哪怕 10 天前，1 个月以前的。对不起空间不够，也全都删除了？真这样的话， 另外 2 快盘上的数据是可以实验室开盘恢复出来的。请恢复一个老版本把？

[johnjiang85]

@firefox12 建议你先看下公告的具体内容吧。

[mhycy]

@johnjiang85 #26
块级校验码与块数据同步存放在一个物理块上，静默错误不可能让块校验码与块数据对的上号的
难道数据 00 的校验码等于 00 ？
如果读取校验实施正确的话，理应是不造成过于严重的性能瓶颈的，除非计算资源与存储规模失配
且，三副本基于成本考虑理应可以提供类似 R0 的同步读取能力，读 IO 高写 IO 低
（由主控节点发起的并行写入，有同步开销）
直接杜绝了直接访问的可能...

如果真如回复的这样，可以以某个数据源作为源进行数据拷贝源....
这暴露的问题更为严重啊

[johnjiang85]

@mhycy 静默错误是有可能导致磁盘本身的块校验时效。存储系统的块校验和三副本校验公告是迁移过程中把校验关了，根本没校验，这个就是严重的问题。。。

[firefox12]

因为分布式存储一般写入只会写入校验信息，并不会进行实际的校验，只有读取的时候才会做数据校验。
绝对不会。这样会造成多端数据不一致。没有一个可以判断的标准。 而且写的时候都是 stream 流，根本没有任何压力。考虑到断线恢复的情况，对写入流进行 checksum 检查是最基本设计。

还有你说复制数据没有开校验，也就算了。但是老副本去了哪里呢？直接被新数据覆盖在上面吗？那家文件系统新文件是直接覆盖掉老文件的？所以，要么就是没有老副本，要么就是老副本很早以前就一直是错的了。

最后没点数了，不回了。