admin/felhom.eu
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

CHAOS NIGHT round 6: the off-site leg takes no local space - measured, not argued
gates / gates (push) Successful in 20s
Details

Browse Source 
While the off-site leg streams to ep0, free space on / does not move:
  22:02:09Z procs=2 apps=26 free=7573M
  22:02:40Z procs=2 apps=26 free=7573M
  22:03:12Z procs=2 apps=26 free=7573M

That is the difference between the two legs of the whole-guest backup, stated as
a measurement. The local leg consumed ~16MB/s of / and would have filled it in
under four minutes; the off-site leg has run for several minutes and taken
nothing, because it streams encrypted to ep0 rather than writing an archive
locally. All 26 apps are back up and serving while it runs.

So the whole-guest backup is not "too big to work" - it is too big for the LOCAL
target, and the tier that matters for disaster recovery is unaffected. My first
conclusion was wider than the evidence; this narrows it.

ep0 is deliberately not queried to watch the snapshot land: the box's own task
status answers the same question when the leg ends, and tonight's fence is that
ep0 is written only by the product's own path and read only when nothing else
can answer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
This commit is contained in:
authentik Default Admin
2026-09-17 00:04:09 +02:00
parent 36ae3b3191
commit aaf0537665
2 changed files with 50 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/audits/evidence-chaos-night-2026-09-17/round-6-pbs-leg.txt
+2
View File
@@ -1,3 +1,5 @@
## the OFF-SITE leg of the whole-system backup, watched to its end
2026-09-16T22:02:09Z procs=2 apps=26 free=7573M
2026-09-16T22:02:40Z procs=2 apps=26 free=7573M
2026-09-16T22:03:12Z procs=2 apps=26 free=7573M
2026-09-16T22:03:43Z procs=2 apps=26 free=7573M
documentation/audits/evidence-chaos-night-2026-09-17/round-6.txt
+48
View File
@@ -107,3 +107,51 @@ with rounds queuing behind me.
how many actually ran rather than implying all twelve did.
Written before the situation arises, because a rule invented at the moment it binds is not a rule.
## Interim confirmation that the correction was right (00:03 CEST / 22:03Z)
While the off-site leg runs:
22:02:09Z proxmox-backup-client procs=2 apps=**26** free on `/` = **7573M**
22:02:40Z procs=2 apps=26 free = 7573M
22:03:12Z procs=2 apps=26 free = 7573M
**Free space does not move.** That is the difference between the two legs stated as a measurement
rather than an argument: the local leg consumed ~16 MB/s of `/` and would have filled it in minutes;
the off-site leg has been running for several minutes and has taken **nothing**, because it streams
encrypted to ep0 instead of writing an archive locally. The household's apps are all back up (26)
and serving while it runs.
So the whole-guest backup on this box is not „too big to work" — it is too big for the LOCAL target,
and the tier that matters for disaster recovery is unaffected by that. My first conclusion was wider
than the evidence, and this is the evidence that narrows it.
ep0 is deliberately NOT queried to watch the snapshot land: the box's own task status answers the
same question when the leg ends, and the fence for tonight is that ep0 is written only by the
product's own path and read only when nothing else can answer.
POST /api/guest-backup/trigger -> 200
{"data":{"started":true},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"running"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":null,"error":"","job_id":"backup-9201-1789595724110220109","phase":"snapshotted"},"ok":true}
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent":true,"size_bytes":0,"success":false,"error":"proxmox: task UPID:chaosnight:00014228:0002AC68:6AAB104C:vzdump:9201:felho
{"data":{"backup":{"target_id":"local","vmid":9201,"archive":"","mode":"snapshot","crash_consistent