My Hosting Platform Runs on Two SQLite Files. Here's How I Back Them Up and Bring Them Back.
Description and use
A step‑by‑step guide to backing up and restoring the agentic‑hosting platform that stores its state in two SQLite files, covering database backups, key management, Docker volume backup, and off‑site transfer.
Problem
How to reliably back up and restore a hosting platform that stores its state in two SQLite files while it is running.
Outcome
Following the steps yields a robust backup strategy that captures all critical data, allows quick restoration on a fresh server, and keeps secrets separate from database backups.
Workflow
- 1. Run
ah backup /var/lib/ah/ah.dbas user ah to create gzipped copies of ah.db and ah-metering.db in /var/lib/ah/backups, keeping the 10 newest. - 2. Store the master.key securely outside the backup directory (e.g., a secrets manager).
- 3. Copy Docker volumes (ah-db-*) and the local registry images to a separate backup location.
- 4. Set up a cron job:
17 * * * * ah /usr/local/bin/ah backup /var/lib/ah/ah.dbto run hourly. - 5. Create an rsync script or agent prompt to copy /var/lib/ah/backups/ and master.key to an off‑site backup host, and alert if the newest backup is >2 hours old.
- 6. On a new server, install agentic-hosting, copy /etc/default/ah, the master.key, the .db.gz files, and restore Docker volumes and registry images.
- 7. Start agentic-hosting and verify the state is restored.
Evidence
ah backup creates gzipped copies of ah.db and ah-metering.db in /var/lib/ah/backups, keeping the 10 newest.
The master key is the big one. Secrets in ah.db are encrypted with it, and ah backup never writes it into a backup.
If you rotate the key with ah rotate-key, older backups still need the old key.
- Record date: 2026-10-27T15:11:12.144Z