mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-12 13:47:01 +00:00
kevinveenbirkenbachandClaude Opus 5.5
d1dc702de4
Step [2/9] of the DR drill starts svc-bkp-nfs-2-local on the NFS server,
which writes a full first generation of /srv/nfs into
/var/lib/infinito/backup/<machine-id>/backup-nfs-to-local on the node's
own root filesystem, i.e. the node container's writable layer on the
runner disk. Step [4/9] pulls that generation to the backup host. After
that nothing reads the NFS-side copy (the recovery restores from the
device into the restore root, and verify_recovered_marker.sh reads the
live export), and nothing deletes it: the drill never touched it and
sys-ctl-cln-bkps always keeps the last generation.
In run 40625679270 that left the size of the export on the runner disk
twice over while the [5/9] space gate measured the backup host:
shopware#0's NFS unit took the runner from 49105M to 37275M free and the
NFS node ended 13.1 GB above the control node, and SuiteCRM#0, BookWyrm#0,
Penpot#0, Funkwhale#0 and Snipe-IT#0 refused at "the sync holds the
...M pulled tree and its device copy at once ... must be free" (SuiteCRM:
8533M free, 20942M needed, 14563M of it the NFS-side generation).
The drill now removes ${DIR_BACKUPS}/${NFS_MID}/backup-nfs-to-local on
the NFS server right after the marker is confirmed on the backup host,
before the space gate measures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Test Utilities 🧪
This directory holds the operational side of testing in Infinito.Nexus.
These assets are meant to support confidence, not ceremony. They help the project validate real-world behavior across local development, CI environments, and deployment-oriented smoke tests. The emphasis is on practical feedback: when something breaks, the surrounding test tooling should make the failure easier to understand, easier to reproduce, and easier to clean up. 🚀
Good changes in this area usually make the test experience more:
- repeatable
- diagnosable
- environment-aware
- safe to rerun
The ideal outcome is boring reliability: contributors should be able to trust that a test run says something meaningful about the system, not just about the machine that happened to execute it. ✅