这类问题我又碰上了一次。Ubuntu 22.04 上用 borg 1.2 备 800G 图库,第一次跑了六小时,之后每次都还是五六小时,borg create –stats 输出的 deduplicated size 很小,读盘量却和首次一样。
排查方向其实有限,先把可能性排一排。BORG_CACHE_DIR 没固定,默认落在用户家目录,备份脚本用 sudo 跑时换了个用户,缓存等于没有;files-cache 用 ctime,size,而源目录每天被 rsync 同步一遍,ctime 全变导致块索引失效;仓库放在 NFS 上,缓存文件读写慢,chunk 索引每次重建都要几十分钟。
动手时先确认缓存目录落在哪
du -sh ${BORG_CACHE_DIR:-~/.cache/borg}
接着把仓库和缓存都写死在脚本里
export BORG_REPO=/backup/repo BORG_CACHE_DIR=/var/cache/borg
然后改用 mtime 判断文件变化
borg create --files-cache=mtime,size,rechunkify=no ::{now} /data
末了清理旧归档避免仓库无限长
borg prune --keep-daily 7 --keep-weekly 4
手上没有现成的复现脚本,就照着线上请求手工拼了一个。
改完先别撤,确认这几项。第二次 borg create 的耗时降到半小时内,–stats 里 chunk index 复用、deduplicated size 接近零,borg list 能看到当天归档。
提醒一点。borg 每次仍会 stat 全部文件,扫描时间省不掉,省的是读数据和算块;把缓存放 tmpfs 上看着快,一重启就白丢。报错文案容易误导,真正的原因往往在相邻那一层的日志里。
