Backups
The Compose stack includes a backup service. It runs from the first
docker compose up -d with no configuration.
What it does
Section titled “What it does”Every BACKUP_INTERVAL seconds it writes a compressed pg_dump into the
backups volume as app-<timestamp>.dump, then deletes everything past the
newest BACKUP_KEEP files.
| Variable | Default | Meaning |
|---|---|---|
BACKUP_INTERVAL |
86400 |
Seconds between dumps. The default is daily. |
BACKUP_KEEP |
7 |
Dumps retained. |
So the default is a week of daily snapshots. To keep a month of them:
BACKUP_KEEP=30Copy the dumps off the machine
Section titled “Copy the dumps off the machine”A backup on the same disk as the database is not a backup. The volume is on thehost. Find it and sync it somewhere else:
docker volume inspect conatus_backups --format '{{ .Mountpoint }}'Or copy the newest dump out on demand:
docker compose cp backup:/backups ./backupsTake a dump right now
Section titled “Take a dump right now”docker compose exec db pg_dump -U app -Fc app > backup.dumpDo this before every upgrade. See Upgrading.
Restore
Section titled “Restore”docker compose exec -T db pg_restore -U app -d app --clean --if-exists < /path/to/app-<timestamp>.dump--clean --if-exists drops the existing objects first, so this replaces the
current database contents. Stop the app before restoring so nothing writes into
a half-restored schema:
docker compose stop appdocker compose exec -T db pg_restore -U app -d app --clean --if-exists < backup.dumpdocker compose start appIf you restore a dump taken from an older release, start the stack normally.
afterwards. The migrate job runs before the app and brings the schema forward.
Test the restore
Section titled “Test the restore”An untested backup is a guess. Once, on a throwaway copy of the stack, restore your newest dump and log in. It takes ten minutes and it is the only thing that tells you the dumps are real.
