Skip to content

precious — the NVMe copy of the irreplaceable data

/home/angel/precious/: Immich originals + upload + profile + all DB dumps, and EmbeddedEra in full. 21,166 files, 92 GB (09-08). On the root NVMe, so no combination of array-disk failures reaches it. It does not survive the NVMe itself, fire, or theft — that is item 05.

Why this shape

Parity protects against one disk; rsnapshot lives on disk1 (an array disk). Neither survives a two-disk loss or a cage/HBA fault. A copy on the only non-array device closes that gap for the two datasets that cannot be re-downloaded.

Shape

  • Refreshed by /usr/local/bin/precious-sync.sh (angel's crontab, 20 2 * * *; first Sunday of the month 05:00 --verify-full). Log /var/log/precious-sync.log. Own Kuma monitor via PRECIOUS_KUMA_PUSH_URL in /etc/rescue-kit.conf.
  • Guards (precious-sync.sh:98-111): /mnt/storage must be a mountpoint; source trees must exist; source and destination must be different block devices; refuses to run as root.
  • Never --delete: the copy only grows. A deletion is the accident it exists to survive. Prune by hand with --report-extra.
  • Directory↔file flips are moved, not deleted (2026-10-27): when a path changes type at the source (a git branch ref refs/heads/x/ → file x), rsync without --delete fails every night (code 23). displace_type_flips moves the old one to precious/.displaced/<date>/ before each rsync. Prune .displaced/ by hand only. Not --backup: that would keep every overwritten version (~2 GB/day) and fill /. Installed 2026-10-27 12:19 (matches ~/rescue-kit/precious-sync.sh).
  • Motion-photo trap: 13 Samsung assets have their only original under encoded-video/. The script re-derives that list from the Immich DB every run rather than hard-coding it (precious-sync.sh:14-16).
  • precious/RESTORE.txt — the restore procedure. Two gotchas recorded there: the Postgres superuser is immich, not postgres; the cluster dump's role statements error harmlessly on a fresh instance.
  • Verified 09-02 four ways: rsync exit 0; full sha256 manifests both sides (0 mismatches); 40-file random sample; every one of 8,039 DB rows re-resolved against the copy.

Connected to

  • owns: nothing; it is a copy
  • owned-by: datasets
  • joins: history-repo (copy 3 — the versioned one), containers/immich (reads the DB for the motion-photo list; needs immich-postgres up), automation/alerting
  • looks-like-but-is-not: the rescue USB (configs, not data); Storage-snapshots (on an array disk).

If you change this

  • Hits: free space on / (248 GB free; the copy is 92 GB and only grows) · the monthly --verify-full window (reads every byte) · ~/.claude/projects and anything else on the NVMe competes for the same 468 GB.
  • Does not hit: parity, rsnapshot, the array.

Surfaces

Surface Role
angel crontab 02:20 nightly; 05:00 first-Sunday full verify
Uptime Kuma heartbeat "Precious"

See

  • Source: /usr/local/bin/precious-sync.sh · /home/angel/precious/RESTORE.txt · ~/rescue-kit/precious-sync.sh (the source copy)

backups/ no longer copied (2026-10-25, owner)

precious-sync.sh excludes EmbeddedEra/backups/ (rsync, verify list, byte count and headroom du all agree). Those rotating erp/store sets piled up here forever (66 vs 42 at the source, ~0.35 GB/day) and filled /. They are copies of data that lives on this NVMe (docker volumes), with the pool + R2 as other copies. The ~11 GB of sets already here stay until pruned by hand. immich/backups is still copied (RESTORE.txt needs the newest dump) and also accumulates (64 vs 14, 3.8 GB). Source edited in ~/rescue-kit/precious-sync.sh; /usr/local/bin copy installed by the owner (! sudo install).

Pruned 2026-10-25 (owner-approved, #336)

EmbeddedEra/backups/ removed entirely (sets on the pool; the 25 older ones verified in restic). immich/backups pruned 64→20: kept the 14 that match the pool plus 6 Aug 20–25 dumps that predate restic (only copy). Rule for the next prune: delete only what restic find or the pool also holds.