Feature request: Read-only config flag

[udf2457]

Unless I've missed it in the docs, there appears to be no "read-only" config flag available.

Use-case:

Say for example, I want to bring up a fork/clone of a database for testing purposes.
Clearly the way to do this would be to do a PITR off an existing pgbackrest repo.
Without a "read-only" config flag, I leave myself up to the possibility of a "fat finger" moment where I enter the wrong pgbackrest command and end up mangling my repo.
A "read-only" config flag would act as a safeguard mechanism to ensure that any command that makes modifications to a repo would be denied.

[pgstef]

Hi,

I reckon this kind of feature would be handy to facilitate recovery testing. However, this is way more complicated than what it sounds.

In example, imagine setting up this "read-only" flag in the config file, what would (from a security point of view) prevent any user to modify that afterwards or even overwrite it with command-line argument (or even an environment variable).
Given how the config management system works, I don't think it would really be a "safe" feature.

What you should do is configure that RO access at the mount/sharing time, system wide.
Example, if you use an NFS storage, only mount it in RO on the test server. Or if you use a cloud thing, just give it access to a RO user... You'll be better protected by using it system side imo.
(That's also why the --archive-mode=off option is quite handy)

Kind Regards

[udf2457]

So read-only S3-compatible will work ? The initial steps like stanza-create and check won't try any write stuff ? That's good to know.

I missed the bit about --archive-mode=off

[pgstef]

You don't need to run stanza-create since you'll share an existing stanza, so you definitely don't want to run it.
The check command is triggering a new WAL archive and check that this new WAL archive is successfully pushed by PG to the repo. So that too, you wouldn't want it to happen if you share a production repo on a test server.

When you want to test a recovery, the only command that should be run are the restore command (obviously) and the archive-get which would be used by PG restore_command (and the info command too eventually). Everything else would try to push data to the repo, which you don't want to happen.

[udf2457]

Ah ok, that sort of thing wasn't at all clear from my reading of your docs which, understandably, takes a route of showing "create and restore to the same". Unless I missed it there isn't an example in the docs of a greenfield restore-only ?

[pgstef]

There is no "restore-only" docs because that's a very specific use-case. You basically need to understand what each command is used for and not just follow through some basic quick-starts.

Recovery testing will also highly depend on the repository type and access. The only generic advice that we can give is the one I gave above. I mean you have a production backup repository and want to restore a backup from that repo on a test server, well you need to configure pgBackRest to access (in RO) this already existing repository and use the restore command.

[dwsteele]

This is basically what the start/stop command do. When a stanza is stopped it is not possible to write to the repo. That's probably not too clear from the docs, though.

Of course --archive-mode=off is also a good choice.

[pgstef]

This is basically what the start/stop command do. When a stanza is stopped it is not possible to write to the repo. That's probably not too clear from the docs, though.

Oh, yeah you're right! I don't know why but I (wrongly) thought it would also create a stop file in the repo itself and we wouldn't want the production cluster to not be able to write to the repo while we're doing test restores 😅

The doc indeed says Does not allow any new pgBackRest processes to run but the archive-get and restore command should be able to work. So it would be exactly what the OP would need here, and we should indeed probably improve the documentation about this stop command (i.e. list some interesting uses cases for it like this one) 🤔