nuc-seed.md -> nas-seed.md. The leg was designed around nuc's USB pool, which is exactly the device it must not depend on. Target pool ks4backup now lives on tank; nas becomes WG peer 10.8.0.22 and nuc's tunnel retires once seeded — nuc no longer needs one at all, since transmission-bt (the only other user) moved to nas with its own in-container tunnel. ks4 needs no change: traffic arrives masqueraded as the wireguard container whichever peer sent it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.5 KiB
3.5 KiB
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
ks4backupis now backed bytank/backup/ks4on nas. - The WireGuard tunnel moves too: nas becomes peer
10.8.0.22; nuc'swg-ks4(10.8.0.20) is retired once this works. nuc no longer needs a tunnel at all —transmission-bt, its only other user, now runs on nas and carries its own in-container tunnel (10.8.0.21, unchanged, ks4 needs no edit for it). - ks4's ufw rule is unchanged: traffic arrives masqueraded as the
wireguardcontainer (192.168.1.18) whichever peer sent it.
Prerequisites
tankrunning 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 and retire nuc's tunnel:
# on nuc
systemctl disable --now wg-quick@wg-ks4 && rm /etc/wireguard/wg-ks4.conf
# on ks4
incus exec wireguard -- wg set wg0 peer <nuc-pubkey> remove
incus exec wireguard -- wg-quick save wg0