doc/ks2/nas-seed.md

ks4 pull leg — seed after FTTH

Status: prepared, waiting on the FTTH link.

⚠️ Changed 2026-08-30: this leg lands on nas, not on nuc. It was originally designed for nuc's USB pool usb4t, but that pool proved to be the least reliable device in the setup (nuc/usb4t-dropouts.md) — which is exactly what an off-site copy of ks4 must not be. The 4 TB disk moved to direct SATA on the new host nas (192.168.0.4, nas/nas-install.md), and the target pool ks4backup moved with it.

Consequences versus the original plan:

• Target pool ks4backup is now backed by tank/backup/ks4 on nas.
• The WireGuard tunnel moves too: nas becomes peer 10.8.0.22. transmission-bt, the only other user, moved to nas and carries its own in-container tunnel (10.8.0.21, unchanged — ks4 needs no edit for it).
• ⚠️ nuc's wg-ks4 was already disabled on 2026-08-31, before the seed, not after. The original plan retired it only once nas was seeded, on the assumption nuc could serve as a fallback target — it cannot: its ks4backup pool was deleted and its data pool is a 512 GB SSD, far too small for the ~1.75 TiB replica set. Keeping a keepalive'd tunnel alive on a machine that is now powered off between uses bought nothing. wg-quick@wg-ks4 is disabled, and the ks4 incus remote was removed from nuc. /etc/wireguard/wg-ks4.conf and its key are kept, so it is one systemctl enable --now wg-quick@wg-ks4 away if ever needed.
• ks4's ufw rule is unchanged: traffic arrives masqueraded as the wireguard container (192.168.1.18) whichever peer sent it.

Prerequisites

• tank running on SATA for ≥ 7 days with zero pool suspensions — the gate that replaces "fix the USB enclosure"
• FTTH up (the first pass moves ~1.75 TiB)

Setup (root on nas)

# 1. peer nas on ks4's wireguard container
#    (run on ks4) — <nas-pubkey> from /etc/wireguard/wg-ks4.key on nas
incus exec wireguard -- wg set wg0 peer <nas-pubkey> allowed-ips 10.8.0.22/32
incus exec wireguard -- wg-quick save wg0

# 2. tunnel on nas: /etc/wireguard/wg-ks4.conf, modelled on nuc's
#    Address = 10.8.0.22/32, peer pubkey TVs6d7…,
#    Endpoint = 193.70.35.17:51845,
#    AllowedIPs = 10.8.0.0/24, 192.168.1.1/32, keepalive 25
systemctl enable --now wg-quick@wg-ks4

# 3. incus remote over the tunnel
incus remote add ks4 https://192.168.1.1:8443 --accept-certificate --token '…'
incus list ks4: | head          # sanity: remote reachable

Seed

# full pull of every ks4 instance into pool ks4backup (tmux — first pass
# moves ~1.75 TiB 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 (the script does this) — they must never come up on the LAN with ks4's proxy devices.

Cron (after the seed)

Add to nas's root crontab, offset from the 03:30 nuc→nas push, the 04:00 nas→nuc push 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 -c ns -f csv         # all ks4 instances present
# test-restore one instance: copy a replica to the local pool,
# start it isolated, check the service answers, then delete it
incus copy solar solar-restoretest -s incus
incus start solar-restoretest && incus exec solar-restoretest -- systemctl is-system-running
incus delete -f solar-restoretest

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

Only one piece of nuc's retirement is still outstanding — dropping its now-unused peer on ks4. Harmless to leave (an unused peer costs nothing) and safe to do at any time, since nuc's tunnel is already down:

# on ks4 — nuc's pubkey is 31Tlgloc…
incus exec wireguard -- wg set wg0 peer 31TlglocNJyooDVAO8HWEC0lyCykhbaFIWVWFUCOrmQ= remove
incus exec wireguard -- wg-quick save wg0

Deleting /etc/wireguard/wg-ks4.conf + .key on nuc is deliberately not done: they cost nothing and regenerating keys would mean re-peering on ks4.