Summary
The PostgreSQL provider always configures pgBackRest to take backups from the primary. There is no way, through the DatabaseCluster API or otherwise, to make Everest use pgBackRest's backup-standby option so that the data is read from a replica instead.
Reading backups from a standby is a pgBackRest best practice: it offloads the primary (no extra read I/O / load on the write node during a backup) and is the recommended setup for any cluster with one or more replicas. The underlying Percona/Crunchy operator already supports it via spec.backups.pgbackrest.global (backup-standby: "y"), but Everest neither sets it nor exposes it, and it reconciles the PerconaPGCluster back to no standby config.
Current behavior
internal/controller/everest/providers/pg/applier.go → reconcilePGBackupsSpec() builds pgv2.Backups and assigns newBackups.PGBackRest.Global = pgBackrestGlobal, but never includes backup-standby. The DatabaseCluster.spec.backup schema only exposes pitr and schedules, so there's no user-facing way to opt in either.
Proposed change
PGBackRest.Global maps 1:1 to spec.backups.pgbackrest.global, which is passed straight to pgBackRest, and the operator already configures every instance as a pg-host (so pgBackRest can auto-detect primary vs standby). The change is small:
Option A — minimal (always back up from standby when replicas exist):
// reconcilePGBackupsSpec(), right after: newBackups.PGBackRest.Global = pgBackrestGlobal
if newBackups.PGBackRest.Global == nil {
newBackups.PGBackRest.Global = map[string]string{}
}
newBackups.PGBackRest.Global["backup-standby"] = "y"Option B — opt-in field (preferred): add DatabaseCluster.spec.backup.backupFromStandby *bool (default false) and gate the above on it.
Caveat
backup-standby=y requires at least one standby host, so it should be skipped for single-instance clusters.
I have Option A running on a fork (PG 17.9 / operator 2.9.0 / pgBackRest 2.58, Everest 1.15.2) and it works as expected — backups read from a replica. Happy to open a PR for Option B if the maintainers agree on the API shape.
Summary
The PostgreSQL provider always configures pgBackRest to take backups from the primary. There is no way, through the
DatabaseClusterAPI or otherwise, to make Everest use pgBackRest'sbackup-standbyoption so that the data is read from a replica instead.Reading backups from a standby is a pgBackRest best practice: it offloads the primary (no extra read I/O / load on the write node during a backup) and is the recommended setup for any cluster with one or more replicas. The underlying Percona/Crunchy operator already supports it via
spec.backups.pgbackrest.global(backup-standby: "y"), but Everest neither sets it nor exposes it, and it reconciles thePerconaPGClusterback to no standby config.Current behavior
internal/controller/everest/providers/pg/applier.go→reconcilePGBackupsSpec()buildspgv2.Backupsand assignsnewBackups.PGBackRest.Global = pgBackrestGlobal, but never includesbackup-standby. TheDatabaseCluster.spec.backupschema only exposespitrandschedules, so there's no user-facing way to opt in either.Proposed change
PGBackRest.Globalmaps 1:1 tospec.backups.pgbackrest.global, which is passed straight to pgBackRest, and the operator already configures every instance as a pg-host (so pgBackRest can auto-detect primary vs standby). The change is small:Option A — minimal (always back up from standby when replicas exist):
Option B — opt-in field (preferred): add
DatabaseCluster.spec.backup.backupFromStandby *bool(default false) and gate the above on it.Caveat
backup-standby=yrequires at least one standby host, so it should be skipped for single-instance clusters.I have Option A running on a fork (PG 17.9 / operator 2.9.0 / pgBackRest 2.58, Everest 1.15.2) and it works as expected — backups read from a replica. Happy to open a PR for Option B if the maintainers agree on the API shape.