Lesson 9 of 9 · 18m
Backups, Replicas, and the Settings That Matter
pg_dump vs PITR, streaming replication, and the five config knobs that determine whether your database survives the next incident.
A backup strategy that hasn't been restored from isn't a backup — it's a hope. Postgres gives you two real options and a handful of settings that decide whether they work when you need them.
pg_dump is a logical snapshot
pg_dump -Fc produces a portable, restorable export — perfect for dev databases, small prod, and "copy prod to staging." Its limit: it's a logical dump, so restore time scales with data size and it captures a point-in-time snapshot of whatever it saw when it ran.
PITR is for real recovery
Point-in-time recovery = base backup (pg_basebackup or a filesystem snapshot) + continuous WAL archiving (archive_command copying WAL segments to object storage). Restore is "recover to 2025-06-15 14:32:07" — you get back every committed transaction up to the failure. Tools: pgBackRest, WAL-G, Barman.
Streaming replication
A replica replays the primary's WAL in near-real-time. hot_standby = on makes it readable — reports, analytics, read-heavy queries can hit the replica. Synchronous mode (synchronous_commit = remote_apply) waits for the replica to confirm before returning to the client: the price is latency, the payoff is zero data loss on primary failure.
The knobs that matter most
shared_buffers— page cache; 25% of RAM is the default starting point.work_mem— per-sort/hash memory; too low and joins spill to disk, too high and you exhaust RAM.max_connections— each is a process; >500 is a smell — use a pooler (PgBouncer).effective_cache_size— a hint to the planner about OS cache; set it to ~75% of RAM.autovacuum_*— tune per-table (ALTER TABLE big_table SET (autovacuum_vacuum_scale_factor = 0.05)) when defaults are too lazy.
Field notes
pg_stat_replicationon the primary shows lag — a replica >5min behind is a PagerDuty page, not a metric to watch.- Test restore quarterly: restore to a scratch instance, run a checksum or a row count, document the RTO.
- The
recovery_target_timein a PITR restore is your real RPO — the WAL archive's lag is how much you lose on a bad primary.