Julien LutranandClaude Opus 5
66c7bca28f
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>
Personal infrastructure notes
Two repositories back this setup:
doc (this one) and
scripts (the cron drivers
and their config files, deployed to /root/scripts on each host).
Start here:
- backup-strategy.md — what is backed up, by which tool, on what schedule, and how to restore.
- new-container.md — conventions for adding a service to ks4 (and getting it backed up automatically).
Tech notes
nuc/— home lab onnuc: host, iGPU instancesnas/— storage + backup hostnas(Supermicro A1SAi-2750F): the 4 TB on direct SATA, media over NFS, backup poolsks4/— prod serverks4at OVH: host, services, network flowsks2/— legacy backup server being decommissionedarcher-c7/— home router (TP-Link Archer C7 v5 running on OpenWrt)
Conventions
- One markdown file per topic in the correct subdir, containing the full implementation notes, configuration, and troubleshooting notes.
- Containers are built from Debian/Ubuntu images and configured
exclusively through
incus exec/incus configso the doc is the single source of truth — rebuilding = re-running the script. - Adding a service to ks4: follow
new-container.md (no Docker in containers —
incus runs OCI images natively and
incus-composehandles stacks; data paths go intoscripts/restic-paths).