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

[void1900]

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

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

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

---

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

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

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

我想说的其实是身为开发者要理性面对数据丢失问题，

否则你又要耽误另一个千万数据了

[yinanc]

他们是认为这么多个 9 就是等于 1，不等于 1 就是虚假宣传

[baojiweicn2]

共消费 3569 元=价值两千万的数据=两年没备份。
腾讯云是坑，阿里云也坑。不如换 AWS。

[a22124497]

重要数据 ，只有一个节点，是永远不对的，自己不备份嘛？
把命交到别人手上，这不是作 死嘛

[likuku]

副本 /冗余，和 备份 完全是两码事，不趁早认清这点，那迟早会损失惨重。

[gamexg]

@baojiweicn2 #2 +1

我很奇怪一个备份也没有？还是全部备份都在腾讯云结果一次故障全挂了？
不过大公司也出过奇葩问题，gitlab x 份备份全部无效...

[likuku]

@gamexg gitlab 的灾难例子，再次说明: “被定期验证可恢复正确数据的有效备份” 才是 “备份”

[momocraft]

企鹅这次给的理由不就是磁盘损坏吗

[night98]

@momocraft #7 如果做快照的话都能保存一部分完整数据，最多丢失快照后到出问题时的这段数据，按照他的消费金额，估计没有进行快照。

[type]

腾讯云这次给的理由就是磁盘问题啊，LZ 这是咋了？

[void1900]

@momocraft
@type

“因受所在物理硬盘固件版本 bug 导致的静默错误（写入数据和读取出来的不一致）影响，文件系统元数据损坏。”

可以算是软件问题，一般的磁盘损坏都是指扇道等硬件问题

[type]

“物理硬盘固件”，这个东东你先查查再回答好不？

[ToT]

"保证一个 Chunk 的所有副本分布在不同机架下的不同 Chunk Server 上，有效防止由于一个 Chunk Server 或一个机架的故障导致的数据不可用". 为何三个 chunk 会同时失效？

[void1900]

@type
硬盘固件 就是硬盘的系统，类似你的手机固件就是手机系统，软件还是硬件？

[catror]

都是精神股东啊，这样的服务精神做企业级市场肯定是要凉的。

[void1900]

@ToT 了解下 raid 吧

[type]

@void1900
这个固件是在硬盘主板上的，每块硬盘都是独立，互不干扰的。

你这份副本下的硬盘的固件有问题，难道另两份副本下的硬盘的固件也有问题？

[void1900]

@type 去了解下 raid 吧

[type]

Raid 跟副本是两回事好不？ 你好好了解下 副本和 Raid 吧

[void1900]

@type 希望你别耽误了你们公司价值一千万的数据

[type]

腾讯云：云硬盘服务等级协议(SLA)
链接见另一个贴子的 72 楼： https://www.v2ex.com/t/477152?p=1#r_5992507

第 2.1.4 章节： 数据知情权
最后一段：
为保证用户数据安全性，腾讯云采用同时存储三份数据副本的存储方式，并定期进行数据冷备操作。

[wdd2007]

三副本能避免硬件故障导致的数据丢失么？

[lfzyx]

腾讯云 p7 专家来洗地了？

[type]

想想那得多可怕，三份副本的硬件都挂了

[type]

腾讯云：云硬盘服务等级协议(SLA)，第 2.1.4 章节： 数据知情权，最后一句：并定期进行数据冷备操作。

哦，对了，连“数据冷备”的那个硬件也挂了

[hanru]

希望腾讯云能公布问题硬盘的型号和固件版本。

[void1900]

@lfzyx 我不是腾讯的让你失望了

[likuku]

有机会玩下 hadoop 的 hdfs 就会对 “多副本” 有比较直观的认识，

“避免硬件故障导致数据丢失”，
这得看故障的硬件数量占受影响的存储池所组成的硬件总量里的份额高低了，
若超出带冗余功能的存储系统的容错上限，那么数据丢失是不可避免的。

另外，ZFS 也有 副本的概念，即便一个 ZFS 存储池是仅仅建立在 1 块物理硬盘上，
也可以给这个池设定使用多个数据副本，当然那块唯一的物理盘挂了，存储池也一样完蛋了，
虽然你让一个鸡蛋必须克隆多个分别放在多个筐里，但载那些筐子的船翻了，结局是一样完蛋的。

[mhycy]

高可用磁盘底层架构为非同批次、非同固件的等容量、等架构磁盘组建硬件 /软件 RAID
此磁盘柜应配合巡检定期校验数据是否可用，并尽早踢出异常磁盘
三备份应是基于此磁盘架构的冗余备份架构，无论是实时互备还是定时冷备

一般云 VPS 服务的自动迁移依赖独立的磁盘柜与计算集群实现
那么在腾讯的这个案例上，可能存在三台阵列柜、一套磁盘阵列网关与若干计算节点组成的计算机群
丢失数据的范围为一个集群（假定整个集群都出现静默错误，且真的存在三备份架构）

那么问题来了
1、为什么现在只有一家公司发声？
2、如果真的是三备份架构，为什么会三套存储设备同时故障？
3、为何阵列损坏后没有任何警告、通知直接就是静默错误？

假设现在的信息都为真实信息，没有人为修饰掩盖
有以下推断：
1、不存在三套设备互备的磁盘架构
2、这个软件 BUG 不在硬盘而在软件分布式上面
3、假设 2 推断为假，软件 BUG 位于磁盘，则阵列架设没有严格遵守高可用原则进行设计
4、假设 2 推断为真，那么更有可能的情况是 BUG 位于阵列卡，数据位于单一母机，丢失范围为一台母机
5、假设 2 推断为真，数据存在集群上面，且 BUG 位于自研的分布式存储平台上，那么...不多说了

说实在，怎么想都想不出来为什么一个成熟的云平台能搞到数据全丢
甚至有点怀疑是不是有人手动的“ rm -rf ”然后后续业务直接写花了集群

[rrfeng]

@mhycy
一直懒的打那么多字，我看法相同。使用方的文章只会扯皮，没有提供实质信息。腾讯云的声明提供的技术细节一点都不充分。

希望腾讯云能再公开更多的细节。

[void1900]

@mhycy

静默错误（写入数据和读取出来的不一致）

我理解的是，因为读写不一致导致镜像磁盘以为镜像内的数据是对的，然而其实并不一致，最后所有磁盘数据都乱了。

[jadec0der]

lz 的意思是腾讯云的三副本用了同样的硬盘，同样的固件，而且这个 bug 是只要写特定数据就会导致损坏？你咋知道这么多

[void1900]

@jadec0der raid 丢数据并不是只有全部磁盘损坏了才会丢的

[mhycy]

@void1900
构建磁盘阵列的时候，静默错误是个必然需要考虑的异常情况
（事实上依据观察 V 站的各位似乎考虑到这个问题的并不多）

针对的是单个磁盘回报不正确数据的情况，该如何尽早的发现尽早的排除
在支持静默错误发现的阵列系统例如：ZFS
静默翻转 /静默写入读出不一致是不可能导致整个磁盘阵列丢失数据的
因为软件层面上会实时的校验读取到的数据与元数据是否一致（显然元数据也是冗余的）
对于异常磁盘一次读出就尽早修正并且抛出警告了
如果问题出自硬盘底层固件，那么问题范围也仅仅可能局限在一个磁盘阵列节点也不可能全存储系统的崩溃

[void1900]

@mhycy https://www.zhihu.com/question/55714905/answer/311729503

[murmur]

3 副本如果不是 raid 还能同时炸

[mhycy]

@void1900
重新阅读回复，你会知道为什么同时损坏理应概率极低

[void1900]

@mhycy

zfs 是 bsd 那边的 一般的云基本都是硬件 raid

我想说的是像一般 raid1 raid5 raid10 等 在这种情况下我觉得都是有可能丢数据的

各种云的三副本其实也只是 raid1 3 镜像而已

[1762628386]

CVM 提供达 99.95 %的服务可用性和 99.9999999% 的数据可靠性。CVM 搭载的云硬盘提供三副本存储策略，保证了数据在任一副本出现故障时快速进行迁移和恢复。CVM 搭载稳定的网络架构，采用成熟的网络虚拟化技术和网卡绑定技术，在 T3 级以上数据中心中运行，保证网络高可用性。

[kappa]

@lfzyx 腾讯 P 是产品，等级 7 不存在，为了黑而黑你活的累不累

[1762628386]

腾讯云 CVM 产品详细信息
腾讯云 CVM 提供了在云中的可扩展的虚拟计算资源，允许您选择多种操作系统来启动 CVM 实例，并加载到您自定义的应用环境。后续随着业务量的变化，您还可以随时调整您的 CVM 规格。

您可以使用控制台、命令行或 SDK 等多种管理工具来启动、监控或终止您的实例。

腾讯云 CVM 提供按量计费和包年包月两种计费模式，您可以灵活选择付费方式，按量计费只需为您实际消耗的资源付费，按小时结算；包年包月适合业务量稳定的场景，费用更低廉。

功能
腾讯云 CVM 提供多种强大功能，用于构建可扩展、能够故障恢复的企业级应用程序。

实例类型
实例类型决定了用于实例的主机硬件配置。每一个实例类型提供不同的计算和存储能力，用户可以基于需要提供的服务规模而选择实例计算能力、存储空间和网络访问方式。有关每种实例类型的更多信息，请参阅 CVM 实例配置。实例启动后，用户即可像使用传统计算机一样使用它，用户对启动的实例有完全的控制权。

最新一代云服务器
腾讯云在国内率先使用英特尔下一代至强®处理器 Skylake，推出国内最新一代云服务器。与过往采用至强系列处理器的云服务器相比，使用 Skylake 处理器的新一代云服务器具有更高计算性能、更大内存带宽、更强存储 IO 性能、更低网络时延等优势，能满足游戏行业、视频行业、金融行业等领域的更高计算需求。
最新一代云服务器火热申请中 >
第二代云服务器
我们最新推出硬件升级的第二代云服务器，采用英特尔®至强® V4 处理器，整数和浮点运算性能相比以往提升 40%；搭配 DDR4 内存，性能提升 30%；全面搭配网络增强，包转发率（ PPS ）最高可达 30W。
丰富的机型配置
云服务器 CVM 提供多种适用于不同使用场景的实例类型供您选择，这些实例类型由 CPU、内存、存储和网络容量组成不同的组合，您可灵活地为您的应用程序选择适当的资源组合。每种实例类型都包括多种实例大小，从而使您能够将您的资源扩展到符合目标工作负载的要求。
了解实例类型详情 >
灵活的配置调整
云服务器 CVM 提供丰富的计算、网络和磁盘的配置及容量扩展，支持不关机随时调整网络，支持关机状态下基于云盘的硬件调整和磁盘扩容。
对于突发性业务高峰，您可以使用按量计费的计费模式，随时开通 /销毁计算实例，按实例的实际使用量付费。计费精确到秒，最大程度降低成本。
您可在页面上通过鼠标点击操作，一键升级到更高性能和容量的实例规格。升级过程中不影响您业务正常访问和使用，实现快速、平滑扩容，满足业务快速发展需要。
多地域与多可用区
腾讯云服务器托管机房分布在全球多个地域，您可以选择靠近您目标客户的地域来部署 CVM，从而大幅降低访问时延，提升业务体验。
每个地域内有多个互相隔离的可用区，如果您的业务需要较高的容灾能力，可以将 CVM 实例部署在同一地域内的不同可用区，保护应用程序不受单一可用区故障的影响。
了解地域及可用区详情 >
镜像
用户可以使用同一个镜像启动不同类型的实例，镜像是一种云服务器软件配置（操作系统、预安装程序等）的模板。腾讯云要求用户通过镜像启动实例。镜像可以启动多个实例，供用户反复多次使用。镜像是腾讯云 CVM 实例的操作环境模板，通常包含操作系统和预先部署的软件。镜像功能可以帮助您快速部署环境。
您可以将已经部署好环境的 CVM 实例制作为镜像，在新创建 CVM 实例时加载此镜像，从而极大提升部署效率。
您可以将自定义的镜像通过控制台、API 或 CLI 与其他用户共享。
腾讯云官方提供公共镜像供您选择，腾讯云市场中也提供第三方镜像（多种操作系统及应用程序）。
支持跨地域镜像复制功能，您可以在不同地域下快速部署相同的云服务器实例，提高应用程序的健壮性。
除了 CVM 实例和存储的标准使用费外，镜像服务不需要其他任何费用。
了解镜像详情 >
云硬盘
高可靠性
云硬盘是数据块级别的持久存储设备，具有高可用性、高可靠性的特点，数据可靠性达 99.999999%，领先业内水平。云硬盘采用三副本存储机制，在任何一个副本故障时快速进行数据迁移恢复，时刻保证用户数据 3 份副本可用，为您提供安全放心的数据存储服务。
高性能
支持三种类型的云硬盘：普通云硬盘，高性能云硬盘和 SSD 云硬盘，满足不同场景下的需求。其中 SSD 云硬盘采用 NVMe 标准高性能 SSD，单盘提供 24000 随机 IOPS，260MB/s 吞吐，同时实现了超强性能与超高可靠性。
了解三种云硬盘的详细对比 >
快照备份
通过对云硬盘创建快照来保留数据的备份副本，您可以随时从快照创建新的云硬盘，并将其连接到另一个实例，提高业务的灵活性。
了解快照详情 >
扩展性
您可以自由配置云硬盘的存储容量，按需扩容，且无须中断业务。
单磁盘容量为 10-16000GB，单 CVM 累计可挂载 160TB 的存储，单 CBS 集群存储容量无上限，高效应对 TB/PB 级数据的大数据处理场景。

[void1900]

@mhycy 不扯了难多的技术细节太说不准了

我希望的是大家正视数据丢失问题，无论哪家云的云盘技术方案都没和你说过保证数据 100%可靠。

即使你自己再做跨地域同步+跨地域备份也只是提高了可靠性。 同样给不了你 100%可靠。这应该是程序员还有的严谨！

[void1900]

@1762628386 希望你别耽误了你们公司价值千万的数据

[mhycy]

@void1900
硬件 RAID 最基础最基础的低成本高可靠选项是 RAID6，不是 RAID5

RAID1 的存储成本过高
RAID5 存在两个磁盘损坏无法修复的可能性
RAID10 存在特定两个磁盘损坏后无法修复的问题（除非其中的 1 不止一个磁盘）
RAID50 存在特定两个磁盘损坏后无法修复的问题
RAID60 存在特定三块磁盘损坏后无法修复的问题

假设现在情况真的是磁盘回报异常，那么算是静默错误，当成磁盘写入全 0 好了
且故障真的是固件 BUG 引发，那么非同固件且非同批次磁盘构建阵列这个准则是否已经违反？

所以说在正确构建阵列的情况下这是概率极低的事件
除非。。。阵列卡出 BUG 了

[1762628386]

@void1900 这次有功 腾讯年终奖给你加不少吧

[void1900]

@mhycy 那我问你个数字 ，可靠性多少%？

[void1900]

@1762628386 我不在腾讯 喷子🙂

[mhycy]

@void1900
给个场景？

[void1900]

@mhycy 就按你最高的可靠标准来构建这个阵列

[void1900]

@mhycy 在简单点 就是腾讯云给出的这个故障原因 单个磁盘 固件 bug 读写不一致 的静默错误

你能保证数据 100%在？

[mhycy]

@void1900
按照准则这个故障原因是日常不是异常

[zhang61go]

值不值一千万，web archive 看看就知道。
明明有定时快照，却把存系统盘的所有数据保持两年不做快照。
CVM 本质上就是一个 VPS，不用云数据库之类的服务算节省成本勉强认可，但是你不懂基础设施执行定时备份，赖平台这面出现的意外，恕我直言，腾讯云赔 13 万都贵了。

[misaka19000]

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

感觉到了楼主满满的后端优越感啊，我想请问你有什么值得优越的？

[void1900]

@mhycy
算不算异常太多技术细节不透明了，主要很多人认知的三副本就是三个备份，但在磁盘阵列里有很多的机制去判断和同步，没人能保证 100%不出问题。

就问你能向你的客户保证不丢数据吗？你敢建议他们不另做备份吗？

[void1900]

@misaka19000 没有优越 只是希望那些不理性的喷子别耽误了他们公司价值千万的数据

[mhycy]

@void1900
搞不懂你是在杠还是在讨论问题
本来我觉得你在贴头说的话还挺有理的
然后在回复这个帖子前重新看了回复对了下 id
现在我都不知道该怎么和你聊下去了

理性讨论问题是基本的礼貌与对别人的尊重且对双方的技术提升都能有所帮助，希望你懂这个道理。

[jadec0der]

@void1900 那我把最后一个损坏改成丢数据吧，还是那个问题，你咋知道这么多腾讯云没公布的信息？

[void1900]

@mhycy 没有抬杠 ...

我只是想说无论怎样，各家云的技术方案都不可能 100%可靠

至于技术，因为里面很多细节没公开，靠猜没太多讨论价值

[void1900]

@jadec0der 我哪里知道细节了……？

都是官方的公告里的

[n2ex2]

看不懂这么多人在争什么，不管腾讯声称几个 9，几个备份，它已经承认是自己的问题了，那就按照赔偿条款来做。

[ryd994]

关于为什么一块硬盘固件错误会影响三块，可能是这样的：
假设某硬盘固件有误，写入数据的一半全是 0
这时候阵列还是在线的，因为没人知道这块硬盘是错的
我们继续使用，刚好文件系统要用到这些数据，于是读取这一段
阵列卡依然不知道有问题，于是就挑了这块坏的数据
文件系统遇到一两个错误，未必就会立刻崩溃，于是数据修改后又写回去了，注意此时所有副本都已经丢失，如果用户数据也在这一段，那数据已经丢失
最后终于，某个系统文件出错，系统崩溃，这时候文件系统已经不成样子了，就算成样子，数据也已经没了

raid 不保数据不一致。raid 的前提假设就是如果硬盘挂了，就会瞬间彻底离线。这也是为什么某些硬盘有读取超时时直接报错，为的就是提前通知 raid 控制器，防止阻塞整个阵列。

raid 只保 uptime，不保数据可靠性，这必须牢记。


@mhycy
@jadec0der
@type

[mhycy]

@void1900
然而架构合理的情况下公告太不靠谱了...
所以...腾讯云依旧存在问题...

作为经历过各类云服务长毛事件的一代人（例如当年的 QQ 中转站）
我就没相信过任何云服务会可靠，数据在手才是自己的
提到的各种可靠性数字是一个字都不信的（没有单位，没有标准，作为广告都能算是虚假宣传）
云服务本身是否可靠，能否作为主业务节点，需要实际情况实际分析...
例如现在的各种负面...

另: 我关于是否选择云服务的看法可以看看这帖子的回复（#47 ）
https://www.v2ex.com/t/476956

[aliipay]

@catror 你确定都没买吗？[手动滑稽] 不过说的确实比壁虎好中肯一些

[void1900]

@mhycy
确实就是这样

如果腾讯云靠谱最好是公布内部细节

那些跟风喷的要理性看待所有云的所谓可靠性

喷并没有意义

[mhycy]

@ryd994
能做块级存储集群的软件方案，不考虑读取写入校验是基本不可能存在的。
注意，要做到块级存储集群只可能是软件方案而不是硬件的 RAID 整列
能在各个计算节点互相飘的方案也只有走网络的 iSCSI 方案
（如果有别的方案希望给我科普一下，我实施过的只有 iSCSI ）

RAID 保证 uptime 不保证数据这点没错，但考虑到上层软件冗余与纠错... 这锅还是甩不掉啊...
而且 RAID6 的情况下本来就自带有错误发现的能力（读取过程中两个结果互相对比）
于是... 锅还是甩不掉...

[void1900]

@ryd994 是有可能的 其实我想说的就是 三副本的技术方案并不是一般人认为的可靠的备份

它是有可能因为一块硬盘就出问题的，只是概率小

[void1900]

@mhycy 腾讯云确实只表示了固件 bug 是最底层原因 但是文件系统这块没有说明 ，锅应该是有的，固件 bug 可能只是遮羞布

[OneNian]

"对于每一个 Chunk，阿里云会复制出三个副本，并将这些副本按照一定的策略存放在集群中的不同节点上，保证您数据的可靠。"

我看到的重点是“不同节点”，这是单纯的 raid 吗？

[ryd994]

@mhycy 我只是提供了一种假说而已
解释你们之前说的三硬盘为什么能一起挂
腾讯云具体什么架构，只有他们自己知道

除了 iSCSI 还有 rdma 呢

关于 raid6，标准里似乎并不包含你说的读取中两个结果对比的功能。不然也不会有这篇论文了：RAID Architecture with Correction of Corrupted Data in Faulty Disk Blocks。raid 本身并不提供校验，因此纠正也无从谈起。如果你说的是非标准 raid，那 zfs 就是一例

[void1900]

@OneNian 软“ raid ”？

不同节点也不能保证校验或者同步机制一定没有 bug

[ryd994]

@OneNian 可以是，rdma 只要网络撑得住，除了多一个内网延迟，其他都和本地盘一样。
然后，现在都是 30G 50G 的网络
本来计算节点和储存节点分离就是这么玩的

[mhycy]

@ryd994
感谢科普！

[RIcter]

@lfzyx 腾讯是 T 吧

[xanpeng]

这个问题没什么好洗的，做存储的都知道，底裤是不能丢数据。
你可以数据离线一段时间不能访问，就是不能丢数据。
是说 9 个 9 的可靠性，理论上的确不是 100%，但...没必要拿这个理论极值来洗了吧。

至于其他的，那是其他问题（比如赔偿方式额度等，比如备份等），可以把讨论重点放到其他问题上，但逃脱不了这个事实：你丢数据了。

也没必要拿备份来洗。
客户本地备份了，是客户自己做的好。掩盖不了你云存储丢数据的事实。
客户没有备份，他们自己可以怪自己没备份，但你 tx 就不能怪他没备份了。毕竟他相信你云存储宣称的 9 个 9，毕竟他本地可能就没有数据中心。

拿单机硬盘来类比的就更可笑了，这么来洗的，要么是真不理解，要么就是故意了。本来云存储多副本就是要解决单机硬盘可靠性问题的。

[xanpeng]

另外拿硬盘静默数据错误来挡枪，也是不专业的。
tx 这样的大厂，静默数据错误怎么着也得解决了吧。阿里肯定是宣称解决的，tx 我印象里也这么宣称过，但不确定。

[xanpeng]

而且硬盘静默数据错误这个说法，十有八九是背锅的，真正错误原因没说出来。因为：
1、如果同批次硬盘固件有问题，丢数据的客户很可能不只这一家了。
2、如果真是硬盘固件问题，怎么准入的？ tx 肯定用大厂硬盘的吧（不然就是自己作死，相关人得负责任了），大厂硬盘大规模出现类似问题的，没怎么听过吧。这次真是问题的话，这个锅妥妥地甩给硬盘厂商了吧。

真正原因应该是副本间一致性没做好。

[kingme]

多副本怎么就理解成了 RAID 了。。。。

[qiukong]

人家做网站的不懂你们这些技术，既然官网写有备份 99.99999999999%可靠性，人家就相信你们有备份了。出了问题该负责还是要负责的，除非霸王条款协议在先。

[void1900]

@xanpeng 开发的底裤是不是要谨慎?

存储一般也就是 raid，这里没人拿单机硬盘洗了。

固件问题，我自己都碰过，镁光的 ssd，算靠谱吧？时间门，5000 小时候会导致系统死机

准入问题，bug 能遇见就不叫 bug 了，这里不是说有 bug 才对，而是 bug 不可避免，程序员应该理性面对。

[void1900]

@kingme 希望你不要理解成备份

[hjlmjx]

不懂呢，就不要跟着瞎分析。现在又感觉是硬盘固件（硬盘 io 系统）坏了导致的？第一个，如果有备份机制，其它备份盘的固件同时都坏的可能性几乎为 0。第二个，如果是硬盘固件坏了，那么之前就不会出现一直好好的，而某一天突然坏了的情况。除非累计一直写入跟读取都是错误。
太搞笑了。此事腾讯估计解释不清楚了，稍微懂点儿基础的人都大概猜到，他们云备份机制有问题。

[hjlmjx]

固态跟机械完全两码事，别自恋。按照此说法，腾讯应该找硬盘厂商赔偿嘛

[void1900]

@hjlmjx 楼上讨论很多了，懒得和你扯了

[void1900]

@hjlmjx 你这说法就更好笑了...

[hjlmjx]

@kappa 就因为腾讯没 p7，所以他在损群主。

[autoxbc]

不要扯技术细节，原则上核爆都能抗才对，固件 bug 比核爆还狠吗

[nimrc]

这水平就敢出来装逼？敢问你是前端还是客户端..
不过我觉得都不适合你，回老家养猪吧

[ldw4033]

我觉得有些前端都比你强，只讨论技术，不要在这逼逼职位划分，感觉你对这个职位划分很权威似地

[ldw4033]

@void1900 谁都会承认谁的数据都不会 100% 可靠性。那腾讯搞出 9 个 9 意欲何为啊，不就是告诉他比其他云服务商更加牛逼，能达到这么些个 9 啊。让我们买他的服务不是！！既然做不到那就 99.99% 我觉得足够了，不要宣传的那么恶心。

[Narcissu5]

喝奶之前要不要测试下三聚氰胺？打疫苗之前要不要测下有效性？消费者对你信任才把身家性命都托付给你，你们倒好把锅甩给消费者，你觉得往后大家就长记性了？不，大家会选择进口奶粉，会选择进口疫苗，会选择别家的云服务。

[sevenzhou1218]

LZ 你想表达啥就直说吧。绕那么多弯做啥？

[reus]

我怀疑他们是单点落盘，然后就是落盘的 SSD 的固件有静默错误，也就是落盘的数据就是错的，所以你有多少冗余多少备份都没用，落盘的数据就错了而且没报错。
如果是多点落盘，如果有一个盘出现静默错误，那读的时候，这个盘有校验错误，但其他盘没有，那就可以以其他盘的数据为准来做校正。
单点落盘然后再复制副本，当然没法解决单点的静默错误问题。

另外，所有认为云服务就不需要备份，云服务就不可能丢数据的人，没有资格做后端开发。

[tempdban]

@void1900 固件 bug 指什么硬件的固件 raid 卡 or 硬盘？
关键是…你指出的所有可能性其实都是单点故障，高可用的基础不就是单点故障可恢复嘛。
然而他这个事故是一丢全丢了。
按经验，一般这种全丢数据，不是软件故障，就是人为操作。

[ironx]

借这个机会求科普，这个三副本有啥用处，解决了什么问题？

[liuzhedash]

@void1900 #78
软件研发通常的目标是实现业务需求，谨慎之类的底裤也是针对程序逻辑的，谨慎对待硬件 bug 毫无意义。难道调用一下 write() read()还要谨慎考虑一下硬盘会不会在这次写入的时候挂了？

[ioioioioioioi]

给个参考：因为我几乎每天工作，所以我在我的电脑上设置了一个定时脚本，每天自动把服务器上的数据下载到我的电脑上。安全，简单。

[void1900]

@liuzhedash 难道不需要？哈哈哈

[jccg90]

看那个故障描述，估计备份是备了，冷备也有，也备份了好几份。。。

但是，可能当初写入数据的时候就出错了，然后当成了正常数据去备份去冷备。。。结果往出取的时候，校验失败才发现存的数据的不对

[misaka19000]

@void1900 #95 看到你这个回复就知道你什么水平了

[x7395759]

出了 bug 就好好解决 bug，学学 gitlab 和 aws，技术博客和全程修复直播，到现在为止估计这个 bug 还没有解决。

声明和套路云一模一样的，从此改名套路云 2。

数据的重要性不言而喻，但是也不要矫枉过正，你对数据备份的理解有问题，建议去看看 google 的论文。

[unicorn1390]

楼主的意思是我们不能过分依赖于云服务要在其他方面做备份吗？但是你这个说话说一半让人自己想的操作很容易让人以为是某编外人员。。