for stanza containing own repo1-path info gives no output

[ikzelf]

pgbackuprest version 2.36
rhel8

cat /etc/pgbackrest/pgbackrest.conf
[global]
backup-standby=y
process-max=3
start-fast=y

repo1-retention-full-type=time
repo1-retention-full = 7
repo1-retention-archive-type=full
repo1-path = /var/lib/pgbackrest/repo1

this works and is ok for most of our databases.

I have a few that should be written to a different location on the same server so I figured: give that a repo1-path:
cat /etc/pgbackrest/conf.d/datalab.conf
[datalab]
pg1-host = dbhost1
pg2-host = dbhost2
pg1-path = /datalab/data
pg2-path = /datalab/data

repo1-path = /var/lib/pgbackrest/others

pgbackrest stanza-create --stanza datalab did work OK -> created structures only in the /var/lib/pgbackrest/others directory.
pgbackrest backup --stanza= datalab --type=incr worked OK -> backup plus archives written as expected
pg_switch_wal() from the database worked OK -> archive arrives on expected location
pgbackrest info --output json | jq '.[].name' NOT OK -> no mention of datalab

when explicitly mentioning the stanza there is output. I was hoping that pgbackuprest info would report on all defined stanzas.
pgbackrest info --stanza datalab --output json|jq '.[].name'
"datalab"

Question: did I hit a bug or a feature?
I was hoping that the info command would also report the backup data of the databases writing to the others path.

[pgstef]

Hi,

That's unfortunately a known/normal behavior. repo* options should, IMHO, be a global resource.

Currently (and AFAIK for both technical and performance reasons), the info command will only load the global settings, not per-stanza settings (unless --stanza is provided).

FWIW, there's a project card tracking that behavior.

Given you have multiple repositories, you should list each one of them separately with 2 info command calls. (Probably 2 configs files should be best, but you could also use the command line setting to overload the repo-path.)

Hope this helps,
Kind Regards

[ikzelf]

Thanks for your response pgstef,

I am glad the behavior is known. At the same time a tiny bit sad about this because now I have to add a bunch of extra scripting to get it all working and instead of relying on a great info command I need to list directories, find stanzas and list them all separately, which for sure will be slower and more error prone. For simplicity I would like to stay with a global config.

From what I understood, if I put 2 repo path's in the global config, this would mean that the backups would be written to both path's, which is exactly what I don't want. Just a simple separation. Is my understanding about this duplication correct?

[pgstef]

I am glad the behavior is known. At the same time a tiny bit sad about this because now I have to add a bunch of extra scripting to get it all working and instead of relying on a great info command I need to list directories, find stanzas and list them all separately, which for sure will be slower and more error prone. For simplicity I would like to stay with a global config.

You're talking about automatic stanza names discovery. Since you already configured it, you should probably already know it...
To get the list from your config, that's running 2 commands (or with providing --repo1-path or use 2 separated config files and providing --config). Or simply parsing your config files yourself to avoid an extra call to the repos (that might even be faster than using the info command).

From what I understood, if I put 2 repo path's in the global config, this would mean that the backups would be written to both path's, which is exactly what I don't want. Just a simple separation. Is my understanding about this duplication correct?

You mean using repo1 and repo2 options? It depends on the commands actually. There are a few examples here or even here.
The backup command only send a backup to 1 repo, which you have to specify with --repo. But archives are sent to all repos defined. That's not what you want to do.

Here, you're talking about a dedicated repo for a dedicated cluster. That means having a specific configuration for that cluster imo.

Edit:
I understand it could be handy to have a "list-stanza" command or something but I'm not sure it would be very easy to implement with the current parsing system. So I'm just trying to give you a way to get it with the current version ;-)

[ikzelf]

Thanks Stefan,

I appreciate your brain work for me🙏

From what I now see I only need a second toplevel config for the info command. All other things seem to work fine, all coming from the include config in /etc/pgbackrest/conf.d/ When going this way, am I going for a disaster?

I guess that if I use an other toplevel config, that I must somehow reflect that on the database server. It already was a bit of a surprised to find that I needed to specify the pg1-path on the database server, where it would be able to fetch it from the database.

I think this https://github.com/ikzelf/my-zabbix-templates/tree/main/pgbackrest needs some changes to tackle this.

[pgstef]

From what I now see I only need a second toplevel config for the info command. All other things seem to work fine, all coming from the include config in /etc/pgbackrest/conf.d/ When going this way, am I going for a disaster?

Since you're using the include files, it just merge all configs. I'm not sure which one would take precedence then. (never tried to be honest)
Given you're using a backup server, moving config files would probably complicate everything since you'd need to add extra --config and --repo-host-config to your commands. Probably simply using --repo1-path in the info command itself would be faster in your case.

I think this https://github.com/ikzelf/my-zabbix-templates/tree/main/pgbackrest needs some changes to tackle this.

I don't have any knowledge about zabbix but I received a PR in check_pgbackrest to support it. The discovery script there seems a bit simpler. Probably adding a loop to look at various repo paths would be enough.

[ikzelf]

I guess that in the end info uses the repoN-path and it lists the contents there. It's not using the included files at all.

I can imagine those included files are only needed for stanza-create.

So I go for separate top level files, keep the repo1-path in the stanza files. For the info I will loop around the top level files and join the output.

No root/sudo or other privs needed.

[ikzelf]

I think I got this working. Same for the zabbix monitoring. Both backup and monitoring now handle alle configurations found in /etc/pgbackrest/*.conf
I am quite happy with this !