How Hermes's own configuration/state gets backed up, and what's missing.
Current mechanism
hermes backup CLI (verified via hermes backup --help): creates a zip of the entire Hermes config, skills, sessions, and data (excludes the hermes-agent codebase itself).
--quick / -q: fast snapshot of just critical state (config, state.db, .env, auth, cron)
Config keys (updates: section of ~/.hermes/config.yaml):
pre_update_backup: false — Hermes does not automatically back up before self-updates
backup_keep: 5 — retention count (applies to config.yaml.bak* rotation seen during updates, e.g. in runbooks/update-hermes-safely)
non_interactive_local_changes: stash
Evidence on disk (2026-07-22)
One manual full backup exists: /home/hermes/hermes-backup-2026-07-22-180830.zip (~235 MB), same day as wiki creation.
/home/hermes/wiki-personal-backups/ holds an earlier snapshot of the wiki itself (SCHEMA.md, current-state.md, index.md, log.md from 17:34, before later same-day wiki edits) — see runbooks/backup-wiki.
/home/hermes/hermes-wiki/ exists but is empty — likely a staging/rename artifact from wiki setup, not an active backup target.
A dedicated memory-backup script exists: /home/hermes/.hermes/scripts/mnemosyne-backup.sh — see systems/mnemosyne.
Known gaps
No scheduled backup job found:crontab -l -u hermes returns empty, and no systemd timer references hermes or backup. The one full backup on disk appears to have been triggered manually, not on a schedule.
pre_update_backup: false means an in-place hermes update will not auto-snapshot first — the manual step in runbooks/update-hermes-safely step 1 is currently the only safety net.
