Files
doc/ks2/nas-seed.md
T
Julien LutranandClaude Opus 5 58dcaa5d41 nas: new storage host on A1SAi-2750F — 4 TB off USB onto SATA
Builds the box that ends the usb4t dropouts: the JMicron bridge was the
least reliable device in the setup and it held the intended off-site copy
of ks4. The 4 TB now sits on direct SATA as pool `tank`.

- OS on mdraid RAID1 across two 120 GB SSDs (Intel 330 + Toshiba Q300),
  both ESPs bootable; `incus` ZFS mirror on their tails, ~22% left
  unallocated as over-provisioning
- media at /export/media, exported read-only over NFSv4 to nuc
- transmission-bt moves here (its WireGuard tunnel is in-container, so
  ks4 needed no change) and writes to the dataset locally
- backup pools nucbackup / ks4backup / nasbackup
- monitoring live: msmtp (submission+auth, verified 250), zed with
  NOTIFY_DATA, zpool-health.sh every 15 min, smartd on all three disks

Traps recorded because none of them point at their own cause: booting
with the display active kills the i915 probe and wedges incus; d-i picks
grub-pc vs grub-efi from how the installer booted; `incus storage create`
hangs forever on a mountpoint=none dataset; the BMC is deliberately never
cabled, so there is no out-of-band console.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-30 23:53:30 +02:00

1.7 KiB

nuc pull leg — seed after FTTH

Status: prepared, waiting on the FTTH link. Everything is already configured on nuc (see the main README): incus remote ks4 over the WireGuard tunnel (wg-ks4, 10.8.0.20 → 10.8.0.1), target pool ks4backup on the USB ZFS pool (usb4t/backup/ks4) — only the seed itself waited on bandwidth.

Seed (root on nuc)

# sanity: remote reachable through the tunnel
incus list ks4: | head

# full pull of every ks4 instance into pool ks4backup (screen/tmux —
# first pass moves ~1.7 T through the WG tunnel)
/root/scripts/incus-copy.sh -r ks4 -s ks4backup 2>&1 | tee -a /var/log/incus-copy-ks4.log

Notes:

  • First pass is a full send per instance; later refreshes are ZFS-incremental as long as they run at least every snapshots.expiry (7 d on ks4) — same caveat as ks4's local leg.
  • Replicas arrive stopped with boot.autostart=false (script does this) — they must never come up on the LAN with ks4's proxy devices.

Cron (after the seed)

Add to nuc's root crontab, offset from the 03:30 local nucbackup copy and ks4's own 01:00/05:00 jobs:

0 5 * * * /root/scripts/incus-copy.sh -r ks4 -s ks4backup >> /var/log/incus-copy-ks4.log 2>&1

Verification (release gate for ks2)

incus list --project backup 2>/dev/null || incus list | grep -c .   # all ks4 instances present
# test-restore one instance: copy a replica to the default pool,
# start it isolated, check the service answers, then delete it
incus copy solar solar-restoretest -s default
incus start solar-restoretest && incus exec solar-restoretest -- systemctl is-system-running
incus delete -f solar-restoretest

Once verified, tick the nuc gate in the ks2 plan.