Percona Backup for MongoDB (PBM) only work with Percona MongoDB Server.
If you simply rename the Mongodb image in Helm Bitnami to Percona Mongodb, the helm script will not work. Since the initialization and management scripts are included in their docker image by Bitnami.
Thank you for your answer, we have an active bitnami/mongodb-sharded so we can’t just migrate the data. As far as I can tell the filesystem copies, and mongodump are discouraged as they do not work with sharded clusters ( version 4.2+ ). Is our option only the MongoDB Atlas? Do you think is it at all possible to back up this data?
Apologies, will do, my confusion was because when I wanted to install the operator on the kubernetes cluster, the docs pointed me to the mongodb backup doc, and the Percona server was part of the installation.
My apologies again, but I was looking at the wrong docs, the documentation links are fine.
I’m still not sure I can use the Percona operator to my existing bitnami deployment, the documentation of the operator suggests that backup of that is not really possible as stated here:
Hi again. You are right you probably can not use the backup directly within your current Bitnami deployment. My recommendation would be to migrate from the Bitnami deployment to the Percona Operator one. There is a detailed comparison here Comparison with other solutions - Percona Operator for MongoDB that explains why it makes sense to do so once you need shards or really efficient backup. The migration could be based on a dump and restore to the new cluster.
Thank you for clearing up, this confirmed my suspicion.
Unfortunately mongodump and restore, and a even filesystem snapshots are discouraged after mongodb 4.2+ as they lose the atomicity.
Thank you again for clearing up.
This is correct if you are approaching them as backup methods, but they can still be used for a cold migration. Plus additional methods exist for doing a hot migration. So if I may ask is there a specific issue that obstructs you from replacing Bitnami with the Percona Operators in your environment?
We are doing exactly that and installed percona server and we are using minio for local hosting.
However I have ran into trouble with the backup deployment as a lot of the old tickets the starting deadline exceeded when starting. For some reason it can’t find the cluster ( even though the name of the cluster is correct ), or there is something wrong with the secret, but I think that is an issue with either minio keys or the way backup objects should look like.
Does the backup config really must have aws_acces_control_id, and aws_acces_control_key?
The percona server’s backup-agent pods are giving me this error constantly, even though I followed every instruction, including JIRA tickets that said to upgrade version, I use version 1.14.0.
2023-08-14T10:55:13.000+0000 E [agentCheckup] check storage connection: storage check failed with: get S3 object header: NoCredentialProviders: no valid providers in chain. Deprecated.
For verbose messaging see aws.Config.CredentialsChainVerboseErrors
I tried creating different acces keys in minio and using that, even tried changing the keys to lowercase as someone suggested, but nothing worked so far.