On 9 Oct 2026 restic backed up two Postgres dumps and 6 Docker volumes (174.8 MiB) on our 1 GB test server in 27 seconds and stored 23 MiB. The one mistake to avoid: treating a copy of the live Postgres data folder as your database backup.
The checklist
- Dump the database first.
docker exec <postgres-container> pg_dumpall -U <user> | gzip > /var/backups/pg/db.sql.gz. PostgreSQL's own documentation says a file-level copy of a running server is not reliably usable; the dump is. - Back up the dump and the volumes with restic.
restic backup /var/backups/pg /var/lib/docker/volumes/<volume>/_data. Keep the volumes for files that are not databases, such as n8n's encryption key. - Put the repository off the server. A repository on the same disk protects against mistakes, not against losing the server. Use an S3-compatible bucket (
RESTIC_REPOSITORY=s3:https://<endpoint>/<bucket>/<folder>). - Copy the password file somewhere else now. Without it nobody can read the backups, including you.
- Run it at night, niced. On one vCPU our first backup left 0% idle CPU in 25 of 26 seconds.
Nice=10and idle I/O priority in the systemd unit let your apps go first. - Check it.
restic check, and alert when the last snapshot is more than a day old. - Restore it once. The drill is on the next page: RESTORE.
The full test
- restic Postgres backups on a 1 GB VPS, with a timed restore
- Self-hosted n8n: two things not done for you
The starter kit does all of this with one script (60-backup.sh): dumps, restic, a nightly niced timer, check and restore commands. Pay what you want.