Editorial review pendingon version support under review
Action boundary
Before you act
- Expected result
- A recovery checklist names state boundaries, an owner, recovery objectives, and a tested restore result.
- Failure mode
- A copied backup cannot recreate a working known-good state or contains unprotected secrets.
- Rollback
- Make no production changes; retain only the redacted planning record and correct the checklist.
A backup is not proof
A file can exist, have a timestamp, and still fail at the only moment that matters. Recovery proof needs a restore into an isolated environment and an acceptance check that someone else can repeat.
Draw the recovery boundary
List the pieces that may need coordinated recovery: deployed version, approved configuration, secrets references (not secret values), service definition, local SQLite or other state store, integration settings, and any external dependency whose state cannot be reconstructed locally. Use the current official documentation to confirm the product-specific locations and migration rules.
For each piece, answer:
- Who owns its restore?
- Where is the approved recovery copy?
- How old may it be before the recovery point is unacceptable?
- How long may restoration take before the recovery time objective is missed?
- What check proves it is both present and usable?
Lab: create a recovery checklist
Write a checklist for a disposable instance. It must include a pre-change capture, secure storage location, restore target, validation owner, and stop condition. Perform or simulate the restore only where your approved environment allows it. Record the result, not just the intention.
Check: a reviewer should be able to distinguish “backup completed” from “known-good state restored and accepted.” If those statements look identical in your record, rewrite it.
SQLite and local state
Treat a database or local state directory as application state, not as an incidental file. Do not copy it while an unknown writer may be changing it. The exact quiesce, backup, integrity, and restore procedure is release-specific and requires the current primary receipt. This lesson supplies the decision frame, not that procedure.
Checkpoint
A team saved its configuration before an upgrade but never restored its state store in a sandbox. Has it proved rollback? No. It has proved only that one input is available.
Learner artifact
Draw a state-and-restore map: service version, configuration, secret reference, state store, backup vault, isolated restore target, and acceptance check. Its text alternative must say that the arrows represent a tested recovery path, not a claim about a particular OpenClaw file layout.
Lesson checkpoint
Ready to move on?
Mark this lesson complete when you can apply its outcome without relying on the examples above.