Because the job that wrote it can fail quietly. pg_dump … | gzip without pipefail reports gzip's exit code. The destination can fill up mid-write and still leave a file that looks "big enough." Incremental tools can finish a short night and still exit 0. In every one of those cases, last night's file exists, is recent, and is smaller than Tuesday's.
A single-run check that only asks "did it exit 0 and clear a size floor?" will call that night verified. Comparing nights is what makes the shrink visible.
backup-evidence record — one file per night.backup-evidence check runs/*.json --trend.Retention pruning, a restic/borg rewrite, and a dataset that actually got smaller will drop bytes on purpose. The checker reports the drop. You decide whether it matches the work you did.
A scheduled backup can exit 0 while writing a truncated or incomplete artifact that still clears a minimum-size check. Compare consecutive nights' sizes. A drop of 20% or more versus the previous night or the prior-night median is a reason to inspect the job, even if the latest run is marked verified.
No. Retention pruning, incremental repositories, and a genuinely smaller dataset can shrink an artifact on purpose. A size drop is an observation. Test a restore before treating any night as safe.