T

Julien LutranandClaude Opus 5 4c6396a8fa ks2/nas-seed: retire nuc's wg-ks4 now, not after the seed

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>

2026-08-31 10:32:21 +02:00

archer-c7

plakar-s3-data: seed done except seafile-fs (EINTR livelock, excluded)

2026-08-24 00:07:01 +02:00

ks2

ks2/nas-seed: retire nuc's wg-ks4 now, not after the seed

2026-08-31 10:32:21 +02:00

ks4

ks4/incus-copy: finish the nuc -> nas migration of leg 2

2026-08-31 10:29:06 +02:00

nas

nas+nuc: cold boot verified; record what clearing the metadata errors took

2026-08-31 10:16:44 +02:00

nuc

nas+nuc: cold boot verified; record what clearing the metadata errors took

2026-08-31 10:16:44 +02:00

backup-strategy.md

docs: follow the storage move from nuc/USB to nas/SATA

2026-08-31 09:32:29 +02:00

new-container.md

doc: instance leg to S3 shelved; ks2 push is the interim off-site leg

2026-08-28 16:17:11 +02:00

README.md

nas: new storage host on A1SAi-2750F — 4 TB off USB onto SATA

2026-08-30 23:53:30 +02:00

README.md

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 on nuc: host, iGPU instances
nas/ — storage + backup host nas (Supermicro A1SAi-2750F): the 4 TB on direct SATA, media over NFS, backup pools
ks4/ — prod server ks4 at OVH: host, services, network flows
ks2/ — legacy backup server being decommissioned
archer-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 config so 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-compose handles stacks; data paths go into scripts/restic-paths).