Julien LutranandClaude Opus 5
4c6396a8fa
The plan gated nuc's tunnel teardown on the nas leg being seeded, on the assumption nuc stayed a viable fallback target. It is not one: its ks4backup pool was deleted when the disk moved, and its data pool is a 512 GB SSD against a ~1.75 TiB replica set. So the tunnel was doing nothing except re-establishing a keepalive'd link to ks4 on every boot of a machine that is now powered off between uses. Disabled 2026-08-31 (wg-quick@wg-ks4 disabled, interface down, ks4 incus remote removed from nuc). The config and key are deliberately kept, so it is one systemctl away if ever needed — deleting them would mean regenerating keys and re-peering on ks4. transmission-bt is unaffected: its tunnel is in-container and a separate peer (10.8.0.21), verified still handshaking with egress 193.70.35.17. Remaining: drop nuc's now-unused peer on ks4's wireguard container. Harmless to leave, safe to do any time, recorded with the pubkey. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
111 lines
4.4 KiB
Markdown
111 lines
4.4 KiB
Markdown
# 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](../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](../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)
|
|
|
|
```sh
|
|
# 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
|
|
|
|
```sh
|
|
# 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](../ks4/local-backup-cron.md).
|
|
- 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:
|
|
|
|
```cron
|
|
0 5 * * * /root/scripts/incus-copy.sh -r ks4 -s ks4backup >> /var/log/incus-copy-ks4.log 2>&1
|
|
```
|
|
|
|
## Verification (release gate for ks2)
|
|
|
|
```sh
|
|
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](plan.md).
|
|
|
|
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:
|
|
|
|
```sh
|
|
# 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.
|