original conf directory not respected by barman restore and repmgr restore

[gplv2]

There is an annoying issue with barman taking backups from instances that have a separate conf directory where config files live in instead of in the data directory.

Although barman takes a fine backup, restoring is hellish as it does not respect the original design where conf files can be in a different dir than the data one.

It would be nice to have a way to tell barman (on restore perhaps) to put config files into a specific directory.

This also is an issue when using repmgr to clone from barman , kinda making it unusable when you are not using the standard way to configure PG.

Not sure what the best solution is here, but I would assume a good place to start is to keep the original layout of the backed up server instead of defaulting through barman backup to the stock way to place files.

It makes existing startup scripts fail. I tried fixing this with a post_recover_hook script but I find this not to be an ideal solution.

Thanks for input on this

[richyen]

@gplv2 I can take a hack at this. What would be a good test/use case for what you're describing? Are you symlinking postgresql.conf or are you making some other kind of customization for conf file location?

[gplv2]

Hi,

Sorry took me long to respond. Where I work (city of Brussels) we run a lot of postgresql databases on many machines and also often several instances of postgresql on the same machine. a typical layout would be:

/srv/postgresql/11/many11 ... /srv/postgresql/14/ellie14 ...

lrwxrwxrwx  1 postgres postgres   32 Nov 22  2019 backup -> /srv/backup/postgresql/11/many11
drwxr-xr-x  2 postgres postgres   69 Nov  9 09:44 conf
drwx------ 19 postgres postgres 4096 Apr  7 00:00 data
lrwxrwxrwx  1 postgres postgres   29 Nov 21  2019 log -> /var/log/postgresql/11/many11
drwxr-xr-x  3 postgres postgres   55 Nov 22  2019 scripts

So it's not symlinked, it's just in a separate conf directory and not intermixed with data. Barman and repmgr work well on the backup/clone part as they have support for this. But when it comes to restoring it from barman or taking a repmgr clone from barman, the server is restored and config files are put in the data directory.

It would just be perfect to preserve the original layout when restoring no matter why the configs are replaced outside of data, I never really liked that mix anyway personally, it was like this when arriving here, I think it's better more intuitive too. Our toolstacks also expect those to be in their own directory, but after restore with barman, we need to modify the system to a workable state ( either we tackle postgresq, meaning downtime again or we adapt all scripts/crontabs, tools). I prefer the former.

There are many good reasons in keeping conf away from data . It's kinda cool barman and repmgr support using it, but unfortunate that they don't restore 1 on 1 .

That is perhaps my biggest ?. Since were taking physical backups with barman, it is logic and makes sense to exactly restore the backed-up instances imho. An option to override the config data dir like during backup would probably be enough imho. Let me know if I can assist further

Thanks. Glenn