NAS 存储的安全+便捷+成本的最优平衡思路探讨，及单盘位最高容量疑问

先给 V 站大佬们汇报一下所谓"最优平衡"的思路，纯粹从个人的"穷+我全都要"的立场出发。若不合理还望指正并轻拍。要点如下：

安全+便捷角度

1 ）不用 RAID5 ，大容量单盘失效后重建失败概率过高（Ref1），不展开。

进一步地，不用任何奇偶校验的 RAID （包含群晖的 SHR ），避免重建伤盘。（阵列的核心诉求是保证实时性，而不是数据安全性）

2 ）通用数据采用不同存储池下的 1+1 备份实现。工具拟用文件级备份的 Snapraid ，可以实时同步，也可以定期冷备。

（题外话：核心数据额外有 3 地 4 中心机制，即工作机、公司服务器、云、NAS （待增），保证安全性和实时性）。

引入成本角度后

3 ）无需一次性配满磁盘，而是根据数据增量分步按需配置，第一次采购 2 块磁盘（假设为 14T ）组 1+1 ，之后每隔若干年采购 1 块容量翻倍的磁盘，并基于 Mergerfs 实现存储池的平滑扩容。步骤略见下图：

4 ）更进一步地，计算、存储分离（解耦）：算力的提升&降本的速度明显快于存储，因此不想采用一体式 NAS 的方式，更倾向于小主机（ Homelab/算力）+磁盘柜的方式。

小结一下以上思路，即

1 ） Mergerfs+Snapraid+磁盘逐步翻倍扩容策略，优点：

低成本（对标 raid5 ）
数据 1+1 备份（对标 raid5 ）
文件级备份，无重建失败 or 伤盘概率（对标 raid/shr 等校验恢复机制）
可用 ext4 ，读写性能和稳定性更优（对标 shr 等 btrfs 文件系统）

2 ）算存分离，优点：低成本、高性能等。

疑问

要实现图示的存储逐步翻倍扩容，就要确保磁盘柜（或者一体化 NAS 机）的单盘位可识别容量要>50~60T 。但好像目前市面上的产品宣传口径都是跟着主流 HDD 的最大容量走的（一般是 16T-20T 左右）。

我的疑问是，撇开厂家的宣传策略不谈，从技术上看，

磁盘柜/一体式 NAS 的最大单盘容量的受限条件实际是什么？是主板？是 XX 接口的类型？是总线的带宽？还是系统里的默认设置？

或，有没有简易+便宜地提升可识别单盘容量的方法？

谢谢大家~~

sicifus

347 天前

@libook #37 非常感谢~
的确是打算把 SnapRAID 作为温/冷数据定期备份来使用的，而且不打算跨存储池去操作数据。具体的思路是：
1 ）重要数据（热数据）基于云+端的同步（ 3 中心），确保数据多份拷贝和一致性。数据操作时不传 NAS/服务器。
2 ）重要数据定期（每周 1~2 次）同步一次到 NAS+公司服务器上，仅用于规避中招勒索软件的时间成本（云端虽有版本管理功能，但一个个恢复起来时间太长）。其中在 NAS 侧，仅存到存储池 1 内。
3 ）其他数据（主要是照片、影视、书籍等），日常的增添删改都只在存储池 1 内操作。
4 ）存储池 1 内的温/冷数据定期（每周 1 次）通过 Snapraid 同步到存储池 2 中。除了 snapraid 同步、校验，及 s.m.a.r.t.扫描维护之外，其余时间原则上存储池 2 的硬盘休眠（省点电费，#doge ）。

关于 HBA 卡和 12 盘位硬盘笼的信息我再去学习下，感谢~
关于 unRaid ，主要是看了 youtube 上一些 up 主的吐槽（譬如这个 https://www.youtube.com/@ZhangDaqi/search?query=unraid ），感觉好像槽点有点多、学习成本不低，所以也没特别关注了。

libook

347 天前

@sicifus #41
建议第 2 项加快照，可以保留最近几次备份的快照，避免数据损坏后自动进行了备份。

unRAID 对我来说是，确定自己的需求场景可以使用 MergerFS+SnapRAID 满足的情况下，的一个更可靠的替代方案。目前用了两个多月，明显感觉 unRAID 比之前我自己在 Debian 上搭建的 MergerFS+SnapRAID 更稳定耐艹，我上次换了硬盘笼之后已经稳定运行 20 天了。

sicifus

347 天前

@sicifus #40
我又思考了一下，mergerfs 在下文件 io 表现不佳，会不会是因为小文件实际跨磁盘操作了？
我把主贴的图示改了一下，如果日常增添删改永远在存储池 1 里操作、且存储池 1 永远只有 1 块磁盘，会不会好一点？存储池 2 仅作为冷备使用。

sicifus

347 天前

@ButcherHu #36 我又思考了一下，mergerfs 在下文件 io 表现不佳，会不会是因为小文件实际跨磁盘操作了？
我把主贴的图示改了一下，如果日常增添删改永远在存储池 1 里操作、且存储池 1 永远只有 1 块磁盘，会不会好一点？存储池 2 仅作为冷备使用。

sicifus

347 天前

@libook #42 好的谢谢，我再学习一下

sicifus

347 天前

@ltkun #14
按照这篇文章（ https://wzyboy.im/post/1186.html ）的说法，zfs 同样有「 data lock-in 」的缺点，对磁盘容量扩展的友好性明显没有 mergerfs 高。

sicifus

347 天前

@aru #26 你好，我把主贴的图示改了一下，如果日常增添删改永远在存储池 1 里操作、且存储池 1 永远只有 1 块磁盘，io 性能会不会好一点？存储池 2 仅作为冷备使用。

sicifus

347 天前

@ButcherHu #36 另外，分期应不是"最优平衡"，「延迟采购 x 分期」明显优于「仅分期」

msg7086

347 天前

关于 URE 的问题，有几点要提的。
一是 URE 是上限值而不是典型值。比如一块硬盘参数标称 URE 是 1E-14 ，并不是说每读取 1E14 比特就会遇到一个坏点。这里的这个 URE 是最大值。比如我随便拿了一份 WD Red Pro 的参数表，上面写的是：
Non-recoverable errors per bits read
<1 in 10^15
注意这个小于号，实际生产环境中的 URE 其实是远远小于 1E-15 的，标称 1E-15 只是上限值，不是典型值。

二是 URE 通常是发生在磁盘长期不读取的时候。我们知道磁盘本身会随着岁月的流逝而逐渐丢失数据。在读写磁盘数据的时候，如果 ECC 检测到磁盘上有数据错误，就会重写扇区刷新数据。如果你有一些文件放置在那三五年不去读写，有可能三五年过去就有可能有数据会损坏。但如果你每隔两个月刮一次盘，每隔三年把盘清零重写一次，URE 发生的概率会大大降低。

光这两点就已经显著偏离你贴的关于 URE 的数据点了。

然后是单盘容量限制。单盘容量其实没有限制，最多就是操作系统估计限制门槛，要你加钱换更贵的产品。现在一般购买的 NAS 你插一块单盘 100TB 的盘进去也应该能正常使用才对。

最后是说说 NAS 的思路。你如果想做磁盘柜，磁盘柜输出一般是 RAID/HBA 卡，一般为了省事肯定直接插满然后做一个大 ZFS RAIDZ2/3 完事（或者硬 RAID ），不考虑扩容，不考虑花里胡哨，你就把他当成一块巨大的硬盘，开机就用，用到报废，拆了卖废品为止。
如果你想折腾，又想省钱，自己买个多盘位的塔式机箱自己建。
如果你家里地方够大，没有噪音问题，那直接一个 12 盘或者 24 盘的超微解决问题，一站式方案，E5v4 ，插满 DDR4 REG ECC ，自带背板，一块 HBA 连上，剩下的还能搞搞 40G 网卡什么的，装个 Proxmox ，想怎么玩就怎么玩。

我以前给公司装 NAS ，2U 的机器 12 盘 4T 直接组一个大 RAIDZ2 ，随便别人怎么用。
我自己家里的 NAS ，2U 的机器 12 盘 16T ，全部单盘，不做任何 RAID 。
另外一台 NAS ，2U 的机器，塞硬盘做备份。
单盘是最没负担的，想买就买，想换就换，主硬盘坏了直接把备份盘填上就行，也不用纠结什么重建。

sicifus

347 天前

@msg7086 #49 感谢回复！
1 ）关于 URE 或相关的重建恢复问题，我除了关注理论计算值外，另外也比较关注网友实际碰到的情况。毕竟如果只考虑理论风险的话，由 n 个数学大佬们加持的 LTCM 长期资本管理对冲基金应该直到现在还获得好好的。

目前我看到的网上可见案例里，一旦重建恢复，民用级 raid 导致的第二块磁盘故障的案例不少，结合风险=风险等级*风险概率的公式，在我的承受范围下属于不可接受的风险。

2 ）诉求是想省钱、且不折腾、且低风险。所以整体方案要考虑 a)容量可扩展，b)扩展可平滑，c)1+1 存储池

msg7086

347 天前

重建时第二块硬盘故障这个你得带着点盐去看。比如说平日有没有每月（或者每两三个月）刮数据，这个对结果的影响很大的。你说的重建时第二块硬盘故障，我敢说至少有九成的情况是第二块盘早就已经有数据损坏了，只是在重建的时候发现了这些损坏而已。真正的第二块盘原本是完好的状态，在重建过程中开始损坏的，其实很少很少的。
我前面也已经说过了，一个文件不读不写，硬盘就不知道他的好坏，所以可能一个文件半年前已经坏了，而你半年后重建阵列的时候才发现。这个不是 URE 或者 RAID 的问题，纯粹就是自己没有搞清楚，没做好。
这个错之前 LTT 老莱也犯过 https://www.bilibili.com/video/BV1844y1W74r/ 05:55 前后有解释为什么会出问题（以及如何避免这类问题）。

至于既要省钱又要低风险又要不折腾……有这么好的事情一定要跟我说说（

sicifus

347 天前

@msg7086 #51
按照你提供的视频里的说法（ 05:33 起），成品 NAS 都是有自动化的定期数据清理机制的，而开了这个机制后就能监控到磁盘损坏，而不必等到重建时才发现。他们之所以数据丢失的原因就是因为自搭的 CentOS 上没有开启定期清理，nothing more ，没有提到需要"刮数据"。以上是我看完后的理解，若有错误请指正。

关于既要又要还要，不是一个绝对的概念，而是和对标对象的 PK 下的相对胜出。主贴里的小结部分提到了，这里再扩展开说一下：

1 ）省钱：主要对标 raid5 、raid1 、群晖。
raid5 的“不省钱”体现在需至少 [一次性] 采购 3 块同容量磁盘（ 67%容量利用率）、更普遍做法 [一次性] 采购 4 块（ 75%容量利用率）。此外，4 盘同时运转更耗电。
raid1 的“不省钱”体现在空间利用率只有 50%上，但由于初期磁盘可只买 2 块，数据量上去后再按需追加，实际有效容量的成本是接近乃至持平 raid5 的。（当然要看自己的数据增速，增速越快、磁盘二次采购期越近，raid1 越劣势）。
群晖的额外“不省钱”体现在盘位费贵、系统要在每块磁盘都要复制一份等等。

我的思路是保留 raid1 按需扩容的优点，同时避免它必须每次买 2 块的缺点，二次、三次购买都是采购容量翻倍的单块磁盘，通过延长分批采购的时间吃到技术进步&成本下降的红利。同时，磁盘越少电费约省。此外，无需捆绑于群晖。

2 ）不折腾：在容量扩容的硬需求下，主要对标条带化 raid （包含 shr 、zfs 等），以及传统 basic 1+1 模式。
raid/zfs 的一个“折腾”主要体现在条带化存储导致的「 data lock-in 」，在磁盘扩容时必须经历数据导出 -> 磁盘清空 -> 重新导入数据的过程。
此外，磁盘替换时（坏道，或 shr 场景下的磁盘替换增容），raid 重建过程中 CPU 和 IO 性能会狂跌，要忍受大几十小时的不可用时间。
basic 1+1 模式的“折腾”主要体现在磁盘>=3 时，文件管理的不便。

我的思路是放弃条带化存储（ raid 的缺点、basic 1+1 的优点），技术方案是 snapraid 。同时采用存储池（ basic 1+1 的缺点、raid 的优点），技术方案是 mergerfs 。
针对有些楼内说的多盘 mergerfs 下 io 性能不佳的问题，采用主存储池单块磁盘、日常 io 操作，备存储池多块磁盘合并、只做冷备的方式来解决。

3 ）低风险：对标条带化 raid 。
条带化 raid 的“风险”场景：重建时的损盘（争议很大，但至少 ≥ basic 吧？ basic 重建只需复制、无需校验/擦写）
raid5 的额外“风险”场景：多盘同时坏块。

我的思路：同第二条，弃条带化，采用文件级 raid ，叠加 1+1 备份。即便多盘出现坏块，也只损伤特定文件，不涉及跨盘的条带校验值，也不影响其他文件的随意增查删改复制等操作。

不知上述解释能否略微澄清一些你的疑惑？

ericFork

346 天前

企业盘吵其实是个刻板印象，东芝 MG08/MG09 实测都相当安静，你可以去找找它们的运行录音视频

standin000

346 天前

@libook 请教下，如果全上 m.2 接口的 ssd ，是不是对硬盘笼的电源要求就低，也不用解 HBA 卡了。

msg7086

346 天前

@sicifus 不是定期清理，是定期 scrubbing ，也就是我说的定期刮数据。

msg7086

346 天前

另外你的「省钱不折腾低风险」在我看来是相当「不省钱折腾高风险」的方案。
如你所说盘位成本很高，当你第 3 块盘是前两块盘的两倍容量的时候，就意味着你有两个盘位的容量只有一半。
放到今天来说，就相当于你之前买了两块 6T ，现在加了一块 12T ，那你 6T 还是用小容量占坑，等于还是亏了。
如果是第三次扩容，那就相当于里面放了两块 3T ，一块 6T ，一块 12T ，更亏了。
条带存储在磁盘扩容时必须导出再导入，这个没错，但是你配置 snapraid+mergerfs 就算是不折腾了吗。snapraid 和 mergerfs 的坑都踩过一遍了吗？这两个方案用的人可是远远比 zfs 和 RAID 少的。
风险，使用多个软件去解决单个问题，每个软件都是 point of failure 。你自己写 snapraid 配置文件，万一写错，就可能出问题。包括上面#37 说的，万一文件变了，文件对应的块的保护就会失效。在你不知不觉的时候你的数据可能就会掉保护而你自己可能都不知道。你告诉我这是低风险吗。

所以我的结论就是，没有方案能做到既要省钱又要低风险又要不折腾，要是有这么好的事情，企业早就用了。那企业在用什么呢？企业在用 zfs 。

msg7086

346 天前

更大的企业在用类似 ceph 之类的方案，或者 glusterfs 这样的分布式存储，很成熟的方案。前者可以拿来跑高可用虚拟机，Proxmox 在用的，超融合架构，还有像 vSan 这样的产品。后者主要是文件存储，可以动态增减硬盘和服务器扩容。如果你能承受 1+1 备份的话，说不定可以考虑 glusterfs 。
不过我还是觉得普通家用就是最简单的配置最好，单盘单分区，放满了换块盘放，备份就是盘对盘互拷，升级硬盘就是插上硬盘，复制数据，拔掉旧盘。

libook

346 天前

@standin000 两个问题。
首先一般说的 HBA 卡实际上是 SAS 控制器，就是负责将 PCIe 协议转成 SAS 协议。而 M.2 接口通常是 PCIe 协议或 SATA 协议，如果是 PCIe 协议就是直接连接 PCIe 接口（可能需要 PCIe 拆分卡），如果是 SA 协议就是连接 SATA 控制器；也就是说一般不需要 HBA 卡，因为协议不一样。

硬盘的功耗跟接口关系不大，得实际看硬盘产品的官方手册里的额定功率，SSD 用高速主控和大容量闪存阵列也可以很吃电。常见企业级 M.2 产品功率在 4W-15W ，家用级机械硬盘功率在 5W-14W ；企业级机械硬盘以希捷银河 x18 为例，满载在 9W 左右。HBA 卡不同信号功率也不一样，在 6W 到 26W 。机械硬盘可以通过停转休眠来显著降低功耗，SSD 也有的型号具有断电休眠技术，具体看产品手册是不是有这些节能特性。

题外话，M.2 产品目前相对来说比较贵，如果决定用全闪方案，可以看看 U.2 口（通常也是 PCIe 协议）的产品，可能可以便宜，性能一样。

sicifus

345 天前

@msg7086 #56
"放到今天来说，就相当于你之前买了两块 6T ，现在加了一块 12T ，那你 6T 还是用小容量占坑，等于还是亏了。如果是第三次扩容，那就相当于里面放了两块 3T ，一块 6T ，一块 12T ，更亏了。"
————————————————
我觉得这段话里大概有三个问题：
1 ）扩容应该算边际成本的，在现有 2*6T 的情况下，方案①：只需额外采购 1 块 12T 、且充分利用原有 2*6T 、且构成了 1+1 容量完全均等（主 12T ，备 2*6T ）的主备存储池，和方案②：采购 3 块 12T ，替换下原有的 2*6T 又没有合适的用途，明显是方案①的成本更优。
2 ）第三次扩容你的方法写错了，不是 2*3T+1*6T+1*12T ，而是 2*6T+1*12T=24T 组成新的备用池，再采购 1 块 24T 组成主用池。保护
3 ）至于“盘位成本很高”，我是寻求一条保护即有盘位投资+磁盘投资的同时、兼顾容量可扩展性的道路。
说白了现有一般的容量扩容思路有三种，
第 1 种是盘位扩容法，即容量用满时，新采购一个 NAS （或硬盘柜），缺点是最贵，即同时增加盘位投资和磁盘投资，同时亦存在文件跨盘管理的问题。
第 2 种是磁盘扩容法，即容量用满时，新采购 n 块磁盘，缺点是次贵，一般需要采购 2 块（ raid1 ）及以上（ raid5 ），且数据迁移的难度不低，风险有较大争议。
第 3 种是 shr 扩容法，即可按单盘位分批容量升级。这是成本相对最理想的情况。
我的改进思路是基于 shr 的可扩展+性价比的基础上，一方面建议采用(n+n)+2n+4n 的分布扩容法，性价比（磁盘延迟采购）和数据安全性（ 100%备份）最平衡，其次对于普通用户来说可以降低对条带化存储的迷信，开阔一下思路。

就像你说在 56#和 57#提到的企业级的方式，其中 zfs 我并不想否定其价值和意义，就像普通 raid 是有其价值和意义一样。我只是说从 basic 1+1 往上走，如果关注重点是性价比、磁盘扩容便捷性、数据备份性，而不是 NAS 高可用性等特性的话，其实有其他更便捷、性价比更高的 [民用级] 存储扩容和管理思路的，不需要直接跳到的条带化存储思路上去。

57#的“单盘单分区，放满了换块盘放，备份就是盘对盘互拷”的思路，其实的确是民用级最简便的扩容方案，唯一的一个问题是跨盘文件管理的不便，因此需要在这个基础上引入一下 mergerfs 做存储池。