A backup file being present is not the same as a recoverable database. For a daily OpenClaw backup monitor, separate three questions: did the expected backup arrive, can its contents be verified, and can you actually restore and read the data in isolation? Alert on the first two routinely; rehearse the third independently. Do not let a green recency check stand in for a restore test.
Quick answer: three different proofs
| Check | Evidence you keep | What it does not prove |
|---|---|---|
| Presence and age | Expected object and timestamp, scoped to one database | That the object is complete or readable |
| Archive or snapshot verification | Verifier result and backup identifier | That your application starts from restored data |
| Isolated restore and read | Restore job result, a safe read assertion, and elapsed time | That every future restore will work |
This distinction is operational, not a new OpenClaw feature claim. AWS Backup likewise describes restore testing as running actual restore jobs and offers separate, optional validation of the restored result. A nonzero object size is a useful warning signal, not proof of a successful recovery.
Start with the backup system you actually use
If you are protecting OpenClaw's own state, prefer the native backup commands over copying a live SQLite file. OpenClaw's backup guide explicitly warns against copying live .sqlite, -wal, -shm, or -journal files. Its CLI supports creating an archive with verification, verifying an existing archive, and restoring to a separate target. Do not put an unreviewed restore command into an agent schedule that can overwrite production state.
openclaw backup create --output ~/Backups/openclaw --verify
openclaw backup verify ./path/to/openclaw-backup.tar.gz
openclaw backup restore ./path/to/openclaw-backup.tar.gz --target ./restored-openclawThe path in the example is a placeholder; use the actual archive returned by your backup run. Keep the restore target isolated and private because OpenClaw archives may contain credentials and session state. A command reporting success is still not an application-level recovery drill: inspect the expected files or database in the test target, and document how you would activate a recovery offline. For a single OpenClaw SQLite snapshot, the CLI also offers backup sqlite verify and backup sqlite restore with a separate target.
Adapt the Runbooks checklist for an external database
The Runbooks Database Backup Verifier template is a starting checklist for monitoring backups stored in S3, GCS, or a backup provider. Its actual steps check that the expected backup exists, that its timestamp falls inside your window, and that its size is not zero or unusually different from your baseline. It does not run a restore, connect to a database, or prove that the resulting data is usable. Review its provider access and alert destination before using it.
- List each database and its backup owner, storage location, expected completion window, and retention policy. Set thresholds from the real recovery objective, not from a generic template number.
- Give the checker read-only access to backup metadata where possible. Compare each expected backup with the last known successful backup and keep its identifier and observation time.
- Use an OpenClaw Automation with an explicit timezone for the recurring check. A time instruction in a HEARTBEAT.md template is not itself a registered schedule; configure and inspect the job separately.
- Alert on missing or stale evidence and record the failed condition. Separately run an isolated restore using the backup service's supported procedure and verify a safe, expected read.
- Reconcile the automation run status with its actual result and delivered alert. Record the last successful restore-test date, not just the last time the checker ran.
A small acceptance record
| Field | Example of evidence to record |
|---|---|
| Backup identity | Provider object ID or native backup archive path, without credentials |
| Freshness | Observed timestamp and policy-specific deadline |
| Verification | Native verifier result or provider integrity status |
| Restore drill | Isolated target, safe read assertion, test date, elapsed time |
| Failure owner | Who receives the alert and what triggers escalation |
The decision is simple: use the product template to make a missing-backup alert repeatable, and use your backup system's restore tooling to prove recoverability. Neither a scheduled check nor a page visit demonstrates that a database was restored. If you cannot safely perform an isolated drill yet, record that as an unverified recovery path rather than marking the backup healthy end to end.
Inspect the Database Backup Verifier template