From aaf053766597aa6e240aaaa17827d95529b13ab1 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Thu, 17 Sep 2026 00:04:09 +0200 Subject: [PATCH] CHAOS NIGHT round 6: the off-site leg takes no local space - measured, not argued 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 Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS --- .../round-6-pbs-leg.txt | 2 + .../round-6.txt | 48 +++++++++++++++++++ 2 files changed, 50 insertions(+) diff --git a/documentation/audits/evidence-chaos-night-2026-09-17/round-6-pbs-leg.txt b/documentation/audits/evidence-chaos-night-2026-09-17/round-6-pbs-leg.txt index 521c190a..959dd58c 100644 --- a/documentation/audits/evidence-chaos-night-2026-09-17/round-6-pbs-leg.txt +++ b/documentation/audits/evidence-chaos-night-2026-09-17/round-6-pbs-leg.txt @@ -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 diff --git a/documentation/audits/evidence-chaos-night-2026-09-17/round-6.txt b/documentation/audits/evidence-chaos-night-2026-09-17/round-6.txt index 3d79156d..1d37e0d5 100644 --- a/documentation/audits/evidence-chaos-night-2026-09-17/round-6.txt +++ b/documentation/audits/evidence-chaos-night-2026-09-17/round-6.txt @@ -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 \ No newline at end of file