Restore the cluster from a previously saved backup¶

This document describes how to restore from a backup on the same the Kubernetes cluster where it was made.

You can also restore a backup on a different Kubernetes-based environment with the installed Operator as part of the disaster recovery strategy or when you configure multi-cluster deployment with cross-site replication.

Restore types¶

You can make the following restores:

Restore to a specific point in time. A precondition for this restore is to enable saving oplog operations
Restore only a backup snapshot
Selective restore from a logical backup

For either type of a restore you need to create a Restore object using the [deploy/backup/restore.yaml ](https://github.com/percona/percona-server-mongodb-operator/blob/main/deploy/backup/restore.yaml manifest.

Before you begin¶

Make sure that the cluster is running.
Get backup information. List the backups using this command:
```
$ kubectl get psmdb-backup
```
Get cluster information. List available clusters using this command:
```
$ kubectl get psmdb
```

Restore without point-in-time recovery¶

Modify the deploy/backup/restore.yaml manifest and set the following keys:
- set spec.clusterName key to the name of your cluster. When restoring to the same cluster where the backup was created, the cluster name will be identical in both the Backup and Restore objects.
- set spec.backupName key to the name of your backup.
```
apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDBRestore
metadata:
  name: restore1
spec:
  clusterName: my-cluster-name
  backupName: backup1
```

Start the restore by creating the Restore object. Use the following command:

$ kubectl apply -f deploy/backup/restore.yaml

Note

Instead of storing restore settings in a separate file, you can pass them directly to the kubectl apply command as follows:

$ cat <<EOF | kubectl apply -f-
apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDBRestore
metadata:
  name: restore1
spec:
  clusterName: my-cluster-name
  backupName: backup1
EOF

Make a point-in-time recovery¶

Modify the deploy/backup/restore.yaml manifest and specify the following configuration:
- set the spec.clusterName key to the name of your cluster. When restoring to the same cluster where the backup was created, the cluster name will be identical in both the Backup and Restore objects.
- set the spec.backupName key to the name of your backup
- configure point-in-time recovery settings in the pitr section:
  - type - specify one of the following options
    - date - roll back to a specific date
    - latest - recover to the latest possible transaction
  - date - specify the target datetime when type is set to date
Here is the example configuration of the restore.yaml file:
```
apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDBRestore
metadata:
  name: restore1
spec:
  clusterName: my-cluster-name
  backupName: backup1
  pitr:
    type: date
    date: YYYY-MM-DD hh:mm:ss
```
Note

When you run kubectl get psmdb-backup, each backup shows a “Latest restorable time” field. This helps you choose which backup to restore. To get just this time, use:
```
$ kubectl get psmdb-backup <backup_name> -o jsonpath='{.status.latestRestorableTime}'
```

Start the restore by creating a Restore object:

$ kubectl apply -f deploy/backup/restore.yaml

Note

Instead of storing restore settings in a separate file, you can pass them directly to the kubectl apply command as follows:

$ cat <<EOF | kubectl apply -f-
apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDBRestore
metadata:
  name: restore1
spec:
  clusterName: my-cluster-name
  backupName: backup1
EOF

Selective restore¶

Starting with the version 1.18.0, you can restore a desired subset of data from a full logical backup. Selective logical backups are not yet supported.

Selective restores have a number of limitations. Learn more about the current selective restore limitations in Percona Backup for MongoDB documentation.

Selective restores are controlled by the additional selective section in the PerconaServerMongoDBRestore Custom Resource. There you can specify a specific database or a collection that you wish to restore:

spec:
  selective:
    withUsersAndRoles: true
    namespaces:
    - "db1.collection1"
    - "db2.collection2"

You can specify several “namespaces” (subsets of data) as a list for the selective.namespaces field. You can specify a namespace as follows:

as a pair of database and collection names to restore just this database and collection. The format is db1.collection1
as a database name with a wildcard to restore everything from the specific database. The format is database_name.*
as a single star “*” to restore all databases and collections

Also, you can use selective.withUsersAndRoles set to true to restore a custom database with users and roles from a full backup. Read more about this functionality in PBM documentation .

Restore from a backup with a prefix in a bucket path¶

If you defined a prefix (a folder) in a bucket where you store backups, you must specify this prefix in the spec.backupSource subsection of the restore configuration.

To illustrate, let’s say you defined a prefix my-prefix for your AWS s3 bucket my-example-bucket. You wish to restore a backup2025-05-19T07:23:46Z. The pull path to this backup is "s3://my-example-bucket/my-prefix/2025-05-19T07:23:46Z". In this case, your restore configuration looks like this:

apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDBRestore
metadata:
  name: restore1
spec:
  clusterName: my-cluster-name
  backupSource:
    type: logical
    destination: "s3://my-example-bucket/my-prefix/2025-05-19T07:23:46Z"
    s3:
      credentialsSecret: my-cluster-name-backup-s3
      region: us-east-1
      bucket: chetan-testing-percona
      prefix: my-prefix

Apply this configuration to start a restore:

$ kubectl apply -f deploy/backup/restore.yaml

Last update: 2025-06-05