Unable to restore databases or collections from PBM logical backup

# Selective restore with --ns does nothing - collections silently skipped (PBM 2.13.0)

Hello,

I have a 4-node MongoDB replica set:

  • Node 1: Primary
  • Node 2: Secondary
  • Node 3: Secondary
  • Node 4: Hidden (PBM CLI runs here)

PBM agents run on all nodes.

Both MongoDB and PBM run in Docker containers:

  • percona/percona-server-mongodb:8.0.17-6
  • percona/percona-backup-mongodb:2.13.0

## What I did

1. Created `testdb_B` with 2 collections: `testdb_B.logs` and `testdb_B.prodotti`, populated with data

2. Took a logical backup:

2026-03-20T16:17:15Z logical no no 2026-03-20T16:17:20

3. Dropped `testdb_B` entirely

4. Attempted selective restore:

pbm restore 2026-03-20T16:17:15Z --ns="testdb_B.*"

## What I expected

`testdb_B` restored with both collections and their data.

## What I got

The restore completes successfully (`recovery successfully finished`) but `testdb_B` does not appear in `show dbs` and no collections are restored.

## Investigation

pbm describe-backup confirms the collections are present in the backup:

collections:

  • testdb_B.logs

  • testdb_B.prodotti

The backup files exist on the filesystem and have meaningful size:

1863 bytes  /backups/2026-03-20T16:17:15Z/rs0/testdb_B.prodotti.s2

1717 bytes  /backups/2026-03-20T16:17:15Z/rs0/testdb_B.logs.s2


The `metadata.json` inside the backup confirms both collections with data:

{ "db": "testdb_B", "collection": "logs",      "size": 7112 }

{ "db": "testdb_B", "collection": "prodotti",   "size": 7165 }

Primary node logs during restore show the collections being **silently skipped**:

skipping restoring testdb_B.logs, it is not included

skipping restoring testdb_B.logs metadata, it is not included

skipping restoring testdb_B.prodotti, it is not included

skipping restoring testdb_B.prodotti metadata, it is not included

And during the index rebuild phase:

no indexes for testdb_B.logs

no indexes for testdb_B.prodotti

While all other collections show:

skip restore indexes for "testdb_A.ordini"

skip restore indexes for "graylog.streams"

... etc

`pbm describe-restore` confirms PBM is aware of the namespace filter:

name: "2026-03-24T10:27:08.525910563Z"

backup: "2026-03-24T10:17:46Z"

type: logical

status: done

namespaces:

- testdb_B.prodotti

Yet the collection is never written to MongoDB.

Debug logs show **zero mentions of testdb_B** during the actual restore phase:

pbm logs --severity=D --event=restore/2026-03-24T08:14:24.392628273Z | grep -i "testdb_B"

# (no output)

## Additional tests performed

- Tested with PBM **2.12.0** → same behavior

- Tested with PBM **2.13.0** → same behavior

- Tested restoring a **single collection** (`–ns=“testdb_B.prodotti”`) → same behavior

- Tested with a **fresh backup + immediate restore** on the same day → same behavior

- Tested with **selective backup** (`pbm backup --ns=“testdb_B.*”`) followed by selective restore → same behavior

- Full restore (no `–ns` filter) works correctly

- Verified `pbmuser` has all required roles: `pbmAnyAction`, `readWrite`, `backup`, `restore`, `clusterMonitor`

## PBM connection URI used by agents

mongodb://pbmuser:***@<node_ip>:27017/admin?replicaSet=rs0&authSource=admin&tls=true&tlsCAFile=/certs/ca.crt&tlsCertificateKeyFile=/certs/pbm-clientcert.pem

## Question

Is selective restore (`–ns`) from a full logical backup supported and expected to work in this configuration? Are we missing any configuration or is this a known bug?

Thank you

MoosEsooM

Hello,

Thank you for a well described issue.

The issue here is pbm-agent’s connection string, which is not correctly specified because it targets specific database (admin in this case):

mongodb://pbmuser:***@<node_ip>:27017/admin?replicaSet=rs0&authSource=admin&tls=true&…

So it should be without database name:

mongodb://pbmuser:***@<node_ip>:27017/?replicaSet=rs0&authSource=admin&tls=true&…

After that change, you’ll be able to restore the specified database from existing backups.

The issue is described within the following jira ticket:

1 Like