Activity for Barman for PostgreSQL
-
Barman for PostgreSQL released /release_3.17.0/barman-3.17.0.tar.gz.md5
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Gunnar created ticket #113
is this replaced by github.com/EnterpriseDB/barman from v 2.13?
-
thx for claryfying. Especially as it also contains confirmation that it is possible (and how) to run barman withouth root priviledges (as per i.e. this thread). Also, obviousely all the aliassing (as mentioned above) becomes obsolet this way.
-
thx for claryfying. Especially as it also contains confirmation that it is possible (and how) to run barman withouth root priviledges (as per i.e. this thread).
-
Gabriele Bartolini posted a comment on ticket #94
I am happy to explain the reasons why we chose root:root permissions for the system wide configuration. There is already a way to easily override that: by default, the file in the HOME directory of Barman has a higher priority (~barman/.barman.conf). See: https://docs.pgbarman.org/release/2.15/barman.5.html#configuration-file-locations As a result I am not a fan of changing the default permissions of the system wide configuration - my devops side of the brain tells me that that folder should be managed...
-
hm, my working hypothesis for now would be that as long the barman user can find and access a valid barman.conf she should be happy with that and operate. The default /etc/barman/barman.conf can be owned by whomever as it never plays any role on such a system I would say. If you are lazy enough you create an alias for the barman user like alias barman='barman -c /path/to/barman.conf naturally I am happy to accepts any explanation on what may be wrong with this understanding if it was wrong though....
-
Greg Clough posted a comment on ticket #94
@Gunnar , even if you can specify a local config, shouldn't the default configs be owned by barman:barman instead of root? As it stands, we need to give root or sudo vi /etc/barman.conf priv to the DBA's, when all they should need is sudo su - barman to do everything they need. Right?
-
this issue might be obsolete: I just learned from this ticket that you can point barman to any config file with a simple -c option like barman -c /path/to/barman.conf
-
this issue might be obsolete: I just learned from this ticket that you can point barman to any config file with a simple -c option like barman -c /post/to/barman.conf
-
+1 to making barman non-root-able
-
Petr Vyhnalek created ticket #112
Barman cloud backup list exception S3 Glacier Deep Archive
-
Ian Foster posted a comment on ticket #111
I found the following in the documentation so this is expected behaviour: http://docs.pgbarman.org/release/2.12/ NOTE: Unfortunately, it is not currently possible to enable both WAL archiving and streaming from the standby due to the way Barman performs WAL duplication checks and an undocumented behaviours in all versions of PostgreSQL.
-
Barman check show duplicate errors
-
Justinas Balciunas posted a comment on ticket #110
I think you get this error because Barman 2.12 does not support PG 13, and here's why - with PostgreSQL 13 wal_keep_segments is replaced by wal_keep_size.
-
Justin Thomas posted a comment on ticket #103
So I set this aside for much of 2020 but spent the last week tracking it down. It would appear that this particular error is related to running the backup command from the terminal and using the & to run it in the background. Specifically, the sys.stdout association between the barman backup process and the console/logfile broke because of how I was running the backup. I was attempting to test a backup using a command similar to the following: barman backup pg & running this backup instead from the...
-
Biljana Jovanoski posted a comment on ticket #109
I have changed the owner of /etc/barman.d and after that the backup finished
-
Alberto Semprebon Rocha created ticket #110
wal_keep_segments error using PostgreSQL 13
-
Backup failed with "error": "failure copying files ([Errno 5] Input/output error)", barman log ok
-
I got the same error, data files do get copied, streaming of wal is fine, but the backup is failed.Db is large 1.7T How did you resolve your problem?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Marco Nenciarini committed [262186]
New `backup_method` option: `local-rsync`
-
Gabriele Bartolini committed [53bc43]
Avoid corrupting boto connection in worker processes
-
Version set to 2.12
-
Avoid any attempt to connect to PostgreSQL during tests
