Learn pgBackRest - History, Background & Why You Need It

#Introduction

Now that our environment is ready from episode 0, it's time to understand why pgBackRest exists. Every major technology is born out of a real problem, and pgBackRest is no exception. In episode 1 we trace its history from its inception at Crunchy Data in 2014, the limitations of the fragile old approaches, to the concrete reasons why this file-based and WAL-based backup tool became the de facto standard in the PostgreSQL ecosystem.

The questions we'll answer: why aren't pg_basebackup + manual WAL archiving scripts enough? Why choose a physical backup approach over a logical backup? And what features make pgBackRest worth using for large databases in production?

#History and Background

#Born from the Limitations of pg_basebackup

Before pgBackRest, PostgreSQL backups were generally done with pg_basebackup plus manual scripts for WAL archiving. This pattern works for small databases, but it's fragile in three ways: backups run serially (slow for large databases), there is no deduplication between backups (every full backup stores everything), and point-in-time recovery relies heavily on hand-written shell scripts — error-prone and hard to debug.

pgBackRest was developed by Crunchy Data (2014) to solve that problem: a single tool that manages full/differential/incremental backups, WAL archiving, and restore in an integrated way — without sacrificing speed.

#Philosophy: File-Based Physical Backup

The fundamental difference from pg_dump is the approach. pg_dump is a logical backup — it exports data as SQL, cannot do PITR, and is slow for large volumes. pgBackRest chooses physical backup: copying data and WAL files, so you can recover the entire cluster (including users, permissions, and data not stored in SQL) to a precise point in time.

#Evolution and Current Status

Since its birth, the project has remained actively developed. Initially funded by Crunchy Data, it's now community-sponsored with a broad set of contributors, and has reached v2.59.0 (released 20 July 2026). Its stability and focus on reliability make it used everywhere — including as the built-in backup engine for CloudNativePG on Kubernetes (episode 20).

pgbackrest version

#Why You Need pgBackRest

#Parallel Backup and Compression

Backing up a large database isn't a serial operation. pgBackRest splits the work into many processes that copy and compress files in parallel — for terabyte-scale databases, this turns backups taking hours into minutes. We'll break down the details in episode 7.

#Continuous WAL Archiving

This is the feature that sets pgBackRest apart from a mere "snapshot." Every time PostgreSQL writes WAL, the file is archived to the repository via archive_command:

archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'

As a result, the repository always holds a continuous chain of WAL — enabling restore to any point in time, not just the last backup.

#Precise PITR Restore

With the combination of physical backup + continuous WAL, you can recover the database to the state before a bad event (for example an accidental DROP TABLE) with time, LSN, or restore point precision:

pgbackrest --stanza=main --type=time '2026-08-13 09:30:00+07' restore

We'll practice all the restore types (immediate, time, lsn, name) in episode 8.

#Retention Policy

Without retention, the repository would fill up within weeks. pgBackRest manages retention automatically: the most recent full backup is kept, while old backups and no-longer-needed WAL are expired according to the rules you set — for example repo1-retention-full=2 means always keeping 2 full backups. We'll cover this in episodes 5 and 10.

#Support for Diverse Repositories

pgBackRest supports repositories on local disk, remote hosts via SSH, and even S3-compatible object storage — one same configuration can target all of them, so off-site backups (episode 12) aren't a big project.

#Position in the PostgreSQL Backup Ecosystem

To position pgBackRest, remember the four main streams:

• pg_dump: logical backup, good for migrations, not for fast recovery.
• pg_basebackup: the built-in physical backup baseline, without WAL and retention management.
• Barman: a server-based architecture from 2ndQuadrant, solid for specific scenarios.
• WAL-G / WAL-G2: object storage-first, lightweight, but with fewer PITR and reporting features.

We'll wrap up the full comparison in episode 22.

#Conclusion

Key takeaways:

• pgBackRest was born (2014, Crunchy Data) to replace the fragile pg_basebackup + WAL archiving scripts.
• It chose the physical backup approach so it can do full PITR, not just logical dumps.
• Its main features: parallel backup, compression, continuous WAL archiving, precise PITR, retention policy, and object storage.
• It supports up to 10 PostgreSQL versions at once; it's currently active at v2.59.0 (July 2026).

In the next episode we'll dissect the core concepts and main architecture of pgBackRest — what a stanza, a repository, and the backup process (full, differential, incremental) are, and how the pgbackrest binary, the /etc/pgbackrest.conf config, and archive_command work together. This is the anatomy that will explain every command we run in the following episodes.