Recovering a database from its own S3 backups

Lars Kellogg-Stedman

unread,

Mar 9, 2022, 9:08:19 PM3/9/22

to Postgres Operator

I have PGO configured to back up to an S3 repository. That works great.

A virtual calamity occurred, and I had to redeploy my database cluster. Same name, same namespace, same backup configuration. I'd like to recover from the S3 backups, but pgbackrest reports:

ERROR: [028]: backup and archive info files exist but do not match the database
HINT: is this the correct stanza?
HINT: did an error occur during stanza-upgrade?

This error is discussed in https://github.com/CrunchyData/postgres-operator/issues/2559, but I don't think that's quite the same issue. The behavior I want here is to restore from the existing backups...and then continue backing up to the same S3 location.

How do I do that?

TJ Moore

unread,

Mar 14, 2022, 4:53:34 PM3/14/22

to Postgres Operator, Lars Kellogg-Stedman

Hello Lars,

More information regarding your PGO version and environment would be helpful, but an immediate suggestion, assuming you are using PGO v5.0.5, would be to use the "Clone From Backups Stored in S3 / GCS / Azure Blob Storage" option described in the "Disaster Recovery and Cloning" documentation, found here: https://access.crunchydata.com/documentation/postgres-operator/5.0.5/tutorial/disaster-recovery/

As noted for the example given:
"In this example, we are creating a new cluster which is also backing up to the same S3 bucket; only the spec.backups.pgbackrest.global field has changed to point to a different path. This will ensure that the new elephant cluster will be pre-populated with the data from hippo’s backups, but will backup to its own folders, ensuring that the original backup repository is appropriately preserved."

So this should work for your use case, as described.

Regards,

TJ Moore

Lars Kellogg-Stedman

unread,

Mar 14, 2022, 8:06:06 PM3/14/22

to Postgres Operator, TJ Moore, Lars Kellogg-Stedman

More information regarding your PGO version and environment would be helpful, but an immediate suggestion, assuming you are using PGO v5.0.5, would be to use the "Clone From Backups Stored in S3 / GCS / Azure Blob Storage" option described in the "Disaster Recovery and Cloning" documentation, found here: https://access.crunchydata.com/documentation/postgres-operator/5.0.5/tutorial/disaster-recovery/

We were running 5.0.4 when I asked the question, installed via the OpenShift operator hub -- which appears to have *just today* picked up 5.0.5, so I'll give that a try tomorrow and see how it works out.

Ben Blattberg

unread,

Mar 31, 2022, 1:07:59 PM3/31/22

to Postgres Operator, Lars Kellogg-Stedman, TJ Moore

Just wanted to check in on this issue: did it get resolved?

Reply all

Reply to author

Forward