As database environments grow in size and complexity, managing efficient and reliable backups becomes critical—especially in enterprise setups where downtime and data loss are not an option. pgBarman offers powerful features for automating and managing PostgreSQL backups, including support for incremental backups that can dramatically reduce storage consumption.
In this blog post, we’ll walk through a real-world scenario where we transitioned from a daily full backup strategy to a more efficient model: retaining just one full backup with remaining incremental backups. This change was driven by storage constraints and aimed at maintaining recovery capabilities without compromising retention or performance. If you’re looking for a complete configuration, click here
We’ll explore:
- How to configure and enable incremental backups in pgBarman
- The storage savings achieved through deduplication
- How Barman handles backup retention and promotes incremental backups to full when needed
Whether you’re a DBA looking to optimize your backup strategy or exploring pgBarman for the first time, this guide will offer practical insights and hands-on examples.
Configuring Incremental backup
pgBarman supports file-level incremental backups, allowing substantial space savings by reusing unchanged data from previous backups. We all know that the server configuration file would usually be located in /etc/barman.d/ . We can take the incremental in one of the following two ways:
#Adding reuse_backup = link in configuration file
[barman@localhost ~]$ vi /etc/barman.d/edb-server.conf
reuse_backup = link
#Using through the barman command
barman backup --reuse-backup=link edb-serverWe have server configuration file edb-server . Let’s see the how we are getting the incremental backup
#Running the backup command after adding the reuse_backup = link to edb-server.conf
[barman@localhost ~]$ barman backup edb-server
WARNING: No backup strategy set for server 'edb-server' (using default 'concurrent_backup').
Starting backup using rsync-concurrent method for server edb-server in /var/lib/barman/backups/base/20250422T040627
Backup start at LSN: 0/11000028 (000000020000000000000011, 00000028)
Starting backup copy via rsync/SSH for 20250422T040627
Copy done (time: 1 second)
Asking PostgreSQL server to finalize the backup.
Backup size: 67.1 MiB. Actual size on disk: 8.7 KiB (-99.99% deduplication ratio).
Backup end at LSN: 0/11000100 (000000020000000000000011, 00000100)
Backup completed (start time: 2025-04-22 04:06:27.804322, elapsed time: 5 seconds)
Processing xlog segments from streaming for edb-server
000000020000000000000010
000000020000000000000011If we observe the above output of the command, we see deduplication happens (-99.99%). Let’s see the size of the backups on the disk.
[barman@localhost ~]$ cd /var/lib/barman/backups/base/
[barman@localhost base]$ ls -ltr
total 0
drwxr-xr-x. 3 barman barman 18 Apr 22 00:39 20250422T003958
drwxr-xr-x. 3 barman barman 18 Apr 22 01:03 20250422T010218
drwxr-xr-x. 3 barman barman 18 Apr 22 01:06 20250422T010514
drwxr-xr-x. 3 barman barman 18 Apr 22 02:13 20250422T021317
drwxr-xr-x. 3 barman barman 18 Apr 22 04:06 20250422T040627
[barman@localhost base]$ du -sh *
61M 20250422T003958
8.5M 20250422T010218
8.5M 20250422T010514
2.9M 20250422T021317
80K 20250422T040627We can see the old and first(full) backup 20250422T003958 is of 61M . Remaining 4 backups are incremental backups.
Retention Policy
Assuming a retention policy is in place, what happens to the oldest (first) full backup that is currently available?
For the demo purpose , I have configured a retention policy as 5 backups.I currently have 5 backups: 1 full backup followed by 4 incremental backups.
# Checking the list of backups that are available
[barman@localhost ~]$ barman list-backup edb-server
WARNING: No backup strategy set for server 'edb-server' (using default 'concurrent_backup').
edb-server 20250422T040627 - R - Tue Apr 22 04:06:17 2025 - Size: 67.1 MiB - WAL Size: 0 B #Incremental backup
edb-server 20250422T021317 - R - Tue Apr 22 02:13:07 2025 - Size: 67.1 MiB - WAL Size: 48.3 KiB #Incremental backup
edb-server 20250422T010514 - R - Tue Apr 22 01:06:09 2025 - Size: 67.1 MiB - WAL Size: 27.3 KiB #Incremental backup
edb-server 20250422T010218 - R - Tue Apr 22 01:03:13 2025 - Size: 63.6 MiB - WAL Size: 1.5 MiB #Incremental and second oldest backup
edb-server 20250422T003958 - R - Tue Apr 22 00:40:12 2025 - Size: 60.1 MiB - WAL Size: 1.5 MiB #Full and oldest backupHere, we will initiate a new backup with the expectation that the oldest full backup (20250422T003958) will be removed, and the second oldest incremental backup (20250422T010218) will be promoted to a full backup.
#Taking a backup
[barman@localhost base]$ barman backup edb-server
WARNING: No backup strategy set for server 'edb-server' (using default 'concurrent_backup').
Starting backup using rsync-concurrent method for server edb-server in /var/lib/barman/backups/base/20250422T052117
Backup start at LSN: 0/13000028 (000000020000000000000013, 00000028)
Starting backup copy via rsync/SSH for 20250422T052117
Copy done (time: 1 second)
Asking PostgreSQL server to finalize the backup.
Backup size: 67.1 MiB. Actual size on disk: 848.2 KiB (-98.77% deduplication ratio). # Deduplication applys
Backup end at LSN: 0/13000138 (000000020000000000000013, 00000138)
Backup completed (start time: 2025-04-22 05:21:18.069937, elapsed time: 4 seconds)
Processing xlog segments from streaming for edb-server
000000020000000000000012
000000020000000000000013
[barman@localhost base]$ barman list-backup edb-server
WARNING: No backup strategy set for server 'edb-server' (using default 'concurrent_backup').
edb-server 20250422T052117 - R - Tue Apr 22 05:21:07 2025 - Size: 67.1 MiB - WAL Size: 0 B
edb-server 20250422T040627 - R - Tue Apr 22 04:06:17 2025 - Size: 67.1 MiB - WAL Size: 32.3 KiB
edb-server 20250422T021317 - R - Tue Apr 22 02:13:07 2025 - Size: 67.1 MiB - WAL Size: 48.3 KiB
edb-server 20250422T010514 - R - Tue Apr 22 01:06:09 2025 - Size: 67.1 MiB - WAL Size: 27.3 KiB
edb-server 20250422T010218 - R - Tue Apr 22 01:03:13 2025 - Size: 63.6 MiB - WAL Size: 1.5 MiB
edb-server 20250422T003958 - R - Tue Apr 22 00:40:12 2025 - Size: 60.1 MiB - WAL Size: 1.5 MiB - OBSOLETE We can see the backup 0250422T003958 is obsolete. Let see whether it is converting the second backup 20250422T010218 into a full backup or not.
[barman@localhost base]$ ls -ltr
total 0
drwxr-xr-x. 3 barman barman 18 Apr 22 01:03 20250422T010218
drwxr-xr-x. 3 barman barman 18 Apr 22 01:06 20250422T010514
drwxr-xr-x. 3 barman barman 18 Apr 22 02:13 20250422T021317
drwxr-xr-x. 3 barman barman 18 Apr 22 04:06 20250422T040627
drwxr-xr-x. 3 barman barman 18 Apr 22 05:21 20250422T052117
[barman@localhost base]$ du -sh *
64M 20250422T010218
8.5M 20250422T010514
2.9M 20250422T021317
80K 20250422T040627
912K 20250422T052117We can see the second oldest backup (20250422T010218) is converted into full backup.I have configured a retention policy as 5 backups for the demo purpose. Alter this parameter retention_policy as per your requirement.
Summary
In this blog, we demonstrated how PostgreSQL backup strategies can be optimized using pgBarman’s incremental backup feature. By configuring reuse_backup = link, we enabled file-level incremental backups, allowing pgBarman to reuse unchanged data blocks from previous backups. This approach significantly reduces storage usage, as shown by real backup sizes dropping due to deduplication. We also explored how pgBarman’s retention policy manages backups automatically removing the oldest full backup once the retention limit is reached and promoting the next incremental backup to full. This ensures data consistency while maintaining a lightweight and efficient backup chain. Such a setup is especially beneficial for environments facing storage constraints, offering a practical and scalable solution for maintaining reliable and space-efficient backups.