家庭存储中常见的几个选择，处在不同的产品和技术层面：

图中的容量柱表示汇总占比，不是真实分区，未计入元数据和恢复预留。Ceph 副本的不同颜色仅用于区分容量开销，不表示主从关系。

单盘冗余方案在一块盘故障后便失去冗余，重建期间若再发生磁盘故障，就可能丢失数据。对于长期运行、硬盘逐步老化的家庭存储，单盘冗余的可靠性风险较高，本文直接以至少容忍两块硬盘故障的方案为基准讨论。

对比配置：RAID 6、群晖 SHR-2、ZFS RAIDZ2、Unraid 双校验、Ceph 三副本。

对于照片、影音、文件共享和备份等常规家用存储需求，单机方案通常已经够用。相比多节点集群，单机方案的硬件、用电和维护成本更低，管理也更简单。

Ceph 是一个开源分布式存储项目，起源于 Sage Weil 的研究工作，后来由 Inktank 推动商业化，2014 年 Inktank 被 Red Hat 收购。2022 年，Red Hat 的 Ceph 团队转入 IBM，项目持续由社区和多家厂商共同参与。

Ceph 底层以 RADOS 分布式对象存储为基础，将数据组织成对象，经 PG（归置组）和 CRUSH 规则分布到不同 OSD（管理磁盘的存储进程），并按配置保存副本。上层通过 RBD、CephFS 和 RGW 分别提供块、文件和对象存储，具体见 Ceph 架构说明。下图以跨主机三副本为例。

最终选择 Ceph 方案，我主要考虑以下几点：

冗余带来的容量损失，对我来说可以接受。家里的数据体量没有那么庞大，HDD 的存储成本相对便宜，即使到了 2026 年，我手上仍有一批 Chia 企业级矿盘。

bcache 位于 Ceph OSD 使用的块设备下方，用 NVMe 为 HDD 提供缓存，希望兼顾机械硬盘的容量成本和闪存性能。

缓存命中时读取 NVMe，未命中时读取 HDD，并按策略填充缓存。写回模式先写 NVMe，再由 bcache 回写 HDD，直写模式则需等待 HDD 写入完成。

缓存收益取决于访问模式和命中率。我的 NAS 中有大量不经常访问的文件，冷数据首次读取仍然需要访问 HDD，缓存无法直接改善这部分体验。

实际使用中，我遇到了潜在的稳定性问题，也需要考虑缓存设备失效的影响。尤其是写回模式，NVMe 可能承载尚未写回 HDD 的数据，不能当成随时可以移除的读缓存。共享缓存设备还可能同时影响多个后端设备，增加排查和恢复的复杂度。

另一种思路是保留 HDD 存放数据，将 BlueStore 的 block.db 放到 NVMe 上，减少元数据访问对 HDD 的依赖。block.db 保存 RocksDB 元数据，block.wal 用于日志，配置独立 DB 后，WAL 默认也会放到 DB 设备上。具体见 BlueStore 配置说明。

同一块 NVMe 可以划出多个独立的 DB/WAL 空间，分别对应各个 HDD OSD。读写由 OSD 协调：通过元数据定位 HDD 上的数据块，写入时管理数据落盘及元数据、日志更新，内存命中的元数据无需再从 NVMe 读取。

元数据拆分不等于给文件内容加缓存。读取冷数据时，HDD 的寻道和介质延迟仍然存在。

两种加速思路在我的环境中都增加了稳定性顾虑和维护复杂度，而对冷数据读取的改善有限。我最终没有继续沿用。具体经历不足以归结为某个方案的普遍缺陷，但足以影响我自己的选择。

最终，我将 HDD 与 NVMe 拆分成独立存储池，通过设备类别和 CRUSH 规则限定数据落点。需要较高 IOPS、吞吐和较低延迟的业务直接使用 NVMe，容量型负载使用 HDD，数据放置和迁移在业务侧安排。

我的存储网络使用 10GbE。实际性能测试和长期使用下来，HDD 池足以满足我的 NAS 文件存储、虚拟机镜像备份和容量型对象存储需求。小文件、随机访问、并发量以及恢复期间的负载仍会影响体验，不能据此推断所有场景都能跑满 10G。

下面是早期一次 CephFS 文件读写测试的记录。

测试在 CephFS 挂载目录中进行，文件约 2.46 GB，写入显示 854 MB/s，读取显示 2.8 GB/s。结果包含缓存影响，不等同于 HDD 持续落盘速度或网络吞吐。结合长期使用体验，文件访问性能符合我的 NAS 文件存储需求。

2025 年年中，在随后那轮 SSD 大面积涨价之前，我轮换了一台节点，采用 U.2 NVMe 全闪方案替换，继续推进存储的闪存化改造。

早期我也纠结过是否要引入 UPS（不间断电源），主要担心突然掉电造成数据丢失。但 UPS 本身也有需要权衡的问题：

电池安全性与寿命的差异可参考 Eaton 的 UPS 电池说明。

实际测试没有遇到数据丢失，多年使用中机柜发生过大约三到四次掉电，也没有出现已写入数据丢失的问题。经过实践验证，我对自己这套环境的掉电恢复也就放心了。

我的需求边界是：可以接受掉电瞬间尚未完成的写入失败，重点是已经确认持久化的数据应当保留。我没有要求找回所有写入中的数据。对于虚拟机和数据库，应用是否完成事务提交、是否正确执行同步写入，以及设备是否兑现 flush 请求，仍然影响这个边界。

掉电测试和实际故障经历没有覆盖所有故障组合。Ceph 的副本不能替代设备掉电保护、正确的持久化语义、UPS 和独立备份，同机柜副本也无法隔离整柜供电故障。

跨节点副本的价值，就体现在这些局部故障发生时，仍有其他节点上的数据可用。但同一块 HBA 或背板可能同时影响多块盘，所以故障域不能只按「坏一块硬盘」来理解。维护时也需要确认其他节点健康，避免故障叠加。

将 PVE 网络与 Ceph 网络分开，让存储通信使用独立网络。PVE 网络承载计算侧的管理与业务通信，Ceph 网络用于存储访问，以及 OSD 之间的副本同步、心跳和故障恢复流量。

独立网络的价值在恢复期间尤其明显。硬盘故障、节点重新上线或数据重新平衡时，Ceph 会产生额外的数据传输。将这些流量与 PVE 侧通信分开，可以减少带宽争用，也便于分别观察存储链路与计算侧网络的负载。

我的划分只有 PVE 和 Ceph 两类，Ceph 的客户端访问与 OSD 间通信共用存储网络，没有进一步拆分 public_network 和 cluster_network。家庭环境下，我选择先控制网络复杂度，网络模型可参考 Ceph 网络说明。

网络隔离的实际效果还取决于底层链路。VLAN 可以划分逻辑网络，但如果共用同一条物理上联，仍然会争用带宽。容量规划需要同时考虑日常访问与故障恢复，不能只看网卡标称速率。

实际应用中，我按存储介质和数据级别划分存储池，分别设置冗余度。分池时主要考虑以下几点：

每个池对应的设备都需要留出恢复和重平衡空间，不能只按原始容量除以副本数来规划可用容量。不同池如果共用 OSD，仍会共享磁盘容量和 I/O 资源。

对于能够持续接收告警并及时处理的家用集群，我倾向于配置 noout。家里会遇到各种预期外的小故障，例如临时断网、节点重启或接触问题。设备明明可以很快恢复，却因为超时被自动标记为 out，触发一轮数据迁移，恢复后又需要重新平衡，会给整个集群增加额外负载。

noout 的作用是阻止 down 的 OSD 因超时而被自动标记为 out，不是让 OSD 保持在线，也不是禁止所有恢复或数据移动。官方在 OSD 故障排查说明中介绍了维护时使用和解除该标志的方法。

计划内维护可以按实际版本能力，将 noout 的范围缩小到相关 OSD 或主机。长期保留集群级 noout 则意味着主动承担故障处理责任，不能把它当成一条设置完就可以忘记的优化参数。

Ceph 的副本解决介质和节点故障，并不能恢复误删除、应用错误覆盖或者被入侵后同步删除的数据。我采用冷数据静态备份，加上部分关键数据备份到云上对象存储的方案。

冷数据保留独立副本，使恢复不必完全依赖这套 Ceph 集群。云上对象存储则提供另一个位置的恢复来源，避免同一个机柜的问题影响所有数据。

云端备份使用对象存储保存部分关键数据。对象存储 key 的权限需要限制，日常备份使用的凭据与管理凭据隔离，按所需桶和前缀授予最小权限，尤其避免让日常写入凭据拥有删除历史版本或修改版本控制配置的权限。同时启用版本控制，保留错误覆盖或误删除之前的版本。

版本控制仍然需要配合权限和保留策略使用，不能当作不可删除的备份。备份是否成功、历史版本是否仍在，以及能否实际恢复文件，都需要定期检查。