RSYNC mode recursively backs up its own previous snapshots when /run isn't excluded

[jamjop]

Originally reported at teejee2008/timeshift#312 (2018) — that repo is now archived/locked so filing fresh here since it's still reproducible on current Timeshift.

Description:
In RSYNC mode, each snapshot run mounts the backup device under /run/timeshift/<pid>/backup/. If /run isn't in the exclude list, the next snapshot run's rsync pass recursively captures that live mount point — meaning it captures all previously retained snapshots nested inside the new one. This compounds every cycle (hourly/daily/weekly/monthly), since each new snapshot re-includes everncmore previous snapshots.

The stock default exclude list does include /run/*, so this doesn't show up out of the box. But it's very easy to silently reintroduce: customizing the exclude list for your own paths (extra mounts, app directories, etc.) without realizing it needs to also preserve the stock /run entry drops this protection with no warning.

Impact observed:
19 retained snapshots (well within configured retention counts — 6 hourly / 4 daily / 3 weekly / 2 monthly / 5 boot, nothing over-retained or abandoned) had ballooned to 561GB, on a system where the actual root filesystem is only ~309GB used. A single snapshot's /var/run (symlinked to /run) alone was 438GB — almost entirely nested copies of earlier snapshots.

Suggested fix:
Since Timeshift already knows its own live mount path for the current run, it could defensively exclude that specific path unconditionally at runtime, rather than relying solely on a default exclude entry that any legitimate user customization can accidentally drop.

Workaround: add /run/*** back to the exclude list explicitly.

[jamjop]

Correction to my own report above, after digging into the actual source: /run/* and /var/run/* are already unconditionally hardcoded into exclude_list_default in Main.vala (confirmed present in both the installed 24.01.1 and current HEAD), and this isn't affected by a user's custom "exclude" entries in timeshift.json — I verified this by reading the code path (load_app_config() only ever populates the separate exclude_list_user, never touches exclude_list_default) and by pulling the actual exclude.list file generated for a real snapshot run — both /run/* and /var/run/* were present and correctly ordered. So my original theory (custom exclude list silently dropping the default) doesn't hold up — apologies for the bad lead.

What I now believe actually happened, based on before/after measurement: I fully deleted all 19 contaminated snapshots and let Timeshift create one fresh snapshot from a clean slate (no --link-dest reference at all, since there was nothing to link against). That single fresh snapshot came out to ~228GB. The old chain of 19 retained snapshots (built incrementally via --link-dest against each predecessor) totaled 561GB — more than double a single full copy, which shouldn't be possible if hardlinking were working cleanly across genuinely unchanged files.

My working theory now: at some point one snapshot in that --link-dest chain got contaminated (root cause still unclear — possibly a transient issue in an older Timeshift version, or something during an early run before this system's current config existed). Every subsequent snapshot in the chain hardlinked forward against its predecessor via --link-dest, which reuses whatever's already there in the reference snapshot — contaminated or not — regardless of whether the current run's exclude patterns are correct. So the bloat would compound and persist indefinitely even after the excludes were technically fine going forward, since --link-dest only re-evaluates new/changed files against the source, not the reference snapshot's own history.

If this theory is right, the practical fix for anyone hitting this isn't (only) checking the exclude list — it's breaking the link-dest chain entirely (full delete + fresh snapshot) once contamination is suspected, since there's no way to "clean" an already-poisoned reference snapshot short of that. Might be worth Timeshift having some kind of periodic sanity check (e.g., comparing total snapshot-set size against expected bounds, or an occasional non-incremental full resync) to catch and self-heal this kind of chain contamination rather than requiring a user to notice via disk-space alarms.