fix(backup): don't fail volume backups on warning-level tar exits #18
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/volume-backup-tar-warning-exit"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
Odoo's volume backup failed most attempts:
tarexits 1 for warning-level conditions ("some files differ") and reserves 2for fatal errors. Odoo appends to its server log constantly, and that log lives inside a
backed-up mount — so tar noticed the file growing under it and exited 1.
StreamingCommandExecutortreated every non-zero exit as fatal, so the backup wasdiscarded even though the archive was complete and restorable. Failures were intermittent
because they depended on whether the app happened to write during tar's read window —
hence "most" attempts, not all.
Fix
Tolerate warning-level tar exits — but not on the exit code alone. BusyBox tar exits 1
for genuine errors too:
So an exit of 1 is accepted only when every stderr line matches a known-benign warning
(
file changed as we read it,File removed before we read it,socket ignored,leading-slash notices). Anything unrecognised fails closed.
VolumeBackupStrategy, which already owns the tar commandStreamingCommandExecutortakes an injectedwarning_filter:; its default is unchanged,so database dumps still fail on any non-zero exit
docker cpfallback carriedthe same defect
Verification
Not just specs. Reproduced the real condition with a Debian container appending to a 30MB
log on a mounted volume:
gzip -tOK,tar -tzfOK, extracted log readableFull suite: 1147 examples, 0 failures.
Docs
CHANGELOG.mdentry, plus a newTROUBLESHOOTING.mdsection explaining that thesewarnings are not failures and how to verify an archive by hand.
tar exits 1 for warnings ("some files differ") and reserves 2 for fatal errors. A container writing to its own data while it is archived -- an application appending to a log file -- trips the warning, most reliably with Odoo, whose server log lives inside a backed-up mount. StreamingCommandExecutor treated every non-zero exit as fatal, so the backup was discarded even though the archive was complete and restorable. Failures were intermittent because they depended on whether the app happened to write during tar's read window. Tolerate warning-level tar exits, but not on the exit code alone: BusyBox tar exits 1 for genuine errors too (verified: "can't open ...: Permission denied" -> 1). An exit of 1 is accepted only when every stderr line matches a known-benign warning, so permission errors and missing paths still fail the backup. tar's exit semantics live in VolumeBackupStrategy, which already owns the tar command; the executor takes an injected warning_filter and its default behaviour is unchanged, so database dumps still fail on any non-zero exit. Both volume paths are covered -- in-container tar and the host-side docker cp fallback carried the same defect. Verified against live containers, not just specs: a Debian container appending to a 30MB log reproduced the reported error 3/3 before the fix and succeeded 5/5 after, with archives passing gzip -t and extracting cleanly; a BusyBox container with an unreadable file still fails and surfaces the permission error. Co-Authored-By: Claude <noreply@anthropic.com>