When running a PostgreSQL database in a High Availability (HA) cluster, it’s easy to assume that having multiple nodes means your data is safe. But HA is not a replacement for backups. If someone accidentally deletes important data or runs a wrong update query, that change will quickly spread to all nodes in the cluster. Without proper safeguards, that data is gone everywhere. In these cases, only a backup can help you restore what was lost.

The case mentioned above isn’t the only reason backups are important. In fact, many industries have strict compliance requirements that make regular backups mandatory. This makes backups essential not just for recovering lost data, but also for meeting regulatory standards.

Barman is a popular tool in the PostgreSQL ecosystem for managing backups, especially in High Availability (HA) environments. It’s known for being easy to set up and for offering multiple types and modes of backups. However, this flexibility can also be a bit overwhelming at first. That’s why I’m writing this blog to break down each backup option in a simple and clear way, so you can choose the one that best fits your business needs.

1. Backup Type in Barman

Barman primarily supports three backup types through various combinations of backup methods. The table below highlights the/z key differences between them

Feature	Full Backup	Incremental Backup	Differential backup
Data Captured	An entire database at a specific point in time.	Changes since the last backup (full, differential, or incremental).	Changes since the last full backup.
Relative To	N/A (it’s the foundation)	Previous backup (full or incremental).	The last full backup.
Backup method supported	Rsync, postgres	Rsync, postgres	postgres
Backup Time	Longest	Shortest (initially)	Shorter than full, potentially longer than some incrementals.
Storage Usage	Highest	Lowest per backup (depends on backup method used)	Moderate (fewer files than many incrementals)
Recovery Speed	Fastest (self-contained)	Slowest (needs base + all incrementals in chain)	Faster than incremental (needs base + one differential)
Backups Needed for Restore	The full backup itself.	The full base backup + all subsequent incremental backups up to the desired point.	The full base backup + the latest differential backup.
Frequency	Less frequent (e.g., weekly, monthly)	More frequent (e.g., daily, hourly)	Moderately frequent (e.g., daily)
Data Redundancy	Low (if it’s the only copy)	Higher (if multiple incrementals capture the same unchanged data from the base)	Moderate (captures all changes since the last full)
Complexity of Restore	Most complex but handled by Barman (managing and applying the chain)	Most complex but handled by Barman (managing and applying the chain)	Moderate

2. Backup methods 

Barman primarily supports three backup modes. rsync, streaming, and snapshot. The table below highlights the key differences between rsync and postgres backup modes as they are commonly used 

Backup method	Rsync	Postgres
Data transfer via	rsync	pg_basebackup
Incremental backup	Supported (File level)	Supported (Block-level from PostgreSQL-17 onwards)
WAL files backup	archive_command/pg_recievewal(streaming)	archive_command/pg_recievewal(streaming)
Backup types supported	Full, Incremental	Full, Incremental, Differential

NOTE: To perform recovery for PostgreSQL incremental backups, we will need to first combine all the backups using pg_combinebackup. It will generate a synthetic full backup, which can be used for recovery in the same way as a standard full backup. –local-staging-path switch needs to be provided with barman restore command

3. Pros and Cons of Using Barman

Here are some of the key advantages and disadvantages of using Barman.

3.1. Pros

• Enables recovery to any point in time within the retention period. Refer Recovery — Barman documentation for details.
• Copies the entire data directory using file-level synchronization, typically for base backups.
• Streams WAL records in real time from the primary to the replica/barman for continuous replication/backup.
• Ensures minimal data loss in case of failures.
• Simplifies backup management for multiple PostgreSQL servers.
• Barman manages backup retention and reduces storage overhead.

3.2. Cons

• Requires reconfiguration of settings in the event of an HA switchover/failover.
• Continuous WAL archiving can consume significant storage space in case of high-activity databases.
• Transferring WAL files and backups can consume network bandwidth.
• If the barman server fails, backup operations will cease.
• While PITR is very powerful, large databases can take significant time to restore, which is a physical limitation.

I hope this breakdown helped you better understand Barman and its backup options. Choose the one that fits your setup best and don’t forget to test your backups regularly!

You can also check out a webinar I gave on Barman best practices here.