PG Operator 3.0.0+ compatibility with certified pgBackRest images

PostgreSQL Percona Operator for PostgreSQL
1

Description:

The percona/percona-pgbackrest:2.58.0-2 image is mentioned in the Percona certified images documentation for the operator v3.0.0.

Unfortunately, using this image is blocked by a fatal mismatch between the pgbackrest path used by the operator (/opt/crunchy/bin/pgbackrest) and the actual path in the image (/usr/bin/pgbackrest). As a result, the backup container fails with the following error:

Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "/opt/crunchy/bin/pgbackrest": stat /opt/crunchy/bin/pgbackrest: no such file or directory

I tried this with 3.1.0 with the same result. Am I missing something important? It looks like a working image for 3.0.0 does not exist and backups are broken, but I haven’t found any related open issues in the operator repo or Percona Jira, despite it being a pretty critical function.

Steps to Reproduce:

Percona PostgreSQL Operator 3.0.0
Deploy CR PerconaPGCluster with

spec:
  backups:
    pgbackrest:
      image: percona/percona-pgbackrest:2.58.0-2
      # ... setup backup ...

Than check backup pod logs

Version:

Percona PostgreSQL Operator 3.0.0
pgBackRest image perconalab/percona-pgbackrest:2.58.0-2

Logs:

*-backup-* pods finish in StartError state with
Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "/opt/crunchy/bin/pgbackrest": stat /opt/crunchy/bin/pgbackrest: no such file or directory

Expected Result:

Backup pods stars and do backups

Actual Result:

No backups are prodused

2

Hi @a.veselov.s

I couldn’t reproduce your issue by starting a fresh 3.0.0 cluster.

Could you please provide the following information to help us investigate this issue?

  • What crVersion are you using?
  • Is this an existing cluster, or was the cluster newly created?
  • What image is being used in the initContainer of your backup Job?
  • Are you using a CR version older than 2.7.0?
  • Did the initContainer terminate successfully?

You can use the following commands to collect the relevant information:

kubectl get pg <your-cluster-name> -o yaml | yq '.spec.crVersion'

kubectl get job <your-backup-job> -o yaml | yq '.spec.template.spec.initContainers'

kubectl get pod <your-backup-pod> -o jsonpath='{range .status.initContainerStatuses[?(@.name=="pgbackrest-init")]}{.name} exit={.state.terminated.exitCode} reason={.state.terminated.reason}{"\n"}{end}'

Thanks!

3

Oh, that’s exactly what I was missing! The crVersion value was being substituted from an outdated template and was indeed older than version 2.7.0. Many thanks for highlight!