淋巴转移不算远端转移，LZ 要乐观、坚强

自动 LZ 在 V2 站发帖说买房车后就关注上你的博客 rss 了，
虽然我自己应该不会买房车，
但经常能看到房车旅行记录也蛮开心的，云吸房车，
有些经验在自驾游时也能用得上。
感谢~

自从家附近有奥乐齐后，感觉就不需要山姆了

@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 做存储池。

@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 备份。即便多盘出现坏块，也只损伤特定文件，不涉及跨盘的条带校验值，也不影响其他文件的随意增查删改复制等操作。

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

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

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

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

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

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

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

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

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

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

@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 ），感觉好像槽点有点多、学习成本不低，所以也没特别关注了。

@ButcherHu #36 感谢回复！
Mergerfs 的实际体验是我特别想知道的，感谢提醒避坑~

@HXHL #38 感谢！学到新知

@HXHL #27 感谢回复，
能稍微扩展说一下吗？或者给几个关键词我自己去搜一下，
谢谢~

@Ariver #30
事实上是，"我全都要"。
主贴的图已经画了，采用存储池 1+1 备份，因此不光可以接受某个硬盘数据丢失，还可以接受这个存储池下任意 n 块硬盘数据丢失。

@aru 会不会哪里没设置好？我看到的说法 mergerfs 的性能基本上就取决于单盘的读写性能么

@首页 #19 最后一句修改为"因为是数据复刻备份，而非数据+校验字节的条带化存储"