Most backup monitoring stops at "the job ran". The job can run and still leave you with a zero-byte file, a half-written archive, or last week's copy because the new one never got written. You only find out when you need to restore.

I wrote a small skill for Hermes Agent, backup-verifier, that answers one question: is the newest backup trustworthy enough? It is a single Python file, standard library only, no network and no API key.

It checks the newest file matching a path, directory or glob:

  • it exists
  • it is recent (default limit 26 hours)
  • it is not tiny, and not much smaller than the previous backup
  • the archive reads end to end (tar, zip, gz, bz2, xz), which catches truncation
  • if a .sha256 sidecar exists, the hash matches

Output is OK, WARN or FAIL, with exit code 0, 1 or 2, so cron can alert only when something is wrong.

python3 scripts/backup_verify.py '/backups/db-*.tar.gz' --max-age-hours 26 
[OK ] freshness newest backup is 0.0 h old (limit 26.0 h) [OK ] integrity tar readable, 2 entries Result: OK

It does not prove a restore would work, and it does not open encrypted archives. It is a cheap first alarm, not a replacement for restore drills.

The skill is MIT licensed, with a built-in --selftest that builds good, truncated and stale archives and checks each is judged correctly.

Skill (MIT): https://github.com/RobinBeraud/hermes-skills/tree/main/devops/backup-verifier
All skills: https://github.com/RobinBeraud/hermes-skills

This post was written with AI assistance and reviewed through automated checks.