admin
5a349d9884
gates / gates (push) Successful in 26s
- 09 §3: decision 19 (the copy method is chosen by a bake-off) and 20 (the full-system backup waits for the update leg, inside its window; built later). - Bake-off on 9202, docmost / romm / vikunja: both methods pass every case; the folder copy wins because an app with no database server gets no dump, so dump-and-load would need the folder copy anyway. 1-5 s extra downtime, ~420 MB/s, disk = the volumes. - R-645 filed: lifting an update hold by hand lets the recovery unit be re-captured with the failed definition within seconds. Documents and evidence only; product code follows in the controller. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
12 lines
627 B
Plaintext
12 lines
627 B
Plaintext
10:22:23 === cut-off copy: vikunja (largest volume vikunja_vikunja_db)
|
|
10:22:27 copy container exit=0 (137 = killed)
|
|
source bytes=2920872 cut copy bytes=2920872
|
|
finished-marker in the cut copy: 1 -> F refuses to swap
|
|
D: no safety dump exists for this app (R-641)
|
|
|
|
10:22:40 RETRY — 2.9 MB copied inside 0.02 s, so the first cut missed; kill with no delay:
|
|
10:22:48 try 1: container exit=0 source bytes=2920872 cut copy bytes=2920872 finished-marker=1
|
|
try 2: container exit=0 source bytes=2920872 cut copy bytes=2920872 finished-marker=1
|
|
try 3: container exit=0 source bytes=2920872 cut copy bytes=2920872 finished-marker=1
|
|
|