Restore the cluster from a previously saved backup¶

The backup is normally restored on the Kubernetes cluster where it was made, but restoring it on a different Kubernetes-based environment with the installed Operator is also possible.

Following things are needed to restore a previously saved backup:

Make sure that the cluster is running.
Find out correct names for the backup and the cluster. Available backups can be listed with the following command:
```
$ kubectl get psmdb-backup
```
And the following command will list available clusters:
```
$ kubectl get psmdb
```

Note

If you have configured storing operations logs for point-in-time recovery, you will have possibility to roll back the cluster to a specific date and time. Otherwise, restoring backups without point-in-time recovery is the only option.

When the correct names for the backup and the cluster are known, backup restoration can be done in the following way.

Without point-in-time recovery¶

Set appropriate keys in the deploy/backup/restore.yaml file.
- set spec.clusterName key to the name of the target cluster to restore the backup on,
- 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
```

After that, the actual restoration process can be started as follows:

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

Note

Storing backup settings in a separate file can be replaced by passing its content 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

With point-in-time recovery¶

Set appropriate keys in the deploy/backup/restore.yaml file.
- set spec.clusterName key to the name of the target cluster to restore the backup on
- set spec.backupName key to the name of your backup
- put additional restoration parameters to the pitr section:
  - type key can be equal to one of the following options
    - date - roll back to specific date
    - latest - recover to the latest possible transaction
  - date key is used with type=date option and contains value in datetime format The resulting restore.yaml file may look as follows:
```
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

Full backup objects available with the kubectl get psmdb-backup command have a “Latest restorable time” information field handy when selecting a backup to restore. You can easily query the backup for this information as follows:
```
$ kubectl get psmdb-backup <backup_name> -o jsonpath='{.status.latestRestorableTime}'
```

Run the actual restoration process:

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

Note

Storing backup settings in a separate file can be replaced by passing its content 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
  pitr:
    type: date
    date: YYYY-MM-DD hh:mm:ss
EOF

Get expert help¶

If you need assistance, visit the community forum for comprehensive and free database knowledge, or contact our Percona Database Experts for professional support and services. Join K8S Squad to benefit from early access to features and “ask me anything” sessions with the Experts.

Community Forum Get a Percona Expert Join K8S Squad

Last update: 2024-09-15