Files
doc/ks2/nas-seed.md
T
Julien LutranandClaude Opus 5 66c7bca28f ks2: ks4 pull leg and its WireGuard tunnel move from nuc to nas
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>
2026-08-30 23:53:30 +02:00

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 ks4backup is now backed by tank/backup/ks4 on nas.
  • The WireGuard tunnel moves too: nas becomes peer 10.8.0.22; nuc's wg-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 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 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