SHR 是什么：群晖混合 RAID 的原理、容量账与扩容路径
一句话说明白 SHR
SHR（Synology Hybrid RAID）是群晖自己实现的一套基于 LVM 和 mdadm 之上的逻辑卷管理机制，它的核心目的只有一个：让不同容量的硬盘混在一起时，尽量少浪费空间，并且允许你一块一块加盘。
传统 RAID 5 有个硬伤——所有成员盘容量按最小那块算。你买了三块盘，4TB + 4TB + 8TB，组 RAID 5 之后每块盘只按 4TB 参与计算，可用空间是 8TB，那块 8TB 盘多出来的 4TB 直接躺尸。
SHR 会把硬盘切成小块，按不同组合再做冗余，结果是同样的三块盘能用到 12TB（其中 4TB 用于校验）：
| 组合 | RAID 5 可用 | SHR 可用 | 多出来的空间 |
|---|---|---|---|
| 4TB + 4TB + 4TB | 8 TB | 8 TB | 0 |
| 4TB + 4TB + 8TB | 8 TB | 12 TB | +4 TB |
| 4TB + 8TB + 8TB | 8 TB | 12 TB | +4 TB |
| 4TB + 8TB + 12TB | 8 TB | 20 TB | +12 TB |
| 6TB + 8TB + 10TB + 12TB | 18 TB | 24 TB | +6 TB |
最后一行是 SHR 最典型的家庭场景：手里东拼西凑几块不成大小的盘，传统 RAID 会按 6TB 算，SHR 能把剩余空间挖出来大部分。
它到底怎么实现的
不必深究内核实现，理解这个模型就够了：
SHR 把每块物理盘切成较小的分区，然后按容量相同的分区组合成若干个 RAID 组，最后把这些 RAID 组串成一个大的逻辑卷。
举例：4TB + 4TB + 8TB
- 三块盘各切出 4TB 分区 → 组成 RAID 5（可用 8TB）
- 8TB 盘剩下的 4TB 分区单独组合 → 这部分在只有一块盘时没有冗余，但 SHR 会在后续加盘时自动升级
这就是为什么 SHR 能在扩容时”自动折腾”——它不是什么魔法，是后台在数据层面重新做条带和校验。
由此也带来两个必须知道的限制：
- SHR 状态下所谓”无冗余分区”是存在的。两块盘容量差异过大的组合，部分数据不一定有冗余保护，看存储池状态会提示
- 重建时间可能比标准 RAID 长。因为涉及多个逻辑层的重算，大容量盘重建以天计很正常
SHR 与 SHR-2 怎么选
| SHR | SHR-2 | |
|---|---|---|
| 容错能力 | 允许 1 块 盘故障 | 允许 2 块 盘同时故障 |
| 最小盘数 | 1 块（无冗余）/ 2 块（有冗余） | 4 块才有意义 |
| 容量利用率 | 略高于 SHR | 低，要两份校验 |
| 适用场景 | 2~5 盘位家庭、小团队 | 6 盘位以上、数据重要、重建窗口长 |
一个容易被忽略的事实：盘越多、单盘容量越大，RAID 5 / SHR 的单盘容错就越不够用。
原因在重建。一块 16TB 的盘挂掉后，换新盘重建需要从其余盘读取全部数据重新算校验，这个过程可能持续一两天。而大容量硬盘在重建这种高强度读取下，第二块盘出现 URE（不可恢复读取错误）的概率并不是零。所以：
- 4 盘位及以下：SHR 足够，但必须有完整备份
- 6 盘位及以上，或单盘 ≥ 12TB：认真考虑 SHR-2 或 RAID 6
再次强调：任何 RAID 都不是备份。SHR 解决的是”硬盘挂了服务不中断”，解决不了误删、勒索软件、火灾水淹。这两件事要靠快照和异地备份。
容量怎么算才准
很多人算容量时会被”标称容量”和”实际可用”的落差搞晕，这里给个实用算法：
1. 硬盘厂商按 1TB = 1000GB 标称，系统按 1TB = 1024GB 识别 → 先打约 0.91 折 2. 一块 8TB 盘在系统里实际约 7.28 TiB 3. SHR 单盘容错模式，总容量减去最大一块盘的容量 = 可用空间
公式：可用空间 ≈ (所有盘实际容量之和 − 最大一块盘的实际容量) × 0.93（还要扣文件系统预留）
举例 DS925+ 四盘位，插 4TB + 8TB + 8TB + 12TB：
- 实际分别约 3.64 + 7.28 + 7.28 + 10.92 = 29.12 TiB
- 减去最大 10.92 → 18.2 TiB
- 扣掉文件系统预留，实际可用大约 17 TiB 左右
按这个方法估，跟 DSM 里显示的结果基本吻合。
扩容：SHR 真正好用的地方
SHR 最大的价值其实不是初始混插，而是后续加盘太省心了。
支持三种扩容方式：
| 方式 | 操作 | 适用场景 |
|---|---|---|
| 增加硬盘 | 空槽插入新盘 → 存储管理器里点”扩充” | 还有空闲盘位 |
| 替换更大硬盘 | 逐一替换，每次替换后修复 | 盘位已满，想整体升级 |
| 两者结合 | 先加盘，再逐步替换 | 长期演进 |
加盘时的具体规则：
- 新盘容量 ≥ 存储池中最小盘，才能直接获得额外空间
- 新盘容量 ≥ 单盘冗余所需（单盘容错是最大那块的容量），才能完整扩
- 低于这个阈值也能加，但可能只在别的方面提供价值（比如加到 SHR-2）
替换扩容的完整流程（这块必须按顺序来，一步错就危险）：
1. 确认当前存储池状态正常、有完整备份 2. 关机或按 DSM 的”停用”流程处理要换的那块盘 3. 物理更换为更大容量新盘 4. 存储管理器 → 修复存储池，等待重建完成 5. 等状态完全正常后，再换下一块
每块盘重建可能要一两天，四块盘轮一遍就是一周多。这段时间机器是降级状态，别再折腾别的。
SHR 相对 RAID 的取舍
| 维度 | SHR | 传统 RAID 5/6 |
|---|---|---|
| 混插不同容量 | 优秀 | 浪费严重 |
| 渐进式扩容 | 支持，自动化 | 手动，痛苦 |
| 性能 | 略低于同等 RAID 5 | 略优 |
| 通用性 | 群晖专属，锁死平台 | 通用，换系统还能认 |
| 故障后取数 | 只能在群晖设备里读 | Linux mdadm 也能识别 |
最后一行是选 SHR 必须接受的代价：你的数据被绑定在群晖生态上。将来想把硬盘拔下来插到别的品牌 NAS，或者拿到 Ubuntu 上抢救，SHR 卷没人认（虽然底层是 mdadm + LVM，理论上能救，但过程绝非小白友好）。
如果你明确”这辈子就群晖”，SHR 是明显更优的选择。如果你在意数据的平台独立性，那就老实选 RAID 5/6，代价是容量利用率和扩容体验。
上手清单
- 新机器初始化，盘位 ≥ 2 且未来可能加盘 → 无脑 SHR
- 数据重要且盘位多 → 认真评估 SHR-2
- 组好后立刻在存储管理器里看清楚”存储池→空间→已保护”状态
- 打开存储空间使用率告警阈值（默认 80% 提示偏晚，可以调整）
- 定期做数据完整性检查，建议启用计划（按月或季度）
- 无论用哪种 RAID，HB 备份必须另外配
