Exclude specific collections from the PerconaServerMongoDBBackup

MongoDB Percona Operator for MongoDB
1

I’m trying to exclude some of the collections from the backup using PerconaServerMongoDBBackup as shown below. But it is always dumping all the collections. Could someone point me to the correct configuration to exclude specific collections from the backup?

I’m using the PSMDB operator version 1.10

apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDBBackup
metadata:
finalizers:
- delete-backup
name: my-backup
spec:
psmdbCluster: my-cluster
storageName: my-storage
excludeCollection: admin.*
excludeCollectionsWithPrefix: admin
compressionType: gzip
args:
–excludeCollectionsWithPrefix=“admin”

2

Hello @siva ,

it is not supported by the Operator yet. We recently added it in PBM: [PBM-790] Backup and restore a single collection - Percona JIRA

Please tell me more about your use case.

I have created this jira issue: [K8SPSMDB-894] Add support for partial restores - Percona JIRA
Please also upvote it on our public roadmap: [K8SPSMDB-894] Add support for partial restores · Issue #90 · percona/roadmap · GitHub

3

Hi Sergey,

Thanks for your reply.

Here is the scenario for the selective backup/restore requirement.

To support Disaster Recovery scenarios, the whole ETCD data(using velero) and MongoDB data(using PSMDB Operator) are backed up.

While restoring the ETCD data on a fresh cluster, sometimes the MongoDB PODs (rs, cfg and mongos) go in a continuous restart loop. While debugging the log we found that the restart issue could be due to a mismatch in secrets and the credentials stored in admin DB. But, we couldn’t figure out the exact root cause.

So, to work around this issue, we tried creating the MongoDB PODs (cfg, rs, and mongos) before ETCD restore. This time the MongoDB PODs are created with a new random generated secrets and the DB is accessible with the newly created secrets. There are no restart issue observed when the PODs pre created before ETCD restore.

After the ETCD restore is complete, tried restoring the MongoDB data using PSMDB Operator and found that the admin DB is restored with the old secrets and accessible only using the old credentials.
Since the DB contains old secrets and the K8S PSMDB secrets contain new secrets, the PSMDB PODs go in a restart loop.

We need a solution to overcome this MongoDB PODs restart in loop issue or a selective restore for MongoDB collections so that the admin.system.users could be skipped during PSMDB restore.

Hope this clarifies our use case.

Please let me know if you need any further detail on this issue.

Thanks again for your support

4

Hey @siva ,

what we usually recommend (and it is also in our docs) is to restore the secrets with user passwords first. So you create the secret resource in k8s for the operator and it will set the “old” passwords that you have in the backup.

Note: When restoring to a new Kubernetes-based environment, make sure it has a Secrets object with the same user
passwords as in the original cluster. More details about secrets can be found in System Users. The name of the required
Secrets object can be found out from the spec.secrets key in the deploy/cr.yaml .

Will this approach work for you?