diff --git a/BACKLOG.md b/BACKLOG.md
index 7cce976..cf1fff0 100644
--- a/BACKLOG.md
+++ b/BACKLOG.md
@@ -190,10 +190,11 @@
 ## P2 — Polish & DX
 
 ### DC-038: Backup trigger.json + result.json in dashcaddy-update.sh — enable one-command rollback
-- **status:** in-progress
+- **status:** done
 - **owner:** hermes
 - **details:** During the DC-033 fix, recovering from the failed v1.14.4 update required manually mv'ing `trigger.json.processing` back to `trigger.json`, manually running `start.sh`, etc. — because the backup mechanism in `dashcaddy-update.sh` (lines 318-327) only backs up code + data, not the trigger/result state. Fix: in the `backup_data_dir` function (or new `backup_update_state` function), also copy `${UPDATES_DIR}/trigger.json` and `${UPDATES_DIR}/result.json` into the versioned backup directory so rollback tooling can restore them. Effort: ~15 min.
 - **impact:** Faster incident recovery. Currently takes 5-10 manual steps to roll back a failed update; would take 1.
+- **result:** Added \`backup_update_state()\` function in \`dashcaddy-update.sh\` (idempotent, tolerates absent files + chattr +i, cleans up empty subdir). Wired into \`main()\` immediately after \`backup_data_dir()\`. Backs up \`trigger.json.processing\` + \`result.json\` into a \`update-state/\` subdir of the versioned backup. Deliberately does NOT auto-restore on rollback — the rollback handler reads a fresh trigger.json written by the operator/container; restoring the previous attempt's trigger would clobber the active rollback request. New regression test \`dashcaddy-api/scripts/test-dashcaddy-update-backup.sh\` (14 assertions across 5 groups: both-files-present, partial-present, no-files-present, idempotency, main() flow ordering) — all pass. Tests: 1214/1214. Lint: 150 warnings, all pre-existing in untouched files, zero new warnings introduced.
 
 ### DC-039: Audit repo for other `__dirname + sibling-file` patterns — DC-033 class of bug
 - **status:** done