PostgreSQL backup strategies: pg_dump vs pg_basebackup vs Barman

PostgreSQL backup strategies - pg_dump vs pg_basebackup vs Barman

Choosing the right PostgreSQL backup strategy is a practical decision for every DBA. In this post I compare three common approaches — pg_dump, pg_basebackup, and Barman — showing pros and cons and real-world examples. This guidance is written from 15+ years of production PostgreSQL experience and considers compliance and regional drivers such as PDPL and Saudi Vision 2030.

Quick overview

There are two fundamental backup types: logical (object-level) and physical (file-system level). pg_dump produces logical backups (SQL or custom formats). pg_basebackup and Barman produce or manage physical backups and support Point-In-Time Recovery (PITR). Choose based on recovery objectives, backup window, and regulatory needs.

pg_dump — logical backups (best for schema migration and small datasets)

pg_dump exports database objects and data as SQL or compressed custom formats. It’s flexible for schema changes, selective restores, and cross-version migrations.

# Logical backup (custom format, parallel jobs)
pg_dump -h db.example.local -U backup_user -F c -j 4 -f /backups/mydb_$(date +%F).dump mydb

# Restore
pg_restore -h db.example.local -U restore_user -d mydb -j 4 /backups/mydb_2026-02-01.dump
  • Pros: Portable, human-readable (SQL), supports selective restore, ideal for logical migrations across versions.
  • Cons: Slow for very large databases, no native PITR, large dump files can be time-consuming to create and restore.
  • Use when: You need schema-only or per-table restores, logical upgrades, or small/medium databases where downtime is acceptable.

pg_basebackup — physical base backups (fast full copies)

pg_basebackup performs a fast, consistent physical copy of the cluster. When combined with WAL archiving (archive_mode = on) you can perform PITR to any point covered by archived WAL.

# Run a streaming base backup
pg_basebackup -h primary.example.local -D /var/lib/postgresql/basebackup -F tar -z -P -U replicator

# postgresql.conf essentials for WAL archiving
# wal_level = replica
# archive_mode = on
# archive_command = 'cp %p /archive/%f'
  • Pros: Fast to create, binary-level identical copy, supports PITR with WAL archiving, straightforward to automate.
  • Cons: Restores require a compatible PostgreSQL version and platform, less flexible for selective logical restores, requires storage for full physical images and WAL files.
  • Use when: Your RTO needs are aggressive, you need PITR, or you run large datasets where pg_dump is impractical.

Barman — enterprise backup management for PostgreSQL

Barman (Backup and Recovery Manager) is a purpose-built tool to manage physical backups and WAL archives for one or many PostgreSQL servers. It adds retention management, cataloguing, compression, encryption hooks, and automated restore workflows.

# Example barman backup command (on backup server)
barman backup mydb

# Minimal barman.conf per server (in /etc/barman.d/mydb.conf)
[mydb]
description = 'Production DB'
conninfo = 'host=primary.example.local user=barman dbname=postgres'
backup_method = postgres_basebackup
retention_policy = RECOVERY WINDOW OF 7 days

# Recommended archive_command on primary
archive_command = 'rsync %p barman@barman.example.local:/var/lib/barman/incoming/%f'
  • Pros: Centralised management, built-in retention and recovery policies, easy PITR, notification hooks, supports multi-server setups, integrates with SSH and cloud storage (S3-compatible) used in regional cloud deployments.
  • Cons: Additional component to manage, requires access configuration and monitoring, learning curve for custom restore flows.
  • Use when: You run multiple clusters, require centralised retention and reporting, or need a managed backup catalog that supports compliance auditing.

How to choose — practical guidance

  • If you need schema-level portability or are migrating between major versions, use pg_dump (or pg_dumpall for globals).
  • If you need fast full backups and PITR, use pg_basebackup with continuous WAL archiving.
  • If you must manage backups for many systems, want retention policies, and need audited restores and reporting, use Barman as the backup orchestration layer.

Typical production pattern I use: automated pg_basebackup for nightly full backups + WAL archiving to a Barman server for PITR and retention; and periodic pg_dump exports for schema/versioned artifacts and test/dev refreshes.

Operational considerations and compliance

For Saudi enterprises and GCC organisations, consider PDPL requirements and the NCA cybersecurity framework when designing backup storage and encryption. Encrypt backups at rest and in transit; if you use PGEE (PostgreSQL Enterprise Edition by CYBERTEC) you can use TDE and data masking to add protection layers. For migrations or DR scenarios consider Carbonite Double-Take for near-zero downtime replication alongside backups.

  • Encryption: Use filesystem encryption or Barman hooks to encrypt backup files. Ensure keys are managed per PDPL policies.
  • Testing: Regularly perform restore drills. A backup without a tested restore is a false sense of security.
  • Retention: Define retention aligned to compliance and business requirements (e.g., PDPL-related retention windows and Vision 2030 digitisation policies).
  • Automation & Monitoring: Automate backups and alert on failures. Barman includes health checks; integrate with your monitoring stack and incident flows.

Sample, end-to-end WAL archive snippet

# primary postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /var/lib/postgresql/wal_archive/%f && cp %p /var/lib/postgresql/wal_archive/%f'
archive_timeout = 60

Combine the above with a Barman server receiving WALs and periodic base backups. Maintain retention and automate 'barman check' and restore tests.

Conclusion: There is no single best method. Use pg_dump for logical portability, pg_basebackup for fast physical backups and PITR, and Barman when you need centralised, auditable backup management. Align your backup architecture with PDPL, the NCA framework, and your organisation's Recovery Time Objective (RTO) and Recovery Point Objective (RPO).


Ready to Transform Your Database Infrastructure?

Worlber helps companies across Saudi Arabia and the Middle East build reliable, secure, and cost-effective database solutions.

📧 Email us: contactus@worlber.com

🌐 Visit: worlber.sa/contact

📞 Call: Talk to our database experts today

Worlber — Your trusted PostgreSQL partner in the Middle East

Read more