Percona backup getting timeout for Mongodb

MongoDB Percona Backup for MongoDB
,
1

Hi We are using percona backup version as 2.15 and mongodb version as 8.0 and while taking backup through docker we are getting error as follows

docker run --rm -v /etc/mongo/ssl/ca-chainv4.cert.pem:/ca-chainv4.cert.pem:ro percona/percona-backup-mongodb:2.15.0 pbm backup --mongodb-uri=“mongodb://pbmuser:UEK1eYDLPB6fsV5YpxQ3u5vy@cfgsvr1.snb.internal:27019,cfgsvr2.snb.internal:27019,cfgsvr3.snb.internal:27019/?authSource=admin&replicaSet=cfgRS&tls=true&tlsCAFile=/ca-chainv4.cert.pem”

  • ‘[’ pbm = pbm-agent ‘]’

  • exec pbm backup ‘–mongodb-uri=mongodb://pbmuser:password@cfgsvr1.snb.internal:27019,cfgsvr2.snb.internal:27019,cfgsvr3.snb.internal:27019/?authSource=admin&replicaSet=cfgRS&tls=true&tlsCAFile=/ca-chainv4.cert.pem’
    Starting backup “2026-08-03T13:10:19Z”…
    Error: wait for backup status: couldn’t get response from all shards: convergeClusterWithTimeout: 33s: reached converge timeout

  • Backup on replicaset “cfgRS” in state: error: couldn’t get response from all shards: convergeClusterWithTimeout: 33s: reached converge timeout

We have currently 3300+ collections and getting timeout error as follows - journalctl -u pbm-agent --since “2026-08-03 08:07:30” --until “2026-08-03 08:08:20” -o cat | grep -A2 “timed out”
2026-08-03T08:08:11.000+0000 I [backup/2026-08-03T08:07:39Z] mark RS as error get namespaces size: collStats "audit.elements.versions.autoapitest0812": timed out while checking out a connection from connection pool: context deadline exceeded; total connections: 200, maxPoolSize: 200, idle connections: 0, wait duration: 29.999841437s:
2026-08-03T08:08:11.000+0000 D [backup/2026-08-03T08:07:39Z] set balancer on
2026-08-03T08:08:11.000+0000 E [backup/2026-08-03T08:07:39Z] backup: get namespaces size: collStats “audit.elements.versions.autoapitest0812”: timed out while checking out a connection from connection pool: context deadline exceeded; total connections: 200, maxPoolSize: 200, idle connections: 0, wait duration: 29.999841437s

2026-08-03T08:08:11.000+0000 D [backup/2026-08-03T08:07:39Z] releasing lock

We have following configuration set where we have maxPoolSize=200 to resolve the timeout error

cat /etc/sysconfig/pbm-agent
PBM_MONGODB_URI=“mongodb://pbmuser:password@shardsvr2.snb.internal:27018/?authSource=admin&tls=true&tlsCAFile=/data/mongo/config/ca-chainv4.cert.pem&maxPoolSize=200”

cat /usr/local/bin/pbm-wrapper
#!/bin/bash
export PBM_MONGODB_URI=“mongodb://pbmuser:password@cfgsvr1.snb.internal:27019,cfgsvr2.snb.internal:27019,cfgsvr3.snb.internal:27019/admin?replicaSet=cfgRS&tls=true&tlsCAFile=/data/mongo/config/ca-chainv4.cert.pem”
exec /usr/bin/pbm “$@”

We have disable pitr for now and here is following configuration

pbm-wrapper config
storage:
type: s3
s3:
region: us-east-1
forcePathStyle: true
bucket: snb-dev-int-s3-backups
prefix: mongo-shard-config
credentials: {}
maxUploadParts: 10000
storageClass: STANDARD
insecureSkipTLSVerify: false
pitr:
enabled: false
oplogSpanMin: 60
compression: zstd
backup:
oplogSpanMin: 0
compression: zstd
numParallelCollections: 1
restore:
numDownloadWorkers: 4
maxDownloadBufferMb: 256
downloadChunkMb: 64

I have increased timeout as well to 180 seconds in /etc/pbm-config.yaml but still the issue is not resolved…failure is always during collStats on one of the audit.elements.versions.* collections.

could you help us resolve this issue and what more information we can provide

2

Hello and thank you for describing your case.

Unfortunately, you are affected by the bug that has been present for longer period within PBM, including the latest release (v2.15): https://perconadev.atlassian.net/browse/PBM-1700

The better news is that it is already fixed in dev branch and will be released as part of v2.16 (approx. second half of September, 2026).

There’s no possible workaround, but you can try the following:

  • increase cpu/memory for the running mongodb cluster so that it can serve the number of namespaces on your server during backup preparation phase.
  • use selective backup and do the backup just for a smaller number of databases/collections, which are the most important to you (probably not suitable for your use case, but just to be aware of).
  • do a custom build from the source from the dev branch.