sysbak: Gamma (and Beta) 'latest' age is measured from the wrong timestamp

[thompsonson]

What's wrong

sysbak status/doctor report Gamma's "latest" snapshot age using the gamma.0 directory's mtime (get_latest_snapshot_age, dot_local/bin/executable_sysbak):

get_latest_snapshot_age() {
  local latest_dir="$SNAPSHOT_ROOT/${level}.0"
  ...
  epoch=$(get_file_mtime "$latest_dir")   # stat -c '%Y' on the directory
  ...
}

rsnapshot promotes tiers with mv (rename), not a fresh copy — confirmed directly in /var/log/rsnapshot.log on pop-mini for the 2026-09-06 03:00 gamma run:

mv gamma.2/ -> gamma.3/
mv gamma.1/ -> gamma.2/
mv gamma.0/ -> gamma.1/
mv beta.6/  -> gamma.0/

A same-filesystem mv preserves the moved directory's original mtime. So gamma.0's mtime reflects when its underlying data was first captured as beta.0 — up to retain beta rotations earlier (7 days on this config) — not when the gamma rotation actually ran. The result: gamma.0's reported age is always inflated by roughly one full beta-retention cycle, every week, by construction — not a sign of a missed or failing backup.

Concretely on pop-mini: sysbak status showed "Gamma: latest 11d ago", which read as a possible missed weekly run. The actual rsnapshot log shows gamma ran and rotated successfully on schedule 3 days before that check. Beta inherits the same issue one level down (from alpha), just less visibly since alpha's 4-hourly cadence keeps the drift small.

Why this hasn't tripped sysbak warn

get_backup_age_hours (used for the Warnings section / staleness thresholds) walks tiers starting from alpha, so in practice the global staleness check is driven by whichever tier last ran — normally alpha, which genuinely is fresh. So this is a display bug in the per-tier "latest" numbers (status, doctor), not a false negative in the actual stale/critical warning gate. Still worth fixing — it's exactly the kind of number a human glances at and mistakes for "gamma might be broken."

Suggested fix

Read the last successful run per level from /var/log/rsnapshot.log's <level>: completed successfully lines instead of the promoted directory's mtime. That reflects when the rotation actually happened, immune to the mv-preserves-mtime effect. Needs /var/log/rsnapshot.log to stay world-readable (it currently is, 644 root) or a sudo-gated fallback if that's ever tightened.

Evidence

• dot_local/bin/executable_sysbak: get_latest_snapshot_age() (~line 284), get_backup_age_hours() (~line 246)
• /var/log/rsnapshot.log on pop-mini, 2026-09-06T03:00 gamma run
• stat on /media/passport/snapshots/gamma.{0,1,2,3} — mtimes Aug 29 / Aug 21 / Aug 15 / Aug 8, each ~8 days apart, consistent with inherited beta-cycle mtimes rather than gamma's own weekly cadence

Claude-Session: https://claude.ai/code/session_01WDcE2CAYzzJTMY6ubRmt94