Re: Barman versus pgBackRest - Mailing list pgsql-general

From Achilleas Mantzios
Subject Re: Barman versus pgBackRest
Date
Msg-id 5aef9b65-d7a9-6a77-149d-8693071c1eae@matrix.gatewaynet.com
Whole thread Raw
In response to Re: Barman versus pgBackRest  (David Steele <david@pgmasters.net>)
Responses Re: Barman versus pgBackRest  ("Jehan-Guillaume (ioguix) de Rorthais" <ioguix@free.fr>)
List pgsql-general
Hello,

One strong point of barman IMHO is transparently converting an incremental backup to a full backup for retention purposes, so retention specification is far more liberal than with pgbackrest, and configuring for incremental backup does not pose any limitations to the schedule of backups.
In our environment our net connection to the remote site (repo) is extremely lousy, (although within Switzerland if that makes any difference), so with pgbackrest a full backup of our 1.3TB db, would take about 2 days ,lets say set in cron weekly on sunday, (Sunday 1:00->Tuesday),  then I would have to take incr backups from Wednesday->Saturday. And we would have to also take a full backup next Sunday.
With pgbarman we had to set :
reuse_backup = link
retention_policy = RECOVERY WINDOW OF 14 DAYS
and just perform regular backups. So for barman every backup can be used as a base for the next backup, which achieves fast backups and reduced disk space.
In pgbackrest one has to be explicit about the retention of both full backups and diff backups.
it would be nice in pgbackrest to only have incremental backups and let the system do the necessary management (converting incremental to full) transparently and asynchronously, e.g.via cron.
I have read about the --repo-hardlink option.
"
This gives the appearance that each backup is a full backup at the file-system level
"
So could we just take a first full backup and then switch permanently to incr backups?

-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

pgsql-general by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Re: Weird behaviour of ROLLUP/GROUPING
Next
From: AI Rumman
Date:
Subject: Postgres Automated Failover