The one thing to understand first
A backup is only as good as the recovery it enables, and “recovery” for PostgreSQL means two ingredients working together: a physical copy of the data directory taken at a known-consistent point, plus every WAL <a class="sev1-termlink" href="https://thesev1database.com/glossary/tuple/" title="Tuple">record written since so you can replay forward to any moment. pgBackRest is the tool most teams use to manage both. The earlier Pathway 04 lesson on WAL archiving and PITR explained the primitives; this lesson shows how a real backup tool composes them into full, differential, incremental, and block-incremental backups — and how restore picks them apart again.
This extends Pathway 04’s WAL-archiving + point-in-time-recovery lesson by adding the backup-tool layer that sits on top of those primitives.
The mechanism: PostgreSQL’s backup API
pgBackRest doesn’t snapshot files behind PostgreSQL’s back. It calls the server’s low-level backup API — pg_backup_start() and pg_backup_stop() (defined in src/backend/access/transam/xlogfuncs.c; these were renamed from pg_start_backup/pg_stop_backup in PostgreSQL 15). Starting a backup forces a checkpoint and records a backup_label with the start LSN; stopping it returns the stop LSN. Any data file may be copied in a torn, inconsistent state during this window — that is fine, because replaying WAL from the start LSN forward repairs every page to a consistent state. The backup is “consistent” not because the files are, but because the WAL range that accompanies them is complete.