pg_basebackup creates a safe, full snapshot of a PostgreSQL cluster data directory without stopping the database. It is PostgreSQL-aware: unlike RAID, server snapshots, or generic file-level copies, it accounts for server processes, data files, and WAL semantics. section 9.1
Physical redundancy is not a backup strategy. Mirrored disks, snapshots, and standby replication can all preserve corruption, accidental deletion, or malicious changes. A recoverable backup is an independent copy that can restore data regardless of the hardware or replication arrangement. section 9.1 section 9.7
Figure 9.1 A PostgreSQL installation layout demonstrating the double physical redundancy of having a standby server but also RAID1 mirrored disks in each of the servers.
This layout illustrates why multiple physical copies alone do not provide recovery from logical damage: both the primary and standby can retain the same bad change. section 9.1
For Point-in-Time Recovery (PITR), pg_basebackup supplies the base image and archived WAL supplies the transaction history after that image. The backup is a binary-perfect copy of the entire cluster, not an individual database. Retain every WAL file generated from backup start through completion; otherwise a requested recovery point may be unreachable. section 9.2
A practical recovery workflow is:
- Configure WAL archiving with archive_command in postgresql.conf. section 9.2
- Take a full base backup with pg_basebackup. section 9.2
- Restore the data directory and set recovery_target_time to recover up to the required moment. section 9.2
- Schedule PostgreSQL-aware backups, keep a redundant offsite copy, and regularly perform a full restore test. section 9.7
Full backups alone leave a loss window between backup runs. Continuous WAL archiving closes that gap for PITR. PostgreSQL 17 also adds incremental pg_basebackup backups for very large databases; these combine with older base backups to form full backups. section 9.2
