How to restore to a different collection using PerconaServerMongoDBRestore CR

MongoDB Percona Operator for MongoDB
1

Hello everyone,

I am trying to determine whether it is possible to restore a single MongoDB collection to a specific point in time using the Percona Operator for MongoDB on Kubernetes, specifically through the PerconaServerMongoDBRestore Custom Resource (CR).

My goal is to restore only one collection, but into a different target collection name (not overwriting the original). Essentially, I am looking for functionality equivalent to the following PBM CLI command:

pbm restore --time=<timestamp> \
  --ns-from=testPerf.usertable \
  --ns-to=testPerf.usertable_v2

After reviewing the Percona Operator documentation, I did not find any references to this type of namespace remapping during restore.

Is this type of restore (point-in-time restore of a single collection into a different collection name) supported when using the Operator and the Restore CR? If so, could you please clarify how this can be achieved?

My current version of the operator is v1.20.1 with MongoDB 7.0.28

In this part, of the selective.namespaces I was expecting to be able to pass the ns-from and the ns-to, in order to create a parallel collection on the replica set. But nothing is documented (even in more recent versions)

 pitr:
    type: date
    date: "<TIMESTAMP>" # FORMAT YYYY-MM-DD hh:mm:ss
  selective:
    namespaces: ["<DATABASE.COLLECTION_NAME_1>"]

Best regards,
Paulo

2

No, it’s not yet possible. As a workaround you need to use pbm from the pod itself.

1 Like
3

Hi @psamagal,

As @radoslaw.szulgo mentioned, this isn’t supported through the CR yet. The selective.namespaces field only controls which collections to include in the restore; it does not remap them to different names. This is a gap between what PBM supports at the CLI level and what the operator CR exposes.

The good news is that PBM supports exactly what you need since version 2.8.0, and your operator v1.20.1 bundles PBM 2.9.1. You can run PBM directly from inside the backup-agent sidecar. I tested this on a 3-node replica set with PBM 2.12.0 and confirmed that PITR restore with namespace remapping works:

# exec into the backup-agent sidecar on one of the RS pods
kubectl exec -it <cluster-name>-rs0-0 -c backup-agent -- \
  pbm restore --base-snapshot <backup-name> \
    --time 2026-03-01T14:30:00 \
    --ns-from=testPerf.usertable \
    --ns-to=testPerf.usertable_v2

Replace <cluster-name> with your PSMDB cluster name and <backup-name> with the logical backup name (check pbm list from inside the container). The --time flag uses YYYY-MM-DDTHH:MM:SS format without timezone suffix.

A few constraints: you can only remap one collection per restore, it must be unsharded, and the target collection name must not already exist. Indexes (including TTL indexes) are preserved on the renamed collection. These constraints are documented in PBM selective restore docs.

One caveat: the operator won’t track this restore operation, so you won’t see status in kubectl get psmdb-restore. For a single collection rename this is fine, but avoid running operator-managed restores and manual PBM restores at the same time.

Consider filing a feature request at perconadev.atlassian.net under the K8SPSMDB project to add nsFrom/nsTo to the restore CR’s selective section. PBM already supports it; the operator just needs to pass those fields through.

References:

1 Like
4

Many thanks for the confirmation.

sadly, I don’t appear to have permissions to do it on Jira project refered

5

I’ve created K8SPSMDB-1603 to track adding --ns-to (namespace remapping) support to the PerconaServerMongoDBRestore CR. You can watch it for updates.