DIY unraid 替代品： SnapRAID

[kice]

这里有一些我对于 samba 的一些不满，简单概括就是文件路径太长 samba 不支持，导致文件名可用字符很短。结论下来 SMB 服务器还是得 Windows 。

Windows 下有存储空间，但是这个东西风评不是很好，文档也不全。隔壁 LTT 也抛弃了使用这东西来组磁盘阵列。

于是，先大概列出组磁盘阵列要有的功能：

1. 一定程度内，硬盘故障不会导致数据丢失
2. 允许添加任意大小的磁盘进行扩容
3. 冗余级别可以自行选择

然后就发现了 SnapRAID 。一个跨平台的文件“备份”方案。使用效果和 Unraid 类似，不是传统的 RAID ，但是也能提供一定程度冗余。

SnapRAID 运行在文件系统之后，而不是组了 RAID 之后再运行文件系统。于是这东西就能跨平台。

目前打算是这样整：

PVE -> Windows Server -> SnapRAID -> DrivePool -> SSD Cache -> SMB

DrivePool 可以替换成 RClone Union + WinFSP ，但是这样估计太怪了。

然后就是 SSD 缓冲的设计，可以是只缓冲 SMB 写，也可以是缓存每个硬盘。估计 PrimoCache 可以完成。

OVM 是有 SnapRAID 插件，配合 MergerFS 就能实现以上功能。但是我不要 Samba ，或者 OVM 开 NFS 然后 Windows 提供 SMB ？

最后就是 SnapRAID 的配置

1. 校验数据和 Unraid 一样，校验数据的硬盘必须是最大容量的硬盘。校验数据是普通的文件，于是允许校验盘是多个硬盘组成，但是实际上使用会不会有问题。
2. SnapRAID 需要手动同步。虽然跑一次影响不大，但也是要手动（或定时，或事件触发）跑一次。
3. 关于大量小文件的友好程度。

想听听 dalao 们有什么看法。

[sNullp]

看着不错，会在下一个服务器里试试。感谢。

[TsubasaHanekaw]

DrivePool 现在用在 6x16Tb 硬盘上,不做冗余挺好,就是没法创建硬链接

[anubu]

homelab 场景的存储设计，个人倾向于优先考虑池化，其次是备份，最后是高可用。个人用户需要保障“硬盘故障不会导致数据丢失”的数据量一般不大，通过备份实现比通过类似 RAID 的高可用实现更合适，复杂度也更低。当然，需要研究各种软硬 RAID 方案的除外。

[totoro625]

PVE 里面塞 Windows server 是为了方便使用吗？还是为了原汁原味的 SMB ？

SnapRAID + DrivePool 的组合，感觉 DrivePool 的均衡器设置 + SSD Cache 会影响 SnapRAID 的数据恢复
参考：[NAS] 24 盘位 Stablebit DrivePool+SnapRAID NAS 阶段性总结： https://www.chiphell.com/thread-1914792-1-1.html

我买了正版 unRAID ，但是目前在用 ZFS
笔记本上用了 SnapRAID ，想通过 scrub 命令防止静默数据损坏，但是我的数据一直在变化，感觉起不到应有的作用

[NSAgold]

snapraid+mergerfs 对大多数家庭用户来说可能比上 raid 更合适，因为家庭用户照片视频类的冷数据会比较多，对可恢复性需求＞可用性，而且扩容方便，只要校验盘≥最大的数据盘就行（严格来说卷也可以 比如 16t 分 4 个 4t 卷可以用一块 4t 盘校验 不过太灵了）。
但是对于 homelab 玩家来说热数据比较多的话 snapraid 不是很合适，同步会比较耗时。

[kice]

@totoro625

PVE 塞 Win 是因为直接 Win 的话虚拟机会麻烦，不如直接 Win 虚拟机。

samba 文件路径长度限制太痛。想过是 NFS 或者 iSCSI 给 windows ，然后再 win 提供 SMB 共享。

现在用的是 unraid ，但是 unraid 的 NFS 性能有问题，iSCSI 插件可靠性未知。
TrueNAS NFS 和 iSCSI 都有，但是只支持 ZFS 或者单盘使用。要么扩容太难，要么接受单盘挂了会损失数据。

---

snapraid 适合文件内容不会变化的情况；看上去你这个是数据较少，可能更适合整快照。

---

如果是偏向于冷储存，多盘的均衡可以关掉。

[libook]

我是从 MergerFS+SnapRAID 转到 unRAID 的。

SnapRAID 是非实时校验，如果你只有一块校验盘的话，那么你最好不要同时对多块盘的同一个位置的数据块进行写入操作，否则这块数据就是不可恢复的，直到下一次同步校验数据。

也就是说，推荐的使用场景是，在两次同步校验数据之间，你最好只对一块盘进行写入操作；或者在对第二块盘进行写入操作之前，先进行奇偶校验同步。

当然，不排除确实有人的使用场景是符合这个要求的，比如备份数据等冷归档数据。

我换 unRAID 的最大原因是 MergerFS 近期崩溃频率较高，跟开发者一起调查了很多次也没有定位到问题，不得已换了 unRAID 。

[MoonLin]

@libook 配合 btrfs 看起来可以解决这个问题： https://github.com/automorphism88/snapraid-btrfs#q-why-use-snapraid-btrfs
在 sync 时建立快照，即使两个盘同一个位置都写脏了，其中一块盘坏了，fix 的时候可以用好盘的快照配合校验数据就可以恢复数据到上次 sync 的状态。

[kice]

现在搭建好了环境，在开始 SnapRAID 之前，有几个问题需要解决下：

1. PVE 的 PCIe 直通和内存动态分配不兼容，所以要么不直通 PCIe ，要么就固定内存给虚拟机。主要关系到 NVME 盘直通。
2. 我用的 R730XD ，然后 PVE 挂在了 HBA 上。机械盘不能直通给虚拟机，只能通过软件直通（ RDM ）。
3. RDM 直通有盘数量限制，一共是 33 个的样子。其次，RDM 直通只能设置硬盘序列号，不能设置硬盘型号，也没有 SMART 信息。
4. ~~PVE 的虚拟网卡只有 10Gb ，希望未来够用。~~

5. **DrivePool 平衡策略只能通过界面触发。**
6. **SSD 缓存 DrivePool 需要手动触发“平衡”才能写到机械硬盘。**
7. **DrivePool 文件分配策略搞不懂，要同时避免 SnapRAID 同步时不能触发平衡和能合理分配文件。**

8. PrimoCache 也可能出现 SnapRAID 同步时发生写操作。
---

1 ～ 4 暂时不影响使用，SMART 信息可以通过 SSH 到宿主机或者宿主机用 PY 暴露 HTTP 接口。
NVME 使用 RDM 直通性能看上去还行（用的 virtio scsi single 和一堆参数）。

DrivePool 可能并不十分合适 SnapRAID ，但是没有替代品。目前在研究使用 Rclone+WinFSP+Union ，目前看上去性能应该够用。


关于分区合并，我暂定了以下需求：
1. 能使用 SSD 作为写缓存。
2. 写缓存回写可以手动控制。或者在 SnapRAID 同步时，整个机械盘池能变为只读（写入只写到 SSD 上）。
3. 文件分配磁盘选择能平均一些。
4. 文件分配后，不能移动到其他硬盘；或者一次只能移动一个磁盘，并且在移动完成能触发 SnapRAID 同步。
5. 能被 Everything WizTree 索引。


最坏的情况是写一个 DrivePool 插件，或者直接把 Rclone 的 mount 代码提取出来改改。

[lisaac]

就像 @MoonLin 提到一样，snapraid 最佳拍档还是快照，先快照，再同步
恢复时直接用快照恢复，从而避免文件被修改而导致部分文件无法被恢复的情况

前几天写了个脚本，用的也是 btrfs ，相比 snapraid-btrfs 增加了对 parity 快照保存，这样恢复的时候就有多种选择