Julien LutranandClaude Fable 5
ef88ef9342
backup-strategy (the entry point) still described nuc pulling the ks4 replicas: the leg, its WireGuard peer and the target pool now live on nas with the 4 TB on direct SATA. Also: ks4 README flow chart redrawn for the new topology, incus-copy leg 2 retargeted, usb4t-dropouts marked RESOLVED (kept for the diagnosis method and the alerting gap), and ks2/plan records that the interim push was deliberately not re-enabled. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.7 KiB
3.7 KiB
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).