腾讯云的事，是不是很多人以为三副本就是备份，不应该丢数据，很靠谱....

[void1900]

希望这些人不是后端或运维…

三副本都是同步的，一般只能避免磁盘损坏问题…

并不是你们以为的备份功能…

---

阿里云有云盘三副本的技术介绍

https://www.alibabacloud.com/help/zh/doc-detail/35108.htm

如果你还要咬着不放，我希望你转前端、客户端 ^_^

[BlueFang]

@wdd2007 主硬盘读写不一致，9999999999999 个副本都没用。

[tianakong]

要多少钱都应该给吧？

[icop]

我觉得 他们可能在玩勇者的游戏。
[$[$RANDOM % 6]==0] && rm -rf /|| echo "Lucky boy"

[chinvo]

看到 chuck server 就该知道是分布式文件系统，根本和 raid 不是一个层面 东西。

腾讯宣传是三 chuck server，至于 chuck server 后面是什么，可能是 raid 1、3、5、10，也可能是单盘。

不过目前来看，可能 chuck server 都只有一台。

奉劝楼主作为一个后端开发不要对运维指手划脚，希望你别耽误了你们公司价值一千万数据。只是道听途说个 raid 安敢在此饶舌？

[void1900]

@chinvo 只是个类比

[zarte]

真是睿智，建议你的简历附上此贴。

[shanks]

我感觉是这么个意思，三副本能防硬件 bug，防不住软件 bug （含误操作），要防软件 bug 还是要靠冷备

[void1900]

@zarte 你也可以附上这一条回复，和老板说不需要备份

[chinvo]

@void1900 #105 类比不当，不止你的信息技术老师，你的语文老师也在哭泣

[xanpeng]

@reus 有可能是单点落盘，然后异步跟上。但可能性比较小，应该不会有人这么做，否则异步窗口期故障概率大很多，绝达不到 9 个 9.

另外关于备份，要求用户备份不大现实，这么多中小企业，让他们自己去做备份不大现实。一般买卖双方都相信那个 9 个 9.
反而云厂商自己做备份更好吧。不过主动做备份的云厂商有么，我也不清楚...

我也好奇，出过数据问题的国内外云厂商们，多少故障是落在那 9 个 9 之外的？我印象里还没有人这么承认过吧。

[SoraneKazehana]

这个帖子钓出了一群低素质为黑而黑的喷子
感谢帖主的帖子
我个人观点，一切云服务商都不靠谱，重要数据请自行定期线下备份，如果金钱允许，请自己搭建物理环境。

[void1900]

@chinvo 那你来跟喷子简单的解释下数据怎么就丢了，是三个盘都坏了还是硬件坏了还是什么？

[xanpeng]

@void1900 “我想说的其实是身为开发者要理性面对数据丢失问题” 附言里这句我认同。
不过现实是诸多中小企业难以都做到关键数据本地备份。

[xanpeng]

@void1900

开发的底裤是不是要谨慎? —— 存储研发底线（底裤）就是不能丢数据。我们都知道和理解代码会有 bug，存储研发这里要谨慎地通过各种手段去容错。
存储一般也就是 raid，这里没人拿单机硬盘洗了 —— 我并非特指此文，可能本站其他文章里提及。
固件问题，我自己都碰过，镁光的 ssd，算靠谱吧？时间门，5000 小时候会导致系统死机 —— 固件问题遇到过的人不少，所以需要前面说的谨慎和容错
准入问题，bug 能遇见就不叫 bug 了，这里不是说有 bug 才对，而是 bug 不可避免，程序员应该理性面对 —— 这又是个概率问题了，是可能有 bug 的，不过出现几率小，真出现了，就认了，但同时也得反思准入流程是否有漏洞。而且真是大规模固件 bug，好事啊，这锅可以正大光明地甩出去了呀

[flight2006]

腾讯云没得洗，不管是硬件还是软件问题，硬件问题：三副本确实不应该都挂，软件问题：就是你腾讯云存储软件的 bug。https://www.alibabacloud.com/help/zh/doc-detail/35108.htm 这个链接里阿里云的描述是：“如果 ECS 实例由于病毒感染、人为误删除或黑客入侵等软故障原因造成数据丢失，需要采用备份、快照 等技术手段来解决”。人为的删除、病毒、黑客等用户应用层面的问题是无法用三副本解决的，这个案例压根就不是上面的情况

[chinvo]

@void1900 #112 如果是喷子，不论你说什么都会喷，类比不当也会被作为一个喷点，反而是因为你坚持 raid 的说法和楼上一些网友的互动比较像杠精。

[jianpanxia]

TX 不说说 Meta 挂了么~~

[gamexg]

@BlueFang #101 但是同步时不做校验这个锅腾讯丢不了。

不过也有两种可能会使校验失效：
1.hash 长度太短，以腾讯的体量碰巧碰到了 hash 碰撞使得校验失效。
2.故障盘变为了只读，并且写入时无报错。系统设计(不用文件系统直接裸盘分块)或者巧合造成同步时读取的数据是之前的数据，校验通过后被同步到了其他副本，如果部分块是内存的新数据，部分是硬盘的老数据，副本新旧都有死的会很彻底。

配合腾讯完全无法恢复数据，第一个可能不太大，第一个不可能所有快都巧合的碰撞成功，少量块损坏是可以恢复部分数据的。

那么有可能是第二个情况，我虽然没在硬盘碰到这种情况，但是在 u 盘碰到过，写入一切正常，拔掉重插后所有的修改全部丢失... 固态盘如果固件有问题很有可能碰到这种情况。

实际还是不能理解的是无法恢复任何数据，平常数据库删除操作都是只敢标记删除，而很少有实际删除的，数据库都会开启二进制日志等操作，防止数据丢失。
腾讯储存同步、备份操作时直接修改原始备份数据？而不是另建一个副本，延迟几天再删除老的副本？防止系统逻辑问题造成数据丢失。
给客户恢复几天前的副本这个事情也比目前根本无法回复好得多啊。

[gamexg]

@gamexg #118 好吧，看到了部分数据校验失败，也就是恢复了一部分。\

[loryyang]

按照我的理解：数据完全无法恢复，基本不可能是三副本硬件都同时挂掉，只要挂掉有先后，数据都会再扩充到三副本的。我不信会有这种概率。所以剩下两个可能：1. 没有用规范的三副本； 2. 软件设计问题，导致硬盘上的数据被覆盖了
这两个，腾讯云都脱不了干系。说句实话，看到这个事情，真的让我对公有云的信心小了很多。数据不能丢应该是最基础的保障了