Skip to content

SnapRAID array — d1 d2 d3 + one parity, snapshot parity, not live RAID

Survives exactly one disk failure. Parity is recomputed nightly; anything written after 03:30 is unprotected until the next sync. Nothing user-facing ever reads the parity disk.

Why this shape

Offline parity on plain ext4 disks: each disk is independently mountable, a failure loses at most one disk's files, and the parity drive can sleep 23 h a day. The cost is the sync window and the guard rituals around it.

Shape

/etc/snapraid.conf (SnapRAID 12.3): - parity /mnt/parity/snapraid.parity (2.308 TiB file; cannot be truncated on 12.3) - content × 4: /mnt/disk1, /mnt/disk2, /mnt/disk3, /var/snapraid/ (NVMe — survives a cage/HBA failure) - data d1 /mnt/disk1 · d2 /mnt/disk2 · d3 /mnt/disk3 - autosave 100 (checkpoint every 100 GB; no UPS) - excludes: *.tmp *.partial *.db *.sqlite* *.log, docker/ appdata/ cache/ tmp/, /Storage-snapshots/, /downloads/, /docker-backups/ (493 parity errors a night when it was inside), /recovered-esd-backups/, /recovered-docker-backup/ (1.2M stale files, excluded 09-03)

State (09-08): 45,297 files · 41 hardlinks · No error detected · 25 % unscrubbed, oldest block 44 d, median 9 d · 7 .unrecoverable stubs, all on d1 (six 0-byte .nfo, one 18 GB movie whose byte-identical twin still seeds on d1).

Connected to

  • owns: the four content files; the parity file
  • owned-by: disks
  • joins: mergerfs-pool (same three data disks, read through the pool by everything else)
  • looks-like-but-is-not: snapraid-webui/ config dir in torrentvpn — no running container; ghost.

If you change this

  • Hits: processes/snapraid-sync and snapraid-scrub (they read this file) · the rescue kit host/snapraid.conf + host/snapraid.content (rebuilt nightly) · the precheck's DEL_LIMIT=500 / UPD_LIMIT=2000 if you add or remove a large tree — run snapraid diff first and read the numbers.
  • Does not hit: mergerfs, containers, Plex — none of them know parity exists.

Rules

  • Never a bare snapraid sync; use sr or systemctl start snapraid-sync (the guard runs the precheck).
  • After any disk event: snapraid status first; sync only when it reads clean. A sync against a missing disk writes the loss into parity.
  • snapraid check compares against hashes from the last sync — sync immediately before a check or every .nfo the *arrs rewrote reads as "Data error" (that is what the 09-03 drill found: 30 errors, all sidecars).
  • snapraid -C host/snapraid.content regenerates a lost snapraid.conf.

Surfaces

Surface Role
root via timers sync 03:30 daily, scrub Sun 04:00
sudo -n snapraid status currently NOPASSWD for angel (see host/sudo-and-tools)
logs /var/log/snapraid/{sync,scrub}-YYYYMMDD.log; sync-manual-20260903.log is the 1.2M-file exclusion sync

See

  • Source: /etc/snapraid.conf · /etc/systemd/system/snapraid-*.service (+ .d/override.conf, .d/alert.conf)