Barman: What's the best way to switch from backup_method postgres (streaming) to rsync (ssh)?

Question

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

• jjanes: Why are you changing so much stuff? This is more than just switching to rsync.
• jean pierre huart: 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'?
• jjanes: streaming_conninfo, streaming_archiver, archiver, and slot_name are all unrelated to your choice of backup_method.
• jean pierre huart: 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).

Answer 1

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.

• jean pierre huart: 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: 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.