Backup and Restore

Backups copy data so it can be recovered after deletion, corruption, or disaster. A backup is only as good as the last successful restore test.

reliability

Definition

Backup and restore is the operational practice of copying data and configuration to independent storage and proving that those copies can rebuild a working system within acceptable time and data-loss limits.

Context and scope

Backups protect against operator error, ransomware, storage failure, and bad deployments. They are distinct from replication, which copies failures as faithfully as it copies data.

Common misconceptions

Replication is a backup because it keeps a second copy
A backup job that reports success is definitely restorable
Backups stored in the same account or region are sufficient

Anti-patterns

Never testing restores until an incident forces one
Storing the only backup credentials alongside the backup data
Backing up a corrupt dataset on a schedule without validation

Related concepts

Authoritative source

https://www.postgresql.org/docs/current/backup.html

How it works

Backups take three common forms: logical dumps, physical snapshots, and continuous log archiving. Full backups copy everything, incremental backups copy changes since the last backup, and differential backups copy changes since the last full. Continuous archiving of write-ahead logs enables point-in-time recovery.

pg_dump --format=custom --file=app-2026-10-20.dump appdb
pg_restore --dbname=appdb_restore --clean app-2026-10-20.dump

Store copies in a separate account or region, encrypt them, and protect the keys separately. Restore into a clean environment, replay logs to the target time, verify checksums and row counts, then switch traffic.

When to use it

Every stateful system needs backups, but the required mode follows RPO and RTO. A 24-hour RPO may tolerate nightly dumps; a five-minute RPO needs continuous log shipping or synchronous replication plus snapshots. Test restores quarterly and after major schema changes. Compared with replication, backups preserve history rather than mirroring current state.

Trade-offs

Frequent full backups cost bandwidth and storage; incremental chains reduce cost but lengthen restore time and add dependency on every link. Immutable, air-gapped copies resist ransomware but slow recovery. Encryption protects stolen media yet fails if the key is lost, so key custody needs its own plan.

Concrete example

An operator drops a table at 10:02. The team restores last night’s base backup, replays write-ahead logs to 10:01:59, validates row counts against the application ledger, and resumes traffic at 10:41, achieving roughly 39 minutes of RTO and one minute of RPO.

Replication is not a backup: a dropped table or ransomware encrypts replicas too. A green backup job proves copying, not restorability. Related concepts include Disaster Recovery, RTO and RPO, Write-Ahead Logging, and Data Retention.