T

Julien LutranandClaude Opus 5 c8d759ce9e doc: build the ks4 -> nas backup pull leg

FTTH is up, so the leg nas-seed.md had been holding since 2026-08-30 is
now built: wg-ks4 on nas (10.8.0.22), nas peered on ks4's wireguard
container, incus remote over the tunnel, 05:00 cron, and the first pass
seeding under a systemd-run unit.

Three corrections the runbook needed, all found by running it:

- nas had no wireguard-tools at all. transmission-bt carries its own
  tunnel inside the container, so the host never needed them.
- Every ks4 instance has an instance-level eth0 pinned to incusbr0 with
  a static 192.168.1.x, so each copy failed in under a second with
  "Cannot use manually specified ipv4.address when using unmanaged
  parent bridge". nas now runs a managed incusbr0 on 192.168.1.254/24 —
  deliberately not .1, which must keep resolving over wg-ks4.
- The seed command was missing -p backup, which the doc's own
  verification step already assumed.

Also records the measured rate: ~125 Mbit/s, ks4's OVH uplink rather
than the home downlink, so ~31 h for the first pass — during which the
shared incus-copy lock suppresses the 04:00 nasbackup job.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-16 13:37:56 +02:00

archer-c7

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

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

ks2

doc: build the ks4 -> nas backup pull leg

2026-09-16 13:37:56 +02:00

ks4

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

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

nas

doc: build the ks4 -> nas backup pull leg

2026-09-16 13:37:56 +02:00

nuc

doc: make every LAN instance static, record the FTTH fallout

2026-09-16 10:33:17 +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).