docs: backup verified IN the repository — snapshot b587f775, 118/118 + 40/40 (R-229)
gates / gates (push) Successful in 8s

58,158 files / 405.865 GiB in 27:56; 994 MiB added, 77 MiB stored -- the one-time full re-read
cost I/O, not storage, as predicted.

Also records a false alarm I raised against my own instrument: `restic ls <snapshot> <path>`
reported 0 of 40 archived memories because restic 0.18.0's path filter does not recurse into
subdirectories. The unfiltered listing shows all 40. An instrument that can drop results silently
is not a measurement -- and this one was measuring a safety property.
This commit is contained in:
2026-08-06 11:22:34 +02:00
parent 6a835ad9ec
commit 92a076c239
2 changed files with 43 additions and 2 deletions
+14 -2
View File
@@ -118,11 +118,23 @@ Including Claude auto-memory store: /mnt/5_hdd/felhom.eu/git/.claude-memory
start backup on [/mnt/4_hdd/data /mnt/5_hdd/felhom.eu/git/.claude-memory]
```
**Completed and verified in the repository.** Snapshot `b587f775`, 58,158 files / 405.865 GiB in
27:56, `994.132 MiB added (77.440 MiB stored)` — 77 MiB stored for a 405 GiB re-read confirms the
one-time cost was I/O, not storage. Contents: **161** `.claude-memory` entries — **118/118** top-level
`.md` and **40/40** under `archive/`. The 03:07 snapshot holds `/mnt/4_hdd/data` only, so the two
snapshots are a clean before/after in one listing.
**A false alarm I raised against my own instrument.** The first check used
`restic ls <snapshot> <path>` and reported **0 of 40** archive files — which read exactly like 40
memories silently unprotected. It was wrong: restic 0.18.0's path filter lists entries *at* that path
and does not recurse. The unfiltered listing shows all 40. Recorded because it is this project's own
rule — *an instrument that can drop results silently is not a measurement* — biting a measurement made
**to verify a safety property**.
**Three caveats that make this weaker than "backed up" sounds:** the destination is on the **same
physical disk** as the store; the DooPlex backup set has **no off-site leg**
(`sync-hetzner-backups.sh` is jarrs.eu and pulls the other way); and `/opt/backup/scripts/` is itself
**unversioned host state** (R-231). One-time cost: adding a path invalidated restic's parent match,
so the first run re-reads 405 GiB — dedup keeps storage flat and later runs are incremental again.
**unversioned host state** (R-231).
## 11. Rules report — first run
@@ -181,6 +181,35 @@ Including Claude auto-memory store: /mnt/5_hdd/felhom.eu/git/.claude-memory
start backup on [/mnt/4_hdd/data /mnt/5_hdd/felhom.eu/git/.claude-memory]
```
**Completed and verified in the repository, not just in the log.** Snapshot `b587f775`
(2026-08-06 10:51:17), 58,158 files / 405.865 GiB in 27:56:
```
Files: 58158 new, 0 changed, 0 unmodified
Added to the repository: 994.132 MiB (77.440 MiB stored)
snapshot b587f775 saved
```
| Check | Result |
|---|---|
| snapshot lists the store path | yes — alongside `/mnt/4_hdd/data` |
| `.claude-memory` entries in the snapshot | **161** |
| top-level `.md` (incl. the index) | **118 / 118** |
| `archive/` `.md` | **40 / 40** |
| previous snapshot `511b7f9d` (03:07) | `/mnt/4_hdd/data` only — a clean before/after in one listing |
77 MiB stored for a 405 GiB re-read confirms the dedup prediction: the one-time full read cost I/O,
not storage.
**A false alarm I raised against my own instrument, recorded because the class is the point.** The
first verification used `restic ls <snapshot> <path>` and reported **0 of 40** archive files —
which read exactly like a real defect (40 memories silently unprotected). It was wrong: in restic
0.18.0 that path filter lists entries **at** the filtered path and does not recurse into its
subdirectories. The unfiltered `ls` shows all 40. This is the project's own rule — *an instrument
that can drop results silently is not a measurement* — caught on a measurement made **to verify a
safety property**, which is the worst place for a silent drop. Same class as the `| tail -5` census
and the `go test -run` false green already in the register.
**Three caveats, each of which makes this weaker than "backed up" sounds:**
1. The destination `/mnt/5_hdd/backup` is on the **same physical disk** (`sda1`) as the store. This