backup-restore

Run pg_dump through docker compose exec with the custom format flag: docker compose exec -T db pg_dump -Fc -U $POSTGRES_USER $POSTGRES_DB > backup_$(date +%F).dump. The custom format enables selective and parallel restores later.

Keep 3 copies of your data on 2 different media with 1 copy offsite. A backup stored on the same VPS dies with that VPS, so push dumps to S3, Backblaze B2, or rsync.net using a tool like rclone.

Restore into a throwaway Docker container, never against production. Run pg_restore inside a temporary postgres container, then verify row counts of critical tables and the most recent timestamp against production values.

RPO is how much data you can afford to lose, which drives backup frequency and WAL archiving. RTO is how long you can be down during recovery, which determines whether you use pg_restore or faster replica promotion.

Cron jobs often fail without alerting, producing zero-byte or truncated dumps. Monitor for job failure, absence of new backups within 25 hours, and size anomalies like a dump shrinking by 50 percent.

Use pgBackRest or physical backups when databases grow large enough that logical dumps take hours, or when you need point-in-time recovery via WAL archiving. pg_dump suits smaller databases with nightly schedules.