Lv.3 IntermediatePostgreSQL

2026.05.1428 min readLv.3 Intermediate

SeriesPostgreSQL Backup & Recovery Complete Guide · Part 5/6View series hub

PostgreSQL Backup & Recovery Part 5 — Enterprise Backup Tools Compared: pgBackRest vs Barman vs WAL-G

Pg_basebackup and WAL archiving fall short in large-scale production environments where parallel processing, retention policies, encryption, a backup catalog, and cloud storage integration are required. pgBackRest excels at block-level incremental backup and delta recovery for large OLTP workloads above 500 GB; Barman shines with centralized management of multiple instances for DBA teams; WAL-G offers the simplest path to object storage for Kubernetes and cloud-native environments — and the starting point for choosing any of them is a backup strategy built on RPO/RTO, the 3-2-1 rule, and regular recovery drills, not a feature comparison table.

Series overview

• Part 1 — Backup Fundamentals and Strategy
• Part 2 — Logical Backup — pg_dump & pg_dumpall in Practice
• Part 3 — Physical Backup — pg_basebackup and WAL Archiving
• Part 4 — PITR (Point-in-Time Recovery) Implementation Guide
• Part 5 — Enterprise Backup Tools Compared — pgBackRest vs Barman vs WAL-G (current)
• Part 6 — Backup Automation & Monitoring, and Recovery Drills (upcoming)

Table of Contents

1. Introduction — The Limits of Built-in Tools
2. Three Tools at a Glance
3. pgBackRest — The De Facto Standard for High-Performance Production
4. Barman — The Leader in Centralized Multi-Server Management
5. WAL-G — The Cloud-Native Backup Choice
6. Deep Comparison — Four Decisive Differences
7. Situational Selection Guide
8. Side-by-Side PITR Recovery Commands
9. Universal Best Practices — Regardless of Which Tool You Choose
10. Closing — Strategy Matters More Than the Tool

1. Introduction — The Limits of Built-in Tools

Parts 3 and 4 covered how to set up PITR with pg_basebackup and WAL archiving. That combination is solid, but it hits its ceiling fast as production scale grows.

The practical limitations of pg_basebackup

- No parallelism → backup times balloon beyond a few hundred GB
- No incremental or differential backup (v17 native incremental is still early-stage)
- No retention policy management
- No encryption
- No centralized management of multiple servers
- No backup catalog or history
- No direct cloud object storage support

This is exactly the gap that third-party enterprise backup tools fill. This part provides a deep comparison of the three most widely used tools in the PostgreSQL ecosystem as of 2026 — pgBackRest, Barman, and WAL-G.

2. Three Tools at a Glance

3. pgBackRest — The De Facto Standard for High-Performance Production

3.1 Overview

pgBackRest is now the de facto standard for production PostgreSQL backup as of 2026. Written in C, it delivers excellent performance and operates reliably even at multi-terabyte scale. It is also bundled with Percona Distribution for PostgreSQL.

3.2 Key Features

Block-level incremental backup is the feature that most clearly differentiates pgBackRest from competing tools. Because only changed 8 KB blocks — not entire files — are backed up, backup size and duration can be dramatically reduced for large databases. The --delta option applies the same principle during recovery, restoring only changed blocks to speed up the process.

The Stanza concept manages each PostgreSQL cluster independently. A single pgBackRest configuration can cover multiple clusters.

Multi-Repository support lets you back up to local disk and S3 simultaneously, implementing a 3-2-1 strategy with a single tool.

3.3 Installation and Basic Configuration

# Ubuntu/Debian
sudo apt install pgbackrest

# RHEL/CentOS
sudo dnf install pgbackrest

# /etc/pgbackrest/pgbackrest.conf

[global]
# Local backup repository
repo1-path=/var/lib/pgbackrest

# S3 repository (optional: for multi-repository setup)
repo2-type=s3
repo2-s3-bucket=my-pg-backups
repo2-s3-region=ap-northeast-2
repo2-s3-key=AKIAIOSFODNN7EXAMPLE
repo2-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
repo2-s3-endpoint=s3.amazonaws.com
repo2-path=/pgbackrest

# Retention policy
repo1-retention-full=4          # keep 4 full backups
repo1-retention-diff=14         # keep 14 differential backups

# Compression (zstd recommended: balanced speed and ratio)
compress-type=zstd
compress-level=3

# Encryption
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=MyStrongEncryptionPassphrase

# Parallel processes (half of CPU core count recommended)
process-max=4

# Logging
log-level-console=info
log-level-file=detail
log-path=/var/log/pgbackrest

[main]                          # stanza name
pg1-path=/var/lib/postgresql/17/main
pg1-user=postgres
pg1-port=5432

# Add to postgresql.conf
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
wal_level = replica

Security note: Avoid storing S3 credentials in plain text inside pgbackrest.conf. Prefer an EC2 IAM Role or environment-variable-based approach instead.

3.4 Key Commands

# Initialize stanza (one-time)
sudo -u postgres pgbackrest --stanza=main stanza-create

# Validate configuration
sudo -u postgres pgbackrest --stanza=main check

# Full backup
sudo -u postgres pgbackrest --stanza=main --type=full backup

# Differential backup (changes since last full backup)
sudo -u postgres pgbackrest --stanza=main --type=diff backup

# Incremental backup (changes since last backup)
sudo -u postgres pgbackrest --stanza=main --type=incr backup

# List backups
sudo -u postgres pgbackrest --stanza=main info

# Restore to latest backup
sudo -u postgres pgbackrest --stanza=main restore

# PITR to a specific point in time
sudo -u postgres pgbackrest --stanza=main restore \
  --type=time \
  --target="2026-04-14 14:34:59+09" \
  --target-action=promote

# Delta restore (restore only changed files → faster)
sudo -u postgres pgbackrest --stanza=main restore --delta

# Verify WAL archive
sudo -u postgres pgbackrest --stanza=main check \
  --archive-timeout=60

3.5 Example Backup Schedule

# crontab -u postgres -e

# Every Sunday at 1 AM: full backup
0 1 * * 0 pgbackrest --stanza=main --type=full backup

# Every day at 1 AM except Sunday: differential backup
0 1 * * 1-6 pgbackrest --stanza=main --type=diff backup

# Every hour on the hour: incremental backup
0 * * * * pgbackrest --stanza=main --type=incr backup

3.6 Ideal Environments

• Large production environments with DB sizes above 500 GB
• Mission-critical systems that need block-level incremental backup to minimize RPO
• Hybrid on-premises and cloud storage configurations
• Deployments integrated with PostgreSQL professional support (Percona, Crunchy Data)

4. Barman — The Leader in Centralized Multi-Server Management

4.1 Overview

Barman (Backup and Recovery Manager) is a Python-based backup tool developed and maintained by EnterpriseDB (EDB). Its defining characteristic is centralized management of multiple PostgreSQL instances from a dedicated backup server — a strength that shines in enterprise environments operating many DB servers.

4.2 Key Features

Centralized architecture: A dedicated Barman server collects and manages backups from all PostgreSQL servers. DBA teams gain a single point of control to monitor and manage backup status across the entire infrastructure.

Streaming-Only mode: Since Barman 2.0, streaming via pg_basebackup and pg_receivewal is the recommended default. It works without SSH, and pg_receivewal streams WAL in real time before each WAL segment completes, reducing the risk of WAL loss.

barman check command: A built-in health check command verifies the full backup environment status in one shot, making day-to-day operations more convenient.

4.3 Architecture

4.4 Installation and Basic Configuration

# Install on Barman server
sudo apt install barman barman-cli

# Install client on PostgreSQL servers
sudo apt install barman-cli

# Barman server: /etc/barman.conf (global config)
[barman]
barman_user = barman
barman_home = /var/lib/barman
log_file = /var/log/barman/barman.log
log_level = INFO
compression = gzip

# /etc/barman.d/pg-primary.conf (per-server config)
[pg-primary]
description = "Primary PostgreSQL Server"

# PostgreSQL connection info
conninfo = host=pg-primary user=barman dbname=postgres

# Streaming replication connection info
streaming_conninfo = host=pg-primary user=streaming_barman

# Streaming mode settings
backup_method = postgres      # use pg_basebackup
streaming_archiver = on       # WAL streaming via pg_receivewal
slot_name = barman            # replication slot name
create_slot = auto            # auto-create slot

# Retention policy
retention_policy = RECOVERY WINDOW OF 7 DAYS
minimum_redundancy = 1

# Compression
compression = gzip

-- Create Barman-dedicated users on the PostgreSQL server
CREATE USER barman WITH SUPERUSER PASSWORD 'barman_pass';
CREATE USER streaming_barman WITH REPLICATION PASSWORD 'streaming_pass';

4.5 Key Commands

# Full server health check
barman check pg-primary
# Sample output:
# Server pg-primary:
#   PostgreSQL: OK
#   is_superuser: OK
#   streaming replication: OK
#   wal_level: OK
#   replication slot: OK
#   archive_mode: OK
#   continuous archiving: OK

# Run a backup
barman backup pg-primary

# List backups
barman list-backup pg-primary

# Show backup details
barman show-backup pg-primary latest

# PITR to a specific point in time
barman recover pg-primary latest \
  /var/lib/postgresql/17/main \
  --target-time "2026-04-14 14:34:59" \
  --remote-ssh-command "ssh postgres@pg-primary"

# Recover to a specific transaction ID
barman recover pg-primary latest \
  /var/lib/postgresql/17/main \
  --target-xid 1234567 \
  --remote-ssh-command "ssh postgres@pg-primary"

# Delete a backup
barman delete pg-primary 20260414T010000

# Clean up WAL archive (apply retention policy)
barman cron

4.6 Ideal Environments

• Environments managing five or more PostgreSQL servers from a single backup server
• Organizations with a DBA team and enterprise-level compliance requirements
• Traditional on-premises or hybrid infrastructure
• Deployments requiring EDB commercial support

5. WAL-G — The Cloud-Native Backup Choice

5.1 Overview

WAL-G is a cloud-first backup tool written in Go, developed by Citus Data (now Microsoft) and the successor to WAL-E. It is optimized for pushing backups directly to object storage — AWS S3, GCS, Azure Blob Storage, and more.

Its configuration is relatively simple, and it supports multiple database engines including MySQL, MongoDB, and Redis alongside PostgreSQL, making it a natural fit for mixed-DB environments. It is widely used in Kubernetes and container deployments; several Kubernetes PostgreSQL operators such as the Zalando Postgres Operator adopt WAL-G as their default backup tool.

5.2 Key Features

Direct cloud archiving: Setting archive_command to wal-g wal-push %p sends WAL files directly to object storage without routing through a separate server. No dedicated backup server is needed.

Delta backup: The WALG_DELTA_MAX_STEPS environment variable controls how many delta backups are allowed between full backups. Delta backups store only changed files, saving storage.

Parallel compression and upload: Multi-core parallel compression and S3 multipart uploads are supported, keeping large backup runs fast.

5.3 Installation and Basic Configuration

# Download the latest binary from GitHub Releases
WAL_G_VERSION="v3.0.8"
curl -L "https://github.com/wal-g/wal-g/releases/download/${WAL_G_VERSION}/wal-g-pg-ubuntu-20.04-amd64.tar.gz" \
  -o /tmp/wal-g.tar.gz
tar -xzf /tmp/wal-g.tar.gz -C /usr/local/bin/
chmod +x /usr/local/bin/wal-g

# Environment variable config file (envdir approach recommended)
mkdir -p /etc/wal-g.d/env

# AWS S3 settings
echo "s3://my-pg-backups/wal-g"  > /etc/wal-g.d/env/WALG_S3_PREFIX
echo "ap-northeast-2"             > /etc/wal-g.d/env/AWS_REGION
echo "AKIAIOSFODNN7EXAMPLE"        > /etc/wal-g.d/env/AWS_ACCESS_KEY_ID
echo "wJalrXUtnFEMI..."            > /etc/wal-g.d/env/AWS_SECRET_ACCESS_KEY

# Compression method (zstd or brotli recommended)
echo "zstd"                        > /etc/wal-g.d/env/WALG_COMPRESSION_METHOD

# Max delta steps between full backups (required for delta backups to work)
echo "5"                           > /etc/wal-g.d/env/WALG_DELTA_MAX_STEPS

# Parallel upload/download count
echo "4"                           > /etc/wal-g.d/env/WALG_UPLOAD_CONCURRENCY
echo "4"                           > /etc/wal-g.d/env/WALG_DOWNLOAD_CONCURRENCY

# PGDATA path
echo "/var/lib/postgresql/17/main" > /etc/wal-g.d/env/PGDATA

chown -R postgres:postgres /etc/wal-g.d/env
chmod 600 /etc/wal-g.d/env/*

# Add to postgresql.conf
archive_mode = on
archive_command = 'envdir /etc/wal-g.d/env wal-g wal-push %p'
wal_level = replica

5.4 Key Commands

# Full base backup (pushed directly to S3)
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g backup-push /var/lib/postgresql/17/main

# Delta backup (changed files only)
# WALG_DELTA_MAX_STEPS must be set for this to take effect
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g backup-push --full=false /var/lib/postgresql/17/main

# List backups
sudo -u postgres envdir /etc/wal-g.d/env wal-g backup-list

# Restore to latest backup
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g backup-fetch /var/lib/postgresql/17/main LATEST

# Restore to a specific backup by name
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g backup-fetch /var/lib/postgresql/17/main base_20260414T010000Z

# Apply retention policy (keep last 7 full backups)
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g delete retain FULL 7 --confirm

# Verify WAL archive integrity
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g wal-verify integrity timeline

# postgresql.conf: PITR recovery settings
restore_command = 'envdir /etc/wal-g.d/env wal-g wal-fetch %f %p'
recovery_target_time = '2026-04-14 14:34:59 Asia/Seoul'
recovery_target_action = 'pause'

5.5 Ideal Environments

• Kubernetes or container-based PostgreSQL deployments
• Public cloud-native infrastructure on AWS, GCP, or Azure
• Teams running mixed DB stacks (PostgreSQL alongside MySQL, MongoDB, etc.)
• Teams that want a backup system built entirely on object storage — no dedicated backup server
• Small to mid-sized DevOps teams that prioritize configuration simplicity

6. Deep Comparison — Four Decisive Differences

6.1 Backup Method: Block-Level vs File-Level

This is the most technically significant difference.

pgBackRest (block-level incremental)
  Full backup:        1 TB
  Incremental backup: only changed 8 KB blocks → can reach single-digit GB

Barman / WAL-G (file-level incremental)
  Full backup:        1 TB
  Incremental backup: entire changed files → limited benefit when files are large

In OLTP patterns where writes concentrate on a few large tables, pgBackRest's block-level incremental backup is overwhelmingly more efficient.

6.2 Recovery Speed (Delta Restore)

pgBackRest's --delta option compares the current data directory against the backup and restores only changed files or blocks. When most files are intact — for example, after a logical error or isolated table corruption — this is far faster than a full restore.

6.3 Architecture: Centralized vs Distributed

Barman: Centralized monitoring and unified policy enforcement, but the backup server itself can be a single point of failure.

pgBackRest: Supports a more flexible topology, but configuration grows complex when managing multiple servers.

WAL-G: Simplest infrastructure and closest to a serverless model, but cross-server unified monitoring is difficult.

6.4 Operational Complexity vs Features

Low <------------------------------------> High
WAL-G          Barman          pgBackRest
(simple setup)  (moderate)      (feature-rich, complex)

The right choice depends on your team's PostgreSQL expertise and operational maturity. A tool packed with features is a liability if the team cannot operate it reliably.

7. Situational Selection Guide

DB < 100 GB, small/mid-sized team, cloud environment
  -> WAL-G (simple setup, direct S3 integration)

DB 100 GB–1 TB, single server, PITR required
  -> pgBackRest (balanced performance and features)

DB > 1 TB, OLTP, minimize RPO
  -> pgBackRest + block-level incremental backup

5+ PostgreSQL servers, centralized management required
  -> Barman (optimized for centralized management)

Kubernetes / container environment
  -> WAL-G (native integration with Zalando Operator, etc.)

Mixed DB stack (PostgreSQL + MySQL, etc.)
  -> WAL-G (multi-database support)

Enterprise compliance, EDB support required
  -> Barman

8. Side-by-Side PITR Recovery Commands

All three tools support PITR, but their command structures differ. Knowing them in advance prevents confusion during an incident.

# pgBackRest: PITR to a specific point in time
sudo -u postgres pgbackrest --stanza=main restore \
  --type=time \
  --target="2026-04-14 14:34:59+09" \
  --target-action=promote \
  --delta   # delta restore for faster recovery

# Barman: PITR to a specific point in time (requires remote SSH)
sudo -u barman barman recover pg-primary latest \
  /var/lib/postgresql/17/main \
  --target-time "2026-04-14 14:34:59" \
  --remote-ssh-command "ssh postgres@pg-primary"

# WAL-G: restore base backup, then set PITR parameters in postgresql.conf
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g backup-fetch /var/lib/postgresql/17/main LATEST

# Then add to postgresql.auto.conf:
# restore_command = 'envdir /etc/wal-g.d/env wal-g wal-fetch %f %p'
# recovery_target_time = '2026-04-14 14:34:59 Asia/Seoul'
# recovery_target_action = 'promote'
# touch recovery.signal -> restart PostgreSQL

9. Universal Best Practices — Regardless of Which Tool You Choose

These principles apply regardless of which tool you select.

① Always verify backups after they complete

# pgBackRest
pgbackrest --stanza=main verify

# WAL-G
wal-g wal-verify integrity timeline

# Barman
barman check pg-primary

② Set a clear retention policy

Unlimited retention causes storage to balloon; a window that is too short makes it impossible to recover from logical errors discovered late. Set a minimum of 30 days, or follow your organization's compliance requirements.

③ Conduct actual recovery drills on a regular schedule

No matter how capable the tool, teams that are unfamiliar with the recovery procedure will make mistakes under pressure. Schedule at least one full recovery drill per quarter.

④ Attach alerts to backup monitoring

A backup that fails silently is the most dangerous situation of all. Route backup success/failure notifications to a channel your team actually watches — Slack, email, PagerDuty, or equivalent.

10. Closing — Strategy Matters More Than the Tool

pgBackRest, Barman, and WAL-G are all excellent tools. Any of them, properly configured and operated, can form the foundation of a reliable backup system.

But something matters more than the choice of tool.

"A backup tool is the means of executing a strategy. The tool cannot replace the strategy."

Define your RPO/RTO targets, follow the 3-2-1 rule, and regularly verify your recovery capability. Choose the tool that best executes that strategy — not the other way around.

The next part brings everything together: setting up backup automation, building a monitoring system, and planning regular recovery drills to close out the series.

References

• pgBackRest official documentation
• Barman official documentation (v3.18)
• WAL-G GitHub
• Top Open-Source Postgres Backup Solutions in 2026 — Bytebase (Jan 2026)
• PostgreSQL Backup Tools Comparison — DEV Community (Jan 2026)
• Automating Backups and DR: pgBackRest vs Barman — Severalnines (Nov 2025)
• Best PostgreSQL Backup Solutions in 2026 — PostgresGUI (Feb 2026)
• pgBackRest File Bundling and Block Incremental Backup — Crunchy Data
• PostgreSQL Backup and Recovery Management using Barman — Stormatics (Feb 2026)