Continuous backup, also called WAL archival or continuous archiving, preserves PostgreSQL write-ahead log (WAL) files as they are produced. Combined with a base backup, those replayable transaction records enable point-in-time recovery (PITR): restore the cluster to a chosen moment after the backup rather than only to its last full-backup state. section 9.2
A base backup made with pg_basebackup is a binary-perfect snapshot of the whole database cluster. It is necessary but insufficient on its own: full backups leave a data-loss window between runs. For PITR, retain every archived WAL file from the instant the base backup starts through its completion, then onward for every recovery point that must remain available. section 9.2 section 9.7
Set up recovery as an operational chain, not as isolated backup files:
- Configure WAL archiving with a custom archive_command in postgresql.conf. section 9.2
- Take a full cluster backup with pg_basebackup and preserve the WAL generated during the backup itself. section 9.2
- Restore the data directory and set recovery_target_time to the desired stopping point. section 9.2
- Automate backups with PostgreSQL-aware software, keep a redundant copy elsewhere, and regularly perform a full restore test. section 9.7
Recover before damage
If corruption, human error, or malicious activity damages data after a base backup, restore that backup and replay archived WAL only up to the moment immediately before the damage. This avoids accepting every change made since the last full backup merely because that snapshot is the newest one available. section 9.2 section 9.7
Continuous archiving improves recovery-point capability, not necessarily service-restoration time. PITR can recover to the last committed transaction contained in the last saved WAL file, while recovery time depends on the high-availability architecture. Replication and standby nodes address redundancy and failover separately from backup recovery. section 9.5 section 9.7
Figure 9.3 A sample PostgreSQL HA setup with a cascaded replication for redundancy and backup
Use the topology to distinguish backup-oriented WAL shipping from replication-based redundancy: both move WAL, but standby design also determines failover and downtime behavior. section 9.5
