Where is the backup built from

In the cr.yaml file, the backup agent image is percona/percona-server-mongodb-operator:1.9.0-backup. Where is it built from? I suppose that it’s more or less like this : GitHub - percona/percona-backup-mongodb: Percona Backup for MongoDB. But since you are not using the usually backup tag, there is a difference between the standalone version and the operator version?

1 Like

Hello @vhphan .

Here is the docker file: percona-backup-mongodb/Dockerfile.k8s at main · percona/percona-backup-mongodb · GitHub

Thanks. Also are there any “easy” way to add my self-signed CA cert to the image’s trust store? I have a cert error while trying to do backup-restore due to my s3-compatible storage is internal.

I tried to rebuilt the image with my cert included and it worked. I just wonder if there is an easier way to do so.

Unfortunately no for now. PBM does not support TLS verification skipping.

We have this ticket in our operators’ backlog: https://jira.percona.com/browse/K8SPSMDB-473
And this in ticket for PBM to add this support: https://jira.percona.com/browse/PBM-680

1 Like

I see. I can always build my own image from the original Percona’s one.

There is a problem to it, that the operator’s version service will detect difference between my backup version and the Percona-recommended one and will automatically switch back to recommended version. Sure I can turn off the SmartUpdate strategy but then I won’t get the update for MongoDB anymore. Any advice? I guess I can build my own version service that mimic Percona’s one, with some modification.

1 Like

Building a version service looks like an overkill. The simplest would be to get a cert from a trusted CA. It can be a free one, like letsencrypt. Is it an option?

1 Like

Yeah, it’s definitely an option. But you know big company, asking to change the cert of a service can be longer than building something of our own.

Thanks for you help, let’s consider this is solved.

1 Like