Configuring retention policies in Barman
In our previous article we went through describing what retention policies are and how they can be enforced on your PostgreSQL server backups with Barman 1.2. In this post, we will go through the configuration aspects.
For the sake of simplicity, we assume a typical scenario which involves taking full backups once a week through the “barman backup” command. Suppose you want to automatically keep the latest 4 backups and let Barman automatically delete the old ones (obsolete).
The main configuration option for retention policies in Barman is “retention_policy” which can be defined both at global or server level. If you want all your servers by default to keep the last 4 periodical backups, you need to add in the general section of Barman’s configuration file the following line:
[barman] ... // General settings retention_policy: REDUNDANCY 4
When the next “barman cron” command is executed (every minute if you installed Barman using RPMs or Debian/Ubuntu packages), Barman checks for the number of available full periodical backups for every server, order them in descending chronological order (from the most recent to the oldest one) and deletes backups from the 5th position onwards.
In case you have several servers backed up on the same Barman host and you want to differentiate the retention policy for a specific server, you can simply edit that server configuration section (or file, see “Managing the backup of several PostgreSQL servers with Barman“) and define a different setting:
[malcolm] description = Malcolm Rocks ssh_command = ssh malcolm conninfo = host=malcolm port=5432 user=postgres dbname=postgres retention_policy: REDUNDANCY 8
However, Barman allows systems administrators to manage retention policies based on time, in terms of recovery window and point of recoverability. For example, you can set another server to allow to recover at any point in time in the last 3 months:
[angus] description = Angus Rocks ssh_command = ssh angus conninfo = host=angus port=5432 user=postgres dbname=postgres retention_policy: RECOVERY WINDOW OF 3 MONTHS
Make sure you have enough space on the disk to store all the WAL files for every server you back up, and always monitor “barman check” through your alerting tools (such as Nagios/Icinga/Zabbix/etc.).
Current implementation of retention policies in Barman has some limitations: retention policies are managed only automatically (not manually – this would require to create a “barman delete –obsolete” command, for example) and there is no decoupling yet between full backups and WAL archive transactional logs (we have already thought of the “wal_retention_policy” option, but at the moment it is not handled).
More detailed information on retention policies can be found on Barman’s documentation website.
You can think of barman as a tool on-top of the basic incremental backup/restore functions offered by postgresql mentioned earlier. It allows creating/restoring backups via cmdline in one shot and keeps track of created backups and retention policies. So whatever you wan to do, use the barman command and you’re done.
I do not quite understand what the function retention_policy. Since I have tried various configurations
a – retention_policy: REDUNDANCY 2
b – retention_policy = RECOVERY WINDOW OF 4 DAYS
and both I can recover backup from the date of the last backup you create. regardless of the 4 days (if settings b)
my questions are as follows:
What is the utility parameter retention_policy?
Does retention_policy parameter is responsible for performing a backup of the database?
Hi,
I use PgBarman (version 1.2.3) in production for a while in production, and it works very well!
Yet, I’m facing a new challenge, because my applicative support team wants to implement a new backup rotation strategy (GFS mode).
We want to keep:
2 last daily backups (We keep tape backups for 10 days)
4 last weekly backups (Sunday backup for example)
6 last monthly backup (1st Sunday of each month for example)
Is it possible to configure this retention policy?
Perhap’s should I have to upgrade PgBarman to a newer version, in order to face such a challenge.
Thanks in advance for your feedback,
Best regards,
Thomas
Hi Thomas,
the grandfather-father-son algorithm is not yet available in Barman, even though you are advised to upgrade to 1.4.0 (which implements incremental backup).
However, it is a feature that can definitely be added in Barman.
Cheers,
Gabriele
So it is in the roadmap? Can we contribute somehow with code/testing?
Hello Gabriele,
Thanks a lot for your feedback.
I’m looking with a lot of interest on PgBarman version 1.4.0 for the backup deduplication and incermental backup.
I hope we will be able to migrate soon!
Regards,
Thomas