Simple Balance
Documentation

Backups

What to back up, how to restore it, and how to check that the backup you have is one you could actually use.

Updated

Edit this page

There’s one thing to back up: the PostgreSQL database. No uploads directory, no object store, no state on disk in the container.

Taking one

sh
pg_dump --format=custom --no-owner "$DATABASE_URL" > simple-balance-$(date +%F).dump

--format=custom rather than plain SQL because it restores selectively and compresses, and --no-owner so the restore doesn’t need the original role to exist.

Restoring one

sh
createdb simple_balance_restored
pg_restore --no-owner --dbname=simple_balance_restored simple-balance-2026-09-17.dump

Point a deployment at the restored database and start it. Migrations run at startup, so a dump from an older release upgrades on first boot.

Checking the backup is real

A backup nobody has restored is a hypothesis. The cheap test:

  1. Restore into a scratch database.
  2. Start a deployment against it with SMTP_HOST and MAIL_FROM unset, so the copy mails nobody.
  3. Open the trial balance in Reports.

If it comes back and totals zero in every currency, your books in the restore are consistent rather than broken. That’s a stronger check than the file’s size, which is the thing people actually watch, but it has two limits. Each person’s trial balance covers only their own books, so on a deployment other people use, it checks yours and not theirs. And it can’t show that nothing’s missing: every transaction nets to zero by itself, so a ledger short a few of them still passes. For that, compare a few account balances with the live deployment, allowing for anything entered since the dump.