别等到硬盘红灯才后悔：Homelab 存储不够用的真实信号
上周在 r/homelab 上看到一个帖子，有人问“How to know when your storage is not enough?”。底下回复挺有意思，有人直接怼：“Have you really seen two drives fell at once? I think you’re exaggerating a bit there. Your available space has nothing to do with redundancy.”
这哥们儿说得对，但也不全对。我玩了五年 homelab，踩过的坑比吃过的盐还多。今天不扯虚的，直接上干货——怎么在数据还没丢之前，就意识到存储快撑不住了。
存储告急的六个真实信号
1. 监控面板开始报警，但你忽略了
Zabbix 或 Prometheus 默认的磁盘告警阈值通常是 80% 和 90%。很多人看到告警第一反应是“点掉”，然后继续跑。直到某天写数据失败，才意识到问题。
我去年犯过这错。一台 4TB 的 NAS 卷，用了 85% 时我看见了，但想着“下周再清理”。结果一周后跑了三个 VM 的备份，直接撑爆。恢复花了整整两天。
正确做法：把告警阈值调到 70% 和 85%。70% 是预警，85% 是行动线。别等 90% 再动手，那时候已经没余量了。
2. ZFS 的 ARC 命中率开始下降
如果你用 ZFS（应该用），ARC 命中率是个关键指标。当存储接近满时，ZFS 的写性能会显著下降。我见过一个案例，某人的 ZFS 池用到 92%，ARC 命中率从 95% 直接掉到 78%。写入速度从 200MB/s 掉到 40MB/s。
检查命令：
arc_summary | grep "hit ratio"
如果命中率低于 85%，且你的池使用率超过 80%，那就是扩容信号。
3. 快照和备份开始失败
这是最容易被忽视的信号。很多人的备份策略是“每天增量，每周全量”。当磁盘空间不足时，增量备份可能还能跑，但全量备份会失败。
我见过一个兄弟在 r/homelab 上发帖，说他的 Proxmox 备份连续失败三天，他没在意。第四天一个 VM 的磁盘挂了，他才知道备份根本没跑成功。
检查频率：每周至少检查一次备份日志。别等到恢复的时候才发现备份是空壳。
4. SSD 的写入寿命快到了
NVMe SSD 有写入寿命限制。比如三星 980 Pro 2TB 的 TBW 是 1200TB。对于日志写入频繁的系统，这个数字可能三年就耗尽了。
检查方法（Linux）：
sudo smartctl -a /dev/nvme0 | grep -i "percentage_used"
如果百分比超过 90%，赶紧换盘。别赌它还能撑多久。
5. Docker 的 overlay2 分区满了
这是 homelab 最常见的翻车点。Docker 默认把数据放在 /var/lib/docker。很多人给根分区只分了 50GB，跑几个容器日志就能撑爆。
症状：容器突然无法启动，docker logs 报错“no space left on device”。但 df -h 显示主分区还有空间——因为 Docker 用的是 overlay2 的 inode，不是容量。
检查命令：
df -i /var/lib/docker
如果 inode 使用率超过 80%，你就该迁移 Docker 数据目录或者扩容了。
6. 你的“可用空间”和“冗余”被混淆了
回到开头那个红迪回复。他说“available space has nothing to do with redundancy”。这话在技术层面是对的，但在运营层面是错的。
我见过太多人把 RAID5 的 4TB 盘组当成 4TB 可用空间。你确实有 4TB 可用，但一旦坏一块盘，重建期间你的性能会暴跌，而且第二块盘随时可能跟着挂。
真实案例：r/homelab 上有人用 4x4TB RAID5，用了 3.2TB。一块盘挂了，重建到 60% 时另一块盘也挂了。数据全丢。这不是夸张，这是概率问题。
存储扩容决策表
| 指标 | 正常区间 | 预警区间 | 行动区间 |
|---|---|---|---|
| 磁盘使用率 | < 60% | 60-80% | > 80% |
| ZFS ARC 命中率 | > 90% | 85-90% | < 85% |
| SSD 寿命 | < 70% | 70-90% | > 90% |
| inode 使用率 | < 60% | 60-80% | > 80% |
| 备份成功率 | 100% | 连续 2 次失败 | 连续 3 次失败 |
| RAID 重建时间 | < 24h | 24-48h | > 48h |
扩容方案实战
方案 A：热扩容（不停机）
适用于 ZFS 和 Btrfs。如果你用的是 ZFS，加盘很简单：
# 添加一个 vdev 到现有池
zpool add tank /dev/sdc
# 或者替换现有盘为更大容量
zpool replace tank /dev/sdb /dev/sdd
注意：ZFS 的 vdev 类型必须一致。别在 mirror 池里混进一个 single disk。
方案 B：冷迁移（停机）
适用于老旧的 ext4/xfs 系统。步骤：
- 挂载新存储
- rsync 数据
- 修改 fstab
- 重启验证
我的经验：冷迁移虽然麻烦，但比热扩容更可靠。去年我迁移一个 8TB 的 NFS 存储，rsync 跑了 14 小时，但迁移后零问题。
方案 C：分层存储
如果你预算有限，别买大容量 SSD。用 SSD 做缓存，HDD 做冷存储。
LVM cache 配置示例：
# 创建缓存池
lvcreate -L 100G -n cachepool myvg /dev/sdb
lvcreate -L 10G -n cachemeta myvg /dev/sdb
# 将缓存附加到慢速卷
lvconvert --type cache --cachepool myvg/cachepool myvg/slowvol
红迪社区的真实教训
我在 r/homelab 和 r/HomeDataCenter 上收集了一些典型翻车案例：
“My Homelab Did It Again…”：有人靠 homelab 经验找到了 IT 工作，但他的存储配置是单盘无备份。他说“I was able to bring up my homelab in all 3 interviews”——面试时是加分项，但数据丢了谁也救不了。
“What’s the most expensive homelab mistake…”：最高赞回答是“buying a single large HDD instead of multiple smaller ones in RAID”。单盘 18TB 看起来很爽，但坏了就是 18TB 全丢。
“Rebuilding my homelab definitely would have been cheaper.”：有人花了 3000 刀升级存储，结果发现根本用不完。他说“I should have started small and scaled up.”
FAQ
问：Homelab 需要多少存储空间？
至少 1TB 作为起步。如果你跑多个 VM 和容器，2TB 是更安全的起点。预算允许的话，NVMe SSD 做系统盘，HDD 做冷存储。
问：16GB 内存够跑 Homelab 吗？
16GB 是底线，不是推荐值。跑 3-5 个 VM 时，32GB 才够用。每个 VM 需要预留内存，不像容器可以共享。
问：应该留多少空闲空间？
至少留 20%。对于 ZFS，建议留 25-30% 以保证性能。别把磁盘塞到 95% 以上，那样性能会断崖式下降。
问：为什么会提示空间不足但实际上还有空间？
最常见的原因是 inode 耗尽。Docker 的 overlay2 文件系统会消耗大量 inode，尤其是跑了很多容器的情况下。用 df -i 检查。
总结
存储扩容不是技术问题，是意识问题。别等到告警响了再动手。70% 使用率就该规划，80% 就该行动，90% 已经晚了。
记住红迪上那个老哥说的：“Your available space has nothing to do with redundancy.”——可用空间和冗余是两码事。你有 10TB 空余，但没备份，那 10TB 随时可能变成 0。
社区灵感与参考 (References & Community Insights)
本文探讨的架构演进与技术实现方案，深度提炼自 Hacker News、Reddit 等极客社区的真实工程师讨论、线上事故复盘（Post-mortems）以及一线技术博客的实战经验分享。
