All bulk storage lives on hpve as ZFS pools. This page is the authoritative map of what’s on each pool and, more importantly, what has a second copy and what doesn’t. Last verified 2026-07-27.
| Pool | Raw | Redundancy | Used | Role |
|---|---|---|---|---|
| Biggest | 18.2 T | mirror (survives 1 disk) | 81% | Backup/archive target — holds nvmepool-backup, Kiwix, Loki, Maple, archive |
| mediapool2 | 18.2 T | RAIDZ1 (survives 1 disk) | 54% | Primary movies + TV (Plex library). 5×4 TB, Thunderbolt enclosure |
| nvmepool | 10.9 T | stripe — NO redundancy | 75% | Primary working data: music, photos, ingest, Sync replica, CT100 disk, GIS |
| backups | 464 G | single disk | 29% | Proxmox vzdump VM/CT backups + ISOs |
| mediapool | 10.9 T | RAIDZ1 | ~0% (empty, ~7.1 TB usable) | Spare/free — leftover from the 2026-06-01 cutover |
mediapool2 (primary video)
movies— 6.68 TB (Radarr)tv— 1.30 TB (Sonarr)- Auto-snapshots disabled 2026-07-27 (
com.sun:auto-snapshot=false) after 204 stale snapshots were pinning ~4.8 TB. Pool dropped 81% → 54%.
nvmepool (fast working storage)
music1.82 TB ·photos1.56 TB (Immich) ·ingest2.81 TB (seedbox landing / staging) ·sync1.33 TB (server-side Syncthing replica of~/Sync) ·container-data267 GB ·vms293 GB (CT100 disk = 287 GB) ·gis12 GB · plusbooks,audiobookshelf,bookshelf,video,courses,podcasts
Biggest (backup/archive)
nvmepool-backup— nightly rsync of nvmepool data ·Kiwix(ZIM offline wikis) ·loki(log store) ·Maple·archive·backups
backups — Proxmox vzdump dumps + install ISOs.
mediapool — empty; ~7.1 TB usable available for reuse.
| Data | Primary | Backup | Status |
|---|---|---|---|
| Photos, Music, GIS, Books, Sync, container-data | nvmepool | Biggest/nvmepool-backup (nightly rsync) |
✅ Covered |
| Proxmox VM/CT config & disks | (each pool) | backups pool (vzdump) |
✅ Covered |
| Movies + TV | mediapool2 | none | ⚠️ Single copy — accepted risk |
Seedbox ingest (staging) |
nvmepool | none | — Transient by design |
| Anything | (on-box) | offsite | ⚠️ No offsite backup |
The one deliberate gap: the movie/TV library on mediapool2 has no second copy. RAIDZ1 survives exactly one disk failure; a second disk, a pool-level fault, or accidental deletion loses it. Ed reviewed this on 2026-07-27 and accepted the risk rather than replicate (the media is large and largely re-acquirable, though some back-catalogue is no longer available on current indexers). The idle mediapool (~7.1 TB usable) could hold a movies replica if that ever changes.
Second gap: nvmepool has no ZFS-level redundancy (it’s a stripe). Its protection is entirely the nightly rsync to Biggest — so a nvmepool disk failure means restoring from Biggest with up to ~24 h of changes lost, not zero-loss. Fine for its content (working/reproducible data), but worth knowing.
- Keep pools under ~80% full. ZFS (copy-on-write) shifts to a slower space-conserving allocator past ~80% and fragmentation accelerates. Biggest (81%) and nvmepool (75%) are the ones to watch.
- Do NOT defragment — SSDs gain nothing from it and ZFS has no defrag tool.
frag%is free-space fragmentation; the lever is free capacity, not a defrag pass. TRIM (autotrim/zpool trim) is the relevant SSD maintenance. - Scrubs run monthly (see Proxmox page); all pools last scrubbed clean (0 errors) in July 2026.
- Snapshots:
zfs-auto-snapshotruns on most datasets. It was disabled on mediapool2 (media doesn’t need point-in-time rollback and the snapshots were silently hoarding space). Checkzfs list -o name,usedbysnapshotsif a pool’s “used” looks larger than its file contents.