喜大普奔，黑群晖存储池损毁

[nigga]

显示群晖四个盘都正常，也可以点击在线修复，但是 pool 提示损毁，连只读模式都没有，直接寄了

[SgtPepper]

家用 nas 憋整 raid 案例+1

[Huelse]

自己的 nas 就不要用 raid 了，直接单盘用，重要文件多个盘之间 rsync 即可

[Scarletlens]

@Bao3C 不复杂的，这个是实时，也不是群晖的压缩格式，方便查阅，相比 hyper backup

[YongXMan]

这帖子有毒，看了这个帖子后，当天晚上自己的黑裙也掉盘了，查看日志是 ESXI 上也有存储池掉盘的日志，只不过 ESXI 日志里显示的是其他的存储池，这个盘在跑 PCDN ，给群晖的存储池都是直通的，做了硬 RAID5 ，故障时间点和日志能对上。重启了一些 DSM ，盘的状态恢复了。

ESXI 7.0 下稳定运行了 1 年了，没有发生过类似的情况，刚才先把 ESXI 升级到了 8.0 ，再观察观察，估计是有的盘快到寿命了。

虽然做了 RAID5 ，但是重要数据还是单独开了一块盘，每周 rsync 备份。

[ducks]

我主力机数据是 123 备份的，每晚复制一份到移动硬盘，再推一份到云存储（循环 推的时候自动删除 7 天前的备份），移动硬盘就普通的，机器也是 7*24 小时跑的，11 年丢过数据，怕了怕了

[ryd994]

@mikewang #9 对的
raid 的设计前提是假设磁盘坏就是彻底失效。raid 无法解决冷错误问题。zfs 有 checksum ，所以可以。

@testver #12 不仅如此，单盘越大也越不安全。基本上 3tb 以上就不建议用 raid5 而至少应该 raid6


@qingmuhy0 #16 首先，raid5 用的不是海明码，raid2 才是
raid5 本身没有 checksum ，部分实现有，比如 zfs

其次，注意你说的情况和#9 说的不同，这种情况下 raid5 确实有足够的信息去检测到不一致，但无法知道是哪个盘不一致，因此也就无法踢出这个盘重建。
zfs 可以是因为 checksum 可以指出是哪个盘有错误。这样剩余的盘有足够的信息重建。

从实现上来说，raid 的目标是高性能高可用，而不是数据保全。一般的 raid 实现不会在读取时校验数据。类似的，对于 raid1 ，如果两盘数据不一致，raid 标准并没有规定要返回哪个版本。返回任何一个都不违反协议设计。


@Ericality raid1 一样完蛋，raid1 只有 1 位冗余，最坏情况下和 raid5 是一个水平。
raid1 一样有数据不一致问题。一样有单盘重建时间的问题。raid6 有 2 位冗余，因此理论上可以纠正 1 位错误（实际上没有实现），或者恢复 2 位数据。
大单盘的重建时间是以天计的。所以重建过程中再损坏一块的可能性很大。raid1 重建完全依赖于镜像盘，因此同样无法幸免。

2 位冗余意味着只要你不是重建时连坏三块，数据就还有救。

[ryd994]

生产中不用 raid5/6 而用 raid10 的原因是服务器需要随机读写。raid5/6 随机写入需要读取整个条带所有盘上的数据，修改再回写。raid1 只需要修改镜像盘上的数据即可。

个人文件服务器不存在这个问题。又不是跑下载。smb 文件共享都是大文件。而且瓶颈通常是网络而不是磁盘性能。因此个人服务器用 raidz2 才是正解。

同样 4 盘，组 raid10 还是 raidz2 ，容量都是一样。
raidz2 可以损失任意 2 盘，而 raid10 不能，要看运气，看失去的哪 2 盘。

[qingmuhy0]

@ryd994 能劳烦指点一下，如果对相对专业（或者说全面的系统的了解）的数据安全（物理层面的保护，可以不包括阻止未经授权访问之类的安全分支，因为感觉和这个问题不是一个分支，当然如果一起的书籍或者课程俺也有业余时间去了解，尽量能从数学层面解释清楚的。）知识比较感兴趣，有什么系统的课程或者着书籍教程介绍之类的嘛，还是说最好的办法是看各个文件系统的说明文档。

个人兴趣使然，非本人专业领域。

[ryd994]

@qingmuhy0 我也不是专业人士。关于 raid 的结构，维基百科解释的很清楚。关于 raid5 的缺点，特别是为什么不能用于大容量阵列，网上相关的信息也相当多。

[dode]

@ryd994 有故障时先迁移重要数据，再重建呗

[loveour]

@Ericality 没错，作为个人用户来说，永远别指望有什么特别保险的存储方式，一定得多备份。网盘也不一定可靠。自己线下的备份也还是要有的。

[justaname]

群晖的 raid5 实际上是 mdadm+LVM+ext4/btrfs ，你的配置应该是 btrfs ，而 btrfs 这玩意儿配合硬 /软 raid 非常容易挂掉，猜测是因为 CoW 机制导致的 metadata 和 superblock 容易出现一致性问题。建议是 raid5/6 上面就老老实实上 ext4 ，如果希望使用先进的特性比如快照压缩啥的就用 zfs 或者用 btrfs 的 raid1 （ btrfs 的 raid5/6 依然不稳定，有 bug ，别用）。
说到底高级文件系统+底层 RAID 容易炸的原因基本上都是因为缓存不一致的问题，因为各种原因（断电 /内核崩溃）导致高级文件系统出现应该落盘而没落盘的元数据往往是灾难性的，这也是 mdadm 这种软阵列很难确保可靠性的原因，即使是带电池的硬卡也可能出现一些 corner case 导致意外断电后缓存上的数据在阵列再次上电之后没有顺利写入，只不过硬卡不太可能出现系统本身崩溃导致的缓存一致性失效（毕竟硬卡工作在更底层）。相对来说 ext4 这种就很难出现这种问题，最多就是损失一部分文件，不太会出现整个阵列挂掉的情况。

[justaname]

@ryd994 raid 重建本身出错的概率其实并不高，即使是大单盘。好点的硬卡或者软阵列重建基本上跑满单盘写入速度，14TB 也就一天不到的时间就重建好了。另外因为 raid 巡读的存在很少有平时正常巡读但是重建的时候突然挂掉的，就算有 rot bit 也很难导致整个阵列崩溃，最多丢部分文件文件。
真正出现一盘崩溃甚至所有盘都健康结果阵列突然崩溃的情况通常是我上面说的缓存不一致导致高级文件系统自身炸了。当然这种情况理论上依然可以通过人工分析文件系统找回大量数据，但是相对来说就复杂了很多，专业数据找回的价格也不便宜
最后还是得反复强调，btrfs over raid 是坑，别碰，要用 mdadm 或者 btrfs 就老老实实 ext4 或者 ntfs 这种特性简单的文件系统

[justaname]

@73 最后一句话应该是“要用 mdadm 或者 硬 raid 就老老实实 ext4 或者 ntfs 这种特性简单的文件系统”

[HarveyLiu]

zfs ，表示各种情况都出现了，插入新硬盘，直接就恢复了，除了内存依赖比较大，没啥事。