数据完整性格斗技：家庭 NAS 维护日历

ZFS 吸引我的不是「文件系统很潮」，而是校验和加快照这套组合拳：静默损坏能被发现，误删有机会回滚。下面按维护日历写——哪天做什么、看到什么信号该升级处理，而不是又一篇命令速查。

每月第一个周日：Scrub 体检日

zpool scrub tank
zpool status tank

习惯每月一次全池 scrub，安排在低峰；它会吃 IO，别和全盘备份、媒体库刮削撞车。日历提醒只写「开 scrub」，真正重要的是结束后读 zpool status：有无 checksum 错误、是否 in progress 卡住过久、磁盘是否 already offlined。

发现 checksum 错误，进入换盘或修复评估，而不是清日志假装没看见。mirror 或 raidz 仍有冗余时按文档 replace；冗余已损要先保证备份可读再动刀。scrub 不是备份，它只回答「池子现在读起来是否自洽」。若 scrub 耗时突然比上月长一倍，也记一笔：可能是池更满、盘开始吃力，或同时有别的重 IO——相关，不必然是故障，但值得纳入观察。

每周：扫一眼快照与空间

重要 dataset：每小时 / 每天 / 每周分层保留；媒体库：每天、保留短。可用 sanoid 或简单 cron。命名带日期和原因，例如 @before-immich-upgrade；人工快照别留一堆忘删的 snap1 snap2。

每周看一次：

zfs list -o space,name
zfs list -t snapshot

空间「删了文件还是满」，多半是快照仍引用旧数据块。df 不会按你的直觉立刻下降。理解引用关系再清理过期快照；盲目在数据集里 rm 解决不了快照占用。日历上可标「快照修剪日」，与应用大版本升级日对齐——升级前手动打命名快照，升级后观察一周再纳入自动过期。

每季度：快照边界复习 + send/recv 抽查

同池快照防误删、防勒索软件未扩散前的回滚。防不了整机箱故障，防不了池配置级灾难。 请继续 restic 异地，或 zfs send | zfs recv 到另一台机器。每季度做一次增量 send 抽查：接收端磁盘是否仍够、增量是否报错、接收侧能否只读挂载抽查文件。

首次全量耗时长，增量很快。复制不等于关闭源池快照策略——两边保留策略分开想。接收端也是「另一份可能坏的盘」，不能替代异地加密备份的语义；它解决的是「池没了，最近快照链还在另一台」。抽查时随机打开几个真实文件做校验，比只看 zfs list 更踏实；曾遇到增量显示成功、个别大文件却在接收侧读失败的边缘情况，根因是中途网络闪断后重跑策略不完整。

随时：升级与高危操作前的闸门

改压缩、改 recordsize、迁数据集、大版本应用升级：操作前命名快照，操作后在日历记一笔「谁做的、为何」。高危操作清单贴在机柜或笔记置顶：destroy 数据集前二次确认名称；不要在错误的池上实验。误操作的回滚窗口，取决于你还有没有未过期的快照——日历上的保留策略，就是你的撤销键寿命。

年度：策略是否还匹配数据

一年后数据画像会变：相册暴增、监控录像加入、虚拟机镜像变大。重估哪些 dataset 值得密快照、哪些只保留短；scrub 频率是否仍合理；异地备份是否覆盖「快照以为安全其实同站点」的盲区。媒体库若已另有对象存储副本，本地快照可以更短；文档与数据库则相反。

数据完整性是马拉松：scrub 是体检，快照是撤销键，异地备份才是保险柜。维护日历的意义，是把这三件事从「想起来才做」变成「到点就会做」。我把 scrub 结果摘要、快照占用异常、send 抽查是否通过，记在同一本运维笔记里，半年翻一次比只看监控绿点有用——绿点说明现在能 ping，笔记说明你是否真的在管理风险。

和休息日绑定的检查清单

我把 ZFS 维护钉在日历上，而不是「想起来再说」：

• 每月第一个周日：看上次 scrub 是否完成、有无 checksum 错误邮件
• 每季度：挑一个次要 dataset 做一次 rollback 到测试克隆，确认快照真能用
• 换盘或扩容前：手动 zpool scrub 一次，确认池健康再动刀

快照命名带日期和原因，例如 manual-2026-02-01-before-immich-upgrade。自动快照很多时，手工标签能在慌乱中救命。空间报警阈值我设在 80%：ZFS 在很满时性能与碎片会变难看，留余量比「用满每一 TB」重要。