rsnapshot — hardlinked version history of immich and EmbeddedEra on disk1¶
Hourly hardlink snapshots (24 h / 30 d / 12 w / 24 m / 5 y) of the two irreplaceable trees into /mnt/disk1/Storage-snapshots/. 129 GB total; hourly churn is ~zero bytes because it hardlinks perfectly.
Input → Movement → Output¶
Reads /mnt/storage/EmbeddedEra/ and /mnt/storage/immich/ (excluding immich/postgres/, immich/thumbs/, *.db-shm, *.db-wal). Produces hourly.0…23, daily.0…29, etc. under the snapshot root.
Why this shape¶
Parity and the NVMe copy protect against loss; neither protects against an edit or a deletion that then propagates. Snapshots do. They live on an array disk, so they do not survive disk1 — which is why the versioned history moved to the parity-protected restic repo on 2026-09-08 (history-repo). rsnapshot stays for now; once the repo has a few weeks of depth, cut retain hourly 24 to 6 and reclaim most of the 133 G.
Steps¶
/etc/cron.d/rsnapshotruns/usr/bin/rsnapshot <interval>as root.- Config
/etc/rsnapshot.conf:snapshot_root /mnt/disk1/Storage-snapshots/; retains above; twobackuplines. /usr/local/bin/rsnapshot-safe-rmexists as a guarded remover for the tree.
Consequences to know: disk1 carries 3.66 million inodes because of this forest — never tune2fs -c a forced boot fsck onto it; snapraid touch and scans on d1 take minutes. /Storage-snapshots/ is excluded from parity; the compose samba (ghost) points at the pool path, the live samba-nas serves it read/write from /mnt/disk1/…. Stale Storage-snapshots/ dirs also exist on disk2 and disk3 (~50 GB, dead since January) — reclaimable.
If you change this¶
- Hits: disk1 inode count and scan time · Samba share · the two
excludelines that keep DB WAL files out. - Does not hit: parity (excluded), precious, the rescue kit.