Backup config not initialized

MongoDB Percona Operator for MongoDB
1

pbm config --list fails with Error: get: mongo: no documents in result
Comparing to another cluster, I found that the admin.pbmConfig collection doesnt exist. I disabled backups, deployed, re-enabled backups and deployed again, but the operator didnt initialize pbm’s config.

1 Like
2

Hey @dmn ,

I assume you use an Operator to deploy the MongoDB cluster.
In that case, it makes me wonder why would you want to execute pbm config --list and where?

In other words, what is the problem that you are facing and why do you need to go that deep?

For me backups work flawlessly. Could you please share more details with me?
K8s flavor, operator version, cr manifest. Anything else you believe is relevant.

1 Like
3

Yes I used the operator. I’d get a shell in the backup-agent container to run pbm to check its state. I’ve written a backup state check script that runs as a k8s job, thats how I knew there was an issue after deploying this cluster.

I’ve set backup to false and completely removed the backup config in the k8s manifest and redeployed, watched the operator update the pods and remove the backup-agent containers, returned the backup config but still no pbmConfig collection created in admin. This means I cant run the first backup manually to get things going. Not sure how that collection gets provisioned as know in my first cluster I didnt have to do it myself. But in this case to get it working, I exported the one document out of pbmConfig(modifying it of course to match what I need in this cluster) and imported it. Now pbm works and I can kick off a backup, list them, etc.

There was an issue I caught with a typo in the name of the storage container name, but considering that completely removing the backup config from the k8s manifest didnt change anything, I’m not sure what caused the pbm config to not be generated.

Operator image: percona/percona-server-mongodb-operator:1.11.0

The backup config:

backup:
  enabled: true
  restartOnFailure: true
  image:
    repository: percona/percona-server-mongodb-operator
    tag: 1.11.0-backup
  serviceAccountName: percona-server-mongodb-operator
  resources:
    limits:
      cpu: 300m
      memory: 0.5G
    requests:
      cpu: 300m
      memory: 0.5G
  storages:
      azure-blob:
        type: azure
        azure:
          container: xxxx
          prefix: psmdb
          credentialsSecret: yyyy
  pitr:
    enabled: true
    oplogSpanMin: 10
  tasks:
    - name: weekly-azure-blob
      enabled: true
      schedule: "0 0 * * 0"
      keep: 5
      storageName: azure-blob
      compressionType: gzip
1 Like
4

I’m wondering if there is an order of operations issue here? A difference between this cluster and the one with a working backup system was the backup config manifest was part of the initial deploy. In the working case, the backup config was added to the manifest after the cluster was deployed and working.

1 Like
5

Did you ever figure this out? I’ve tried re-setting the db from scratch, enabling/disabling the backup agent and when I inspect collections on the admin db I see the following

pbmAgents
pbmBackups
pbmCmd
pbmLock
pbmLockOp
pbmLog
pbmOpLog
pbmPITRChunks

No pbmConfig collection no matter how many times I try to get the operator to do it.

The difference in my case is that I’m not using a separate percona backup custom resource, instead I used the backup block on the replicaset’s config on the PerconaServerMongoDB resource. This has worked in the past and I’ve made no changes.