Interesting Issue and I like the fixes outlined. If y’all don’t mind, here’s something that worked for us.
The operator’s backup state management gets wedged, blocking all future backups even though pgBackRest itself isfine.
Deleting stuck PerconaPGBackup resources and removing the pgv2.percona.com/backup-in-progress annotation works as a one-time fix, but it’ll happen again since the root cause (operator
state tracking not handling failures gracefully) hasn’t changed across versions.
We solved this permanently by bypassing the operator’s scheduling and running backups via
external Kubernetes CronJobs that kubectl exec directly into the repo-host pod. The script
checks pgBackRest’s own lock (“held”:true in pgbackrest info --output=json) before attempting
a backup, if something’s already running, it skips gracefully instead of creating a stuck
PerconaPGBackup object.
This avoids the operator’s state tracking entirely, no PerconaPGBackup objects, no
backup-in-progress annotations, no backlog. I posted the full CronJob YAML and setup details
here in this reply. https://forums.percona.com/t/full-and-incremental-backups-conflicting-and-stopping-all-backups/33157