Trigger-file driven. When a new backup file lands, runs a size sanity check, verifies archive integrity (tar/zip/sql), and notifies whether the backup is good.

`backup-verifier`

Trigger-file driven. When a new backup file lands, runs a size sanity check and an archive integrity check (tar, gzip, zip, SQL dump), then notifies the result.

Use case

The classic backup failure: the cron ran, a file got written, the size looks plausible — but the archive is silently corrupt and nobody knows until the day they try to restore. This workflow catches that on arrival, in seconds.

This is a YAML workflow, not a skill — tar -tzf is the verifier, no AI involved.

Setup

Create a trigger-file watching your backup destination (e.g. /backups/postgres/)
Link the trigger to this workflow
The workflow fires per file landing; the trigger engine sets TRIGGER_FILE
Adjust MIN_BYTES in workflow.yaml to match your normal backup baseline (a few times your smallest legitimate backup, well below your average)

Pipeline

verify — runtimeenv (bash) — size check, then format-aware integrity check, exits non-zero on FAIL
notify — message — sends the verdict

Supported formats

.tar / .tar.gz / .tgz — full archive read via tar -t[z]f
.zip — unzip -t
.sql / .dump — heuristic trailer check (looks for COMMIT or pg_dump's completion marker)
Anything else — size check only

Behavior on FAIL

Non-tar/zip integrity issues exit the script non-zero → notifications.alertOnError fires the alert contact in addition to the notify task's body. So a corrupt backup gets two messages: the detail (notify) and the page (alertOnError). That redundancy is intentional — backup failures should be impossible to miss.

Customization

Add new format branches in the case statement (e.g. .7z with 7z t)
Tighten MIN_BYTES — set to half your smallest healthy backup, not 1MB blanket
Restore-test mode: extend with a sql task that does a partial restore into a sandbox DB — the only true integrity test for a database dump

Source

See workflow.yaml.