0

My production postgresql server is currently backed up with barman using the backup_method postgres (streaming server). I would like to switch to rsync method (ssh) to benefit from better compression. Do I have to stop current process before reconfiguration, or can I modify the setup and activate it while running?

Current streaming setup:

conninfo = host=conn_host user=conn_user dbname=conn_db
streaming_conninfo = host=conn_host user=streaming_user
backup_method = postgres
streaming_archiver = on
slot_name = barman
minimum_redundancy = 3
last_backup_maximum_age = '3 DAYS'
retention_policy = 'RECOVERY WINDOW OF 31 DAYS'

Future ssh setup:

ssh_command = ssh postgres@conn_host
conninfo = host=conn_host user=conn_user dbname=conn_db
backup_method = rsync
reuse_backup = link
archiver = on
network_compression = true
minimum_redundancy = 3
last_backup_maximum_age = '3 DAYS'
retention_policy = 'RECOVERY WINDOW OF 31 DAYS'
wal_retention_policy = main
  • Why are you changing so much stuff? This is more than just switching to rsync. – jjanes May 15 at 13:50
  • I've followed a tutorial to test the rsync backup and added network_compression. I do not fully understand yet all the settings. Which one do you find are 'so much stuff'? – jean pierre huart May 15 at 14:04
  • streaming_conninfo, streaming_archiver, archiver, and slot_name are all unrelated to your choice of backup_method. – jjanes May 15 at 14:16
  • You scared me, all the settings you mention, will not be present anymore. Only the one presented as 'future setup' should be active (with the corresponding changes in postgresql.conf of the server to be backed-up). – jean pierre huart May 15 at 14:37
0

Just change the configuration. It will take effect next time a backup is started. If there is a currently executing backup it will not switch midstream. You can let it finish, or kill it and start a new one with the new configuration.

  • It worked, but it was not so evident. For the streaming setup I set max_replication_slots = 2 in the postgresql.conf. Changing it to ssh, I thought to reset such parameter to default value 0, but then impossible to restart the server. So I let it to 2 and the backup is now done via rsync. By the way, looking at the monitoring, the number of WAL files is increasing continously (critical error) is it not an indicator that WAL files are not send anymore? What can I do in this regard? – jean pierre huart May 24 at 7:13
  • Following this post I tried to find how to remove the replication_slot that was enabled for barman. I've used the following instruction in psql as user postgres: select * from pg_drop_replication_slot(slot_name name);. Now I'm able to restart my cluster with max_replication_slots = 0. I've restarted anew backup, let's see if my wal files are correctly archived now. – jean pierre huart May 24 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.