Julien LutranandClaude Opus 5
3c6b762038
ef88ef9 updated the headings but left the body describing the old setup,
so the two docs contradicted each other on the same procedure.
The one that would actually have failed: `incus storage create ks4backup
zfs source=usb4t/backup/ks4` — that pool no longer exists, the disk moved
to nas and the pool was renamed to `tank` on import. Also corrects the
WireGuard peer (nas is 10.8.0.22/32, not nuc's 10.8.0.20/32, which is
retired once nas is seeded), the host for the cron and the restore test,
and drops the "replicas live only on the USB drive" framing — direct SATA
was the entire point of the rebuild.
Adds a pointer to ks2/nas-seed.md as the authoritative seed procedure.
Historical notes (the 2026-08-09 verification, the homeassistant VM
measurement) are left as-is: they are dated observations, not steps.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>Prod: ks4
Incus host at OVH — public-facing self-hosted services.
- Debian 13, Xeon D-1521 / 32 GiB, 2× 6 TB (OS on mdraid RAID1,
ZFS pool
dataonsda5) — setup & rebuild: install.md - SSH:
ssh -i id_rsa_claude -p 2233 julien@193.70.35.17(julienhas passwordlesssudo incus …, includingsudo incus exec …; the backup crons themselves run as root) - Instances are on a NAT bridge
incusbr0(192.168.1.0/24); public ingress via Incus proxy devices.gateway(nginx) is the sole HTTP/S entry point and fans out to the app containers. - OS inventory:
incus list -c n,config:user.os,config:user.os-checked— refreshed byincus-container-upgrade.sh(-ofor metadata only).image.descriptionshows the creation image (2019 for most), not what the container runs today. - Services: gateway, mail, nextcloud, seafile, git, freshrss, bitwarden, outline, login (SSO), wireguard, + more — full table in install.md.
- ⚠️ The ZFS
datapool is single-disk (not mirrored); durability rests on nightly cron jobs — 01:00incus copy --refreshof all instances to the localbackuppool on sdb5, then the instance leg to S3; 05:00 restic (DB dumps + data trees) to S3; nas pulls the replicas over WireGuard (after FTTH). Full picture and restore procedures: backup-strategy.md (local-backup-cron.md, incus-copy.md, restic-backup.md).
Network flows (home ↔ ks4)
nas — home LAN 192.168.0.4 ks4 — OVH 193.70.35.17
+-----------------------------------+ +-------------------------------------+
| | | |
| host: wg-ks4 (10.8.0.22) | | [wireguard] 192.168.1.18 |
| incus remote "ks4" ------+--WG-->| wg0 10.8.0.1/24, udp 51845 |
| pull ks4:* -> pool ks4backup | udp | | masquerade -> eth0 |
| on tank (SATA) [pending FTTH] | 51845 | | |
| | | +-> incus API 192.168.1.1:8443 |
| [transmission-bt] wg0 (10.8.0.21) | | | (ufw: only from .18) |
| full tunnel 0.0.0.0/0 ------+--WG-->| | |
| kill switch: no default route | udp | +-> WAN egress: torrents + |
| downloads -> /export/media | 51845 | apt of transmission-bt |
| (NFS-exported to nuc) | | exit as 193.70.35.17 |
| | | |
| 03:30 nuc pushes its instances | | 03:00 instance snapshots |
| -> nucbackup on tank | | 01:00 incus-copy: all instances |
| 04:00 nas replicates its own | | -> project backup, zpool sdb5 |
| -> nasbackup on tank | | |
| 05:00 pull ks4:* -> ks4backup | | 05:00 restic: DB dumps + data |
| [pending FTTH] | | trees -> S3 (restic-data) |
| | | Sun 14:00 restic maintenance |
+-----------------------------------+ +-------------------------------------+
phones/laptops: WG peers 10.8.0.2-3 reach 192.168.1.x through the same endpoint
nuc (on-demand media box) mounts /export/media from nas over NFSv4
Both tunnels initiate from home (NAT, dynamic IP) toward ks4's fixed endpoint; ks4's incus API is never exposed to the internet. The pull leg and its tunnel moved from nuc to nas on 2026-08-30 (nas/README.md).