SnapRAID 与 mergerfs 如何搭配使用

几块不同容量的硬盘，能否像一个目录一样使用，同时保留一定的坏盘恢复能力？SnapRAID 与 mergerfs 常被放在一起讨论，但二者负责不同工作：mergerfs 整理访问入口，SnapRAID 保存用于恢复的校验信息。组合是否合适，取决于资料变化频率，以及你是否愿意持续维护。

本文以 Linux 家庭文件服务器为例，适合已经会挂载磁盘的读者。SnapRAID 也支持 Windows，但这里的 mergerfs 路径和配置流程不能直接搬到 Windows。首次尝试应使用可丢弃的测试资料。

一个合并目录，一个维护恢复点

mergerfs 是基于 FUSE 的联合文件系统，将多个目录呈现在同一个挂载点下。它处理的是路径，底层磁盘仍保留各自的文件系统；它本身不计算 RAID 校验，也不复制每一份文件。项目仓库明确列出了这一定位。

普通文件不会被拆成条带分散到多块盘。因此，即使合并入口显示还有不少空闲空间，新文件也必须能放进某个符合分配策略的分支。单文件传输速度也不会因为盘数增加就自动叠加。参见mergerfs 的限制说明。

SnapRAID 则在运行同步时更新校验信息，形成恢复所依赖的时间点，并非每次写文件就实时更新保护。这种区别见官方方案比较。它很适合变化较少的媒体资料库，但不能按实时镜像的预期使用。

如果资料通常是“复制进去，之后很少修改”，例如已整理的影音文件、导出的历史项目，这种组合比较容易维护。底层目录仍可分别查看，也便于理解文件实际存在哪里。

数据库、正在运行的虚拟机、持续下载中的文件和频繁改写的工作目录，应另行设计存储与备份。建议先在工作区完成下载或编辑，再把稳定版本放入受保护目录。对无法重建的家庭照片与私人文档，仍应保留独立备份，不能因为有校验盘就删除唯一的其他副本。

可以先画出一个小清单：数据盘挂载到 /srv/data1、/srv/data2，校验盘挂载到 /srv/parity，mergerfs 的统一入口则设为 /srv/pool。这些只是示例路径，不代表目录存在就已经挂上硬盘。

实际配置按下面的顺序进行：

核对物理磁盘与挂载。 使用稳定标识配置挂载，并确认重启后仍指向正确设备。挂载失败时，空目录可能留在系统盘上，不应让服务继续往里面写数据。
分别记录数据盘。 SnapRAID 的 data 项指向独立数据盘目录，不要把 mergerfs 合并入口作为唯一数据盘。给每块盘分配固定名称，后续恢复会用到。
规划校验及元数据。 单校验盘方案应让校验盘可用空间足以容纳最大数据盘对应的校验数据，不要只按目前文件总量估算。把 content 元数据副本放到不同物理磁盘；它保存文件清单和校验信息，不能只留一份在可能坏掉的盘上。
再设置聚合入口。 mergerfs 只纳入数据目录，校验盘不要混进普通文件的写入分支。先理解文件创建策略，再决定是否调整默认配置。分支配置文档可用于核对路径写法。
建立运行记录。 首次运行 snapraid sync 后检查结果；之后用 snapraid diff 查看变化，再按计划同步，并定期运行 snapraid scrub 检查。命令成功退出、日志无异常，才算完成一次维护。

容量、content 副本和命令的准确要求，应按已安装版本对应的 SnapRAID 手册确认。不要只复制别人多年前的配置，也不要把自动脚本“启动过”当作任务成功。

假设昨晚完成同步，今天向数据盘新增文件，随后该盘故障。这些未同步的新文件不受昨晚恢复点保护。

更容易忽略的是：没有可用文件系统快照保护时，其他健康盘上被删除或改写的旧数据，也可能导致坏盘上的部分数据无法恢复。因此不能简单理解成“最多只损失坏盘上今天新增的文件”。SnapRAID FAQ专门解释了这一限制。

当前文档介绍了文件系统快照集成，但是否可用取决于软件版本、底层文件系统与配置，不能默认已经启用。准备依赖它之前，应查对应版本文档，并用测试数据演练。

出现故障后，先暂停共享写入和定时维护，保留日志、配置及现有 content 文件，不要先运行同步来“刷新状态”。按照手册把故障盘对应路径改到容量足够的恢复目标，再进行定向恢复和校验。恢复命令可能改写文件，务必确认目标名称与路径。

恢复结束后先检查日志中的不可恢复项目，再实际打开重要文件。只有确认结果可接受，才进入重新同步阶段。若资料不可替代而故障原因不明，应先保全设备状态，避免反复写入。

这套方案的关键不是把命令排进定时任务，而是知道最近一次成功同步发生在何时、有没有错误，以及需要恢复时该先停下什么。做到这些，统一目录带来的便利才不会掩盖实际风险。