\n```\n\n这个命令挂在 cron 里每月跑一次,时间选凌晨,那时候没人访问这些盘,校验本身要全盘读一遍,会占用磁盘 IO:\n\n```\n0 4 1 * * cd /mnt/photos && sha256sum -c checksums-2026.sha256 | grep -v ': OK
>> /var/log/bitrot.log 2>&1\n```\n\n一点五 TB 的库,机械硬盘全盘读一遍的速度大概每秒一百兆上下,跑一次要四五个小时,正好一夜。第一次生成清单那晚跑了快六个小时,因为有些盘已经比较满,读得慢。之后每月校验一次,半夜自动跑,早上起来翻一眼日志有没有 FAILED 就行。\n\n校验只能发现问题,不能修复。真校验出文件坏了,靠的是另一份备份。所以这条铁律其实是和备份配套的:备份要定期验证能恢复,校验要定期跑能发现损坏,两者缺一个都不完整。我自己就经历过校验报了几个 FAILED,翻备份发现备份盘上同样位置的几个文件也是坏的——因为是同一批从旧盘拷贝过来的,源文件就已经坏了,拷的时候没发现,等于坏数据被复制到了所有副本。这种时候哈希校验也没用,因为所有副本都一样\"坏\"。要提前发现,只能靠更早的快照。\n\n哈希清单本身也有时效问题。我的库是只读的,所以一份清单能管很久。如果你的库会持续往里加文件,那每次加完文件都要更新清单,不然新文件没有对应条目,等于没保护。我后来写了个小脚本,新照片入库跑一遍归档流程,顺手把校验清单也更新了,让新文件和清单保持同步。\n\n另一条路是用自带校验的文件系统。如果数据放在 ZFS 或者 btrfs 上,文件系统自己在后台做校验,还能自动修复,不用我手动跑哈希。我主力盘还是 ext4,所以只能用脚本方案。换文件系统要迁移数据,成本高,短期不打算动,哈希脚本先用着,至少能把静默损坏这件事从\"完全无感\"变成\"可发现\"。\n\n跑校验之前我在 find 里排除掉几个不用管的目录,比如正在写入的下载目录和临时目录,不然每次校验都报 FAILED,假警报一多,真出问题反而麻木了。校验清单文件本身我也没放在被校验的盘上,而是放到另一块盘,防止清单和数据一起坏,那就完全没有参照物了。真校验出坏的少数几个文件,我的处理是从另一份正常副本里拷回来覆盖,所以前面说的双备份这时候就是救命稻草,光有校验没有副本,发现坏了也只能干瞪眼。\n\n对特别重要的单个大文件,比如打包好的备份压缩包,我还会额外生成 par2 修复文件。par2 是给文件加冗余的格式,不仅能发现损坏,还能在损坏比例不大时自动修复回来:\n\n```\npar2 create -r5 archive.7z\n```\n\n-r5 表示加百分之五的冗余,能修复不超过百分之五的损坏。这个对放在网盘上的压缩包特别有用,网盘偶尔会抽风把文件弄坏一点,下载回来用 par2 修复,比重新上传下载整包省事。这套组合拳下来:普通文件靠 sha256 清单按月校验,重要压缩包额外加 par2 冗余,备份盘定期做恢复演练,静默损坏这事的风险算是压到能接受的范围了。","is_owner":false,"date":"2026/9/2","category":"系统运维"}