Database backups exist to recover from data loss: hardware failure, accidental deletion, malicious action, application bugs that corrupt data. The goal isn't "we have backups" — it's "we can restore."
The difference matters. Many organizations have backups they've never restored. They're unverified. The first restore attempt during a real incident is the worst time to discover problems.
This page covers the practices that produce restorable backups.
Complete copy of the database. Largest; longest to take; longest to restore.
Changes since last backup (full or incremental). Smaller; faster; chains together for restore.
Changes since last full backup. Larger than incremental but simpler restore.
PostgreSQL: write-ahead log files shipped continuously. Enables point-in-time recovery to any moment.
For most production systems, continuous archiving + periodic full backups is the standard.
How much data are you willing to lose? With daily backups, up to 24 hours. With continuous archiving, seconds.
How long can recovery take? Tied to backup type and size.
Match RPO/RTO to business needs. Tighter requirements cost more.
For RDS, Aurora, Cloud SQL, etc., backups are largely automatic:
In addition to automated. For long-term retention; before major changes.
For most cloud databases, automated + manual snapshots covers most needs.
For self-hosted databases, you implement backup yourself.
pg_basebackup for full backups; WAL archiving for continuous.
Tools: pgBackRest, Barman, WAL-E/WAL-G. Production-grade backup tools handle compression, encryption, retention, parallel restore.
mysqldump for logical backups; Percona XtraBackup for hot backups.
mongodump for logical; filesystem snapshots for hot.
The actual database contents.
Database configuration, user accounts, roles, schemas. The "rebuild from scratch" requires this too.
Without app code, database alone doesn't help.
VPC, security groups, IAM. Terraform usually handles this.
Fast access; vulnerable to region failure.
DR-ready. Costs more (transfer + storage).
Multi-cloud DR. Highest cost; protects against cloud-provider failure.
For most production systems: same-region for speed; cross-region for disaster recovery.
Backups should be encrypted at rest and in transit. The "tar file in S3" pattern is standard:
If backups can be decrypted with a single key compromise, that's a security vulnerability. Manage keys carefully.
The single most important practice. Backups that have never been restored are aspirational.
Monthly or quarterly: restore a backup; verify it works.
What to verify:
Spin up a fresh database; restore latest backup; run smoke tests; tear down.
In CI/CD or scheduled. Continuous verification.
Annual: pretend the primary is gone. Restore in DR region; failover applications. Time it.
This finds problems automated tests miss: documentation gaps, manual steps, organizational coordination.
Keep 7-30 days. Recent enough for normal recovery.
Keep for 1-3 months. Catches issues discovered later.
Keep for 1-7 years. Compliance retention.
Long-term retention as required.
Lifecycle from hot storage to cold (Glacier, etc.) saves cost as backups age. See CloudStorageOptions.
Point-in-time recovery to just before the bad operation.
Without PITR: restore last full backup; lose data since then.
Attacker may have planted persistence. Restore to before compromise; verify.
If compromise was long ago, may need to restore very old backup and replay transactions. Or accept loss of recent data.
Application bug corrupted data. Restore to before bug; reapply known-good transactions if possible.
Restore in another region from cross-region backup. Re-point applications.
Restore fails when actually needed.
Region failure loses both.
Procedures don't match current environment.
Backups silently stop; nobody notices.
Storage cost grows; eventually backups are deleted to save money; the wrong ones get deleted.
Human forgets; backups missing.
Compromise of database = compromise of backups.
For typical production databases: