David Steele

There's not a lot to go on here, but the error appears to have been transient since the next expire succeeds. I suspect that this situation would be helped by...

It looks like the pg_stop_backup() function did not return within `db-timeout` (default 30 minutes) and when pgBackRest tried to cancel it the connection had been dropped. We need to work...

Good, looks like it was transient. I'm going to keep this open so we can improve that error message, though.

First, run pg_checksums (https://www.postgresql.org/docs/13/app-pgchecksums.html) to be sure this is not a false positive. That seems unlikely, but it is best to check. If pg_checksums gives the same result you have...

> this is a production cluster hence I am afraid to make it down as it mentioned as mandatory. You may not have much choice in the end, but for...

My feeling is we'd need to allow concurrent backups both from a PG host and from a source repo. A destination repo would only allow one backup at a time,...

> Because that won't work on two separate VM repos Not sure what you mean by this?

> nothing is said about an upgrade from recent versions, like 2.35 to 2.39. That is because nothing special needs to be done. > v1 to v2 is already so...

> As the database in question is very large for security we store 24h of wal file inside pg_wal and from time to time we delete these wals (after they...

OK, just wanted to clarify what you are doing. So yeah, `archive_command` is not very fast and async pgbackrest is able to get ahead of it. Unfortunately `archive_command` is exec'd...