Review Borg file-cache safety before switching from ctime to mtime

Evaluate change-detection correctness alongside speed before weakening Borg cache comparisons.

Source facts

Borg 1.4.5 uses cached file metadata to avoid reprocessing unchanged files. Its default cache comparison includes ctime, size, and inode. Inode values may be unstable on some network filesystems, reducing cache effectiveness; omitting inode can improve speed but reduce change-detection reliability. The documentation also contrasts ctime with mtime: users can reset mtime after content changes, which can mislead mtime-based cache comparisons. A metadata-only change can conversely advance ctime and cause extra processing.

Source: Borg 1.4.5 — borg create.

Applicability

This applies to Borg 1.4.5 backup-creation cache modes. It addresses the reliability tradeoff in avoiding rereads, not a universal performance recommendation for every filesystem or backup workload.

DSE recommendation

DSE recommends documenting the observed cache problem before changing comparison fields. Record the source filesystem’s behavior and evaluate whether apparent slowness is expected metadata churn or unstable identifiers. Have the backup owner approve any reduced detection guarantees. Preserve a known conservative comparison in the rehearsal so faster operation can be evaluated against content correctness. Avoid treating a short backup duration as proof of improvement when fewer files may simply have been reread under a weaker comparison.

Verification

Use disposable files to compare the proposed and existing modes, including metadata-only changes and content changes followed by restored modification times. Inspect restored content, not just archive statistics. Retain both the performance observations and any missed or unnecessarily reprocessed changes before selecting the production mode.

Official reference

Borg 1.4.5 — borg create. Reviewed October 15, 2026.