Learn pgBackRest (a reliable and scalable PostgreSQL backup & restore solution) from the fundamentals to production-grade: prerequisite skills & environment setup, background history & why you need it, core concepts & main architecture, installation & basic configuration, stanza check & your first backup, full differential & incremental backup types, WAL archiving & archive command, parallelism & compression, full delta & PITR restore, recovery scenarios (corrupt, lost, & clone), backup scheduling & retention policy, encryption & security, remote repository & object storage, transport security & SSH, monitoring & metrics, troubleshooting & debug, restore drill testing, v2.59.0 & the latest features, backup from standby & HA, large database scaling & delta optimization, Docker K8s & cloud integration, roadmap & community, to the alternative ecosystem & final reflection across 23 episodes.
Before you touch pgBackRest, you need to master the basics of PostgreSQL (psql, pg_ctl, WAL), Linux administration (users, systemd, permissions), and storage concepts. In this episode you'll also set up PostgreSQL 13-18, install pgBackRest 2.59.0, create the repository directory, and prepare SSH for remote mode.

This episode reviews the history of pgBackRest from its inception at Crunchy Data in 2014 to becoming an actively developed PostgreSQL backup standard (v2.59.0, July 2026). You'll also understand why pgBackRest is needed: parallel backup, continuous WAL archiving, precise PITR, retention policy, and support for up to 10 PostgreSQL versions at once.

This episode dissects the pgBackRest architecture: the stanza as the backup unit per cluster, the repository as the storage destination (local, remote, or object storage), and the full, differential, and incremental backup process. You'll also learn the roles of the pgbackrest binary, the /etc/pgbackrest.conf config, archive_command, and the main commands such as backup, restore, archive-push/get, and info.

This episode guides you through installing pgBackRest 2.59.0 in two ways: from a distribution package or by building from source, then preparing the repository directory owned by the postgres user. You'll also write a basic /etc/pgbackrest.conf configuration with the correct [global] (repo1-path, log-level) and [stanza] (pg1-path) sections for your cluster.

This episode brings pgBackRest to life for the first time: creating a stanza with stanza-create, validating the entire connection and WAL archiving chain with check, then running your first full backup and reading its status via pgbackrest info. This is the moment your repository starts holding real data.

This episode dissects the three pgBackRest backup types — full, differential, and incremental — along with how each works, their sizes, and when to use each one. You'll also configure the retention policy with repo1-retention-full and repo1-retention-diff so backups are automatically expired and the repository never fills up.

This episode dissects WAL archiving — the layer that makes precise PITR possible: archive_mode=on, archive_command with archive-push %p, and the restore_command that pgBackRest injects automatically during restore. You'll also validate archive-push/get via pgbackrest check and learn about the async archive-push option for high-write workloads.

This episode covers how to speed up backup and restore with parallelism (process-max) and compression: parallel processes that leverage many CPUs, compress-type=zst as the zstd default, adjustable compression levels, and delta backup that only copies the parts of files that changed.

This episode reverses direction: recovering backups. You'll learn pgbackrest restore with the default/immediate type for the latest state, precise PITR with --type=time, --type=lsn, and --type=name, and --delta to sync an existing cluster. This is the moment of proof that all your backups can really be recovered.

This episode tests recovery in three real scenarios: a corrupt cluster recovered to the last backup plus WAL, the loss of the entire data directory requiring a rebuild from scratch, and creating a clone or new standby instance from a backup. It ends with a crash simulation and PITR to a specific time exercise.
