Julien LutranandClaude Opus 5 ceff4ec0d0 doc: record the real ks4 pull bottleneck — source disk, not the link
c8d759c claimed the ~125 Mbit/s seed rate was ks4's OVH uplink. That was
wrong, and measuring it says so: ks4 uploads at 609 Mbit/s, downloads at
900, and nas pulls 670 from OVH's network. WireGuard is not it either —
zero UdpRcvbufErrors, wg-crypt kworkers at ~2%, both hosts ~85% idle.

The limit is `data` sitting on sdb5, one 7200 rpm HGST 6 TB disk: during
the send it does 109 r/s at 14 MB/s with ~131 KB requests and a queue
depth of ~1.0, which is the random-IOPS ceiling of a single HDD reading a
fragmented 1.42 TiB dataset. 14 MB/s is ~112 Mbit/s on the wire, exactly
what we see, while the network sits idle.

Parallelism is the only lever and it works by disk queue depth, not
bandwidth: a second concurrent copy takes sdb from 14 to 21 MB/s and the
request size from 131 KB to 514 KB, lifting the tunnel from 113 to 153
Mbit/s. Recorded, along with the decision to keep the seed sequential —
one-off pass, incremental refreshes after, and incus-copy.sh is shared by
all three legs.

Also corrects the set size to the actual 1.42 TiB (~29 h, not ~31 h).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 14:47:28 +02:00

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).
S
Description
No description provided
Readme
670 KiB
Languages
Markdown 100%