PostgreSQL backup strategy: pg_dump, pg_basebackup, and pgBackRest compared

Your backup tool determines your RPO, RTO, and whether you can restore to a point in time or only to the backup moment. This guide compares logical dumps via pg_dump, built-in physical copies via pg_basebackup, and the third-party tool pgBackRest. PostgreSQL 17 introduced native incremental physical backups. Operators must decide whether built-in capabilities are sufficient or whether to adopt alternatives such as Barman or WAL-G.

pg_dump and pg_dumpall: logical portability

pg_dump and pg_dumpall use an MVCC snapshot to produce a logically consistent SQL archive without blocking reads. Use --table or --schema for selective extraction. Parallel dumps use --jobs with directory format (-Fd) or custom format (-Fc):

pg_dump -Fd -j 4 -f /backup/dir dbname

Restore selectively with pg_restore.

Portability is the main strength: SQL and DDL output lets you restore across major versions and migrate individual objects. The sequential scan also acts as a rudimentary corruption check for table contents, but it does not validate indexes. Indexes are rebuilt during restore, which usually dominates recovery time for large databases. pg_dump does not support Point-in-Time Recovery (PITR); the restore target is the snapshot moment. On large databases, the long-running MVCC snapshot defers VACUUM and contributes to table and index bloat.

Use pg_dump for schema migrations, partial extracts, and databases under roughly 100 GB where RTO allows index rebuilds. Run dumps against a hot standby with hot_standby_feedback = on to avoid VACUUM interference on the primary.

pg_basebackup: built-in physical consistency

pg_basebackup creates a byte-exact copy of the entire cluster over a replication connection. The connecting role needs superuser or the REPLICATION attribute. Plain mode (-Fp) writes files directly to a target directory; tar mode (-Ft) produces base.tar (with optional compression), pg_wal.tar, and a backup_manifest recording file sizes, modification times, and checksums. This is a physical backup: it copies data files as they exist on disk. Validate integrity before relying on the backup:

pg_verifybackup --manifest-path /backup/backup_manifest /backup

As of PostgreSQL 17, pg_basebackup supports --incremental=old_manifest_file to capture only blocks modified since a prior full backup. This requires summarize_wal = on, which spawns a background summarizer process and writes .summary files to pg_wal/summaries/. Retention is governed by wal_summary_keep_time, defaulting to 10 days. Incremental backups must be combined with pg_combinebackup before they can be used for recovery.

The built-in approach has gaps: no retention management, no remote storage abstraction, and no parallel restore. For multi-terabyte databases, serial restore directly extends RTO.

pgBackRest: the erstwhile standard

For years, pgBackRest was the standard for PostgreSQL physical backup. The project reached end-of-life in April 2026 after David Steele stepped away following Crunchy Data’s acquisition by Snowflake. v2.58.0 (January 2025) is the final release. The project will not receive security patches, bug fixes, or new-version compatibility updates, though it remains functional and supports PostgreSQL up to version 18 per the project’s ten-version policy.

pgBackRest supports block-level incremental and differential backups, parallel backup and restore, page checksum validation, S3/Azure/GCS object storage, encryption, backup verification via the verify command, and concurrent backups on different repositories. It does not require a PostgreSQL extension.

Operators still running pgBackRest should plan migration over the coming months. Two configuration changes in recent releases are worth noting: the archive-max-mb option was removed and replaced by archive-push-queue-max with different semantics, and the default backup-user changed from backrest to pgbackrest. Consider active alternatives for new infrastructure.

Active alternatives for 2026

With pgBackRest at end-of-life, two active tools fill the gap.

Barman, maintained by EnterpriseDB, provides centralized backup management for multiple PostgreSQL servers, WAL archiving, retention policies, PITR, and cloud object storage support. Currently at version 3.19.0 (May 2026), recent releases add tamper-proof immutable backup storage, and the CloudBackupExecutor integrates with the PostgreSQL backup API for direct cloud uploads. Barman fits traditional SSH-based infrastructure and compliance-heavy environments.

WAL-G is a Go-based tool originally from Yandex, now community-maintained. It is cloud-storage-native and operationally simpler than pgBackRest, with heavy adoption in Kubernetes and cloud-native environments. It supports PostgreSQL, MySQL, and SQL Server, with configurable upload concurrency defaulting to 16 streams. It lacks some pgBackRest features such as page-checksum validation during backup.

Comparison matrix

Choosing by RPO and RTO

• RPO under 5 minutes. Physical backup with continuous WAL archiving is mandatory. pg_dump captures only a single point in time.
• RTO under 30 minutes for databases over 100 GB. pg_dump is likely too slow due to index rebuilds. Use pg_basebackup with WAL archiving, or a dedicated tool like Barman or WAL-G.
• Cross-version migration. pg_dump or pg_dumpall is the only supported path. Physical backups require identical major versions.
• Cloud-native or Kubernetes. WAL-G has the simplest operational footprint. Barman fits traditional SSH-based topologies.
• Compliance or immutability requirements. Barman’s tamper-proof storage features target cyber-insurance and regulatory use cases.
• Minimal external dependencies. pg_basebackup is built-in. For PostgreSQL 17 and later, native incremental backups close much of the gap that previously drove pgBackRest adoption for large databases.
• Operational cost. pg_basebackup avoids external dependencies but requires you to build retention, scheduling, monitoring, and archival push. Barman and WAL-G add complexity but include retention policies and remote storage integration.

Operator gotchas and recent changes

• pgBackRest migration urgency. Existing deployments are functional but should be migrated. The project reached end-of-life in April 2026, and security vulnerabilities discovered after that date will not be patched.
• WAL summarizer disk usage. Enabling summarize_wal = on for PostgreSQL 17 incremental backups spawns a background summarizer and writes .summary files to pg_wal/summaries/. High-write workloads can consume significant disk space. Monitor this path with du -sh $PGDATA/pg_wal/summaries/ and tune wal_summary_keep_time to exceed your full-backup interval.
• Incremental chain fragility. An incremental backup chain is only as strong as its oldest required full backup. If any manifest or base backup in the chain is lost or corrupted, pg_combinebackup cannot reconstruct a valid restore image. Retention policies must protect the entire chain. Verify combined output with pg_verifybackup before archiving the result.
• Primary-only incrementals. PostgreSQL 17 incremental backups must run against the primary and cannot be taken from a standby. This limits applicability on clusters where the primary is already heavily loaded.
• No parallel restore in native tooling. pg_basebackup reconstructs backups serially. For terabyte-scale databases, this directly extends RTO compared to multi-process restore tools.
• pg_dump and VACUUM interference. Long-running pg_dump processes hold an MVCC snapshot that prevents VACUUM from reclaiming dead tuples, accelerating table and index bloat. Schedule dumps during low-write windows or run them against a replica with hot_standby_feedback = on.

How Netdata helps

Netdata surfaces backup-related risk through PostgreSQL and infrastructure correlation.

• WAL generation rate and pg_wal disk usage. Sudden growth alerts you to replication slot retention or archiving failures before the volume fills.
• pg_wal/summaries/ size on PostgreSQL 17+. Track disk consumption from the WAL summarizer to avoid unplanned growth when incremental backups are enabled.
• Replication slot lag. Inactive slots are a leading indicator of disk exhaustion. Alert when active = false and LSN drift grows.
• Autovacuum health. Correlate autovacuum worker activity with dead tuple ratios. A long-running pg_dump or forgotten transaction appears here as vacuum deferral.
• Backup age monitoring. Track time since last verified backup. An untested backup that runs on schedule is still a liability.

Related guides

• How PostgreSQL actually works in production: a mental model for operators
• PostgreSQL ALTER TABLE blocked: zero-downtime DDL patterns
• PostgreSQL autovacuum blocked by long-running transaction: detection and fix
• PostgreSQL autovacuum not running: detection, causes, and fixes
• PostgreSQL autovacuum tuning: per-table thresholds for high-churn workloads
• PostgreSQL blocking queries: finding the root blocker in a lock cascade
• PostgreSQL checkpoint storms: detection, causes, and tuning
• PostgreSQL: checkpoints are occurring too frequently – what to tune
• PostgreSQL connection exhaustion: detection, diagnosis, and prevention
• PostgreSQL connection refused: pg_hba, listen_addresses, and TCP diagnosis
• PostgreSQL: database is not accepting commands to avoid wraparound data loss
• PostgreSQL dead tuples piling up: why autovacuum can’t keep up