Skip to content

Commit 5dadc93

Browse files
committed
K8SPSMDB-1386 Improved restore doc
Added a subsection explaining restores with prefixes define for a bucket
1 parent dea9876 commit 5dadc93

File tree

1 file changed

+71
-35
lines changed

1 file changed

+71
-35
lines changed

docs/backups-restore.md

Lines changed: 71 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -1,34 +1,40 @@
11
# Restore the cluster from a previously saved backup
22

3-
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](backups-restore-to-new-cluster.md).
3+
This document describes how to restore from a backup on the same the Kubernetes cluster where it was made.
44

5-
Following things are needed to restore a previously saved backup:
5+
You can also [restore a backup on a different Kubernetes-based environment with the installed Operator](backups-restore-to-new-cluster.md) as part of the disaster recovery strategy or when you configure [multi-cluster deployment with cross-site replication](replication.md).
6+
7+
## Restore types
8+
9+
You can make the following restores:
10+
11+
* [Restore to a specific point in time](#make-a-point-in-time-recovery). A precondition for this restore is to [enable saving oplog operations](backups-pitr.md)
12+
* [Restore only a backup snapshot](#restore-without-point-in-time-recovery)
13+
* [Selective restore from a logical backup](#selective-restore)
14+
15+
For either type of a restore you need to create a Restore object using the [`deploy/backup/restore.yaml` :octicons-link-external-16:](<https://github.com/percona/percona-server-mongodb-operator/blob/main/deploy/backup/restore.yaml> manifest.
16+
17+
## Before you begin
618

719
* Make sure that the cluster is running.
8-
* Find out correct names for the **backup** and the **cluster**. Available backups can be listed with the following command:
20+
* Get backup information. List the backups using this command:
921

1022
``` {.bash data-prompt="$" }
1123
$ kubectl get psmdb-backup
1224
```
1325

14-
And the following command will list available clusters:
26+
* Get cluster information. List available clusters using this command:
1527

1628
``` {.bash data-prompt="$" }
1729
$ kubectl get psmdb
1830
```
1931

20-
!!! note
21-
22-
If you have [configured storing operations logs for point-in-time recovery](backups-pitr.md), 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.
32+
## Restore without point-in-time recovery
2333

24-
When the correct names for the backup and the cluster are known, backup restoration can be done in the following way.
34+
1. Modify the [deploy/backup/restore.yaml :octicons-link-external-16:](https://github.com/percona/percona-server-mongodb-operator/blob/main/deploy/backup/restore.yaml) manifest and set the following keys:
2535

26-
## Without point-in-time recovery
27-
28-
1. Set appropriate keys in the [deploy/backup/restore.yaml :octicons-link-external-16:](https://github.com/percona/percona-server-mongodb-operator/blob/main/deploy/backup/restore.yaml) file.
29-
30-
* set `spec.clusterName` key to the name of the target cluster to restore the backup on,
31-
* set `spec.backupName` key to the name of your backup,
36+
* 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.
37+
* set `spec.backupName` key to the name of your backup.
3238

3339
```yaml
3440
apiVersion: psmdb.percona.com/v1
@@ -40,15 +46,15 @@ When the correct names for the backup and the cluster are known, backup restorat
4046
backupName: backup1
4147
```
4248

43-
2. After that, the actual restoration process can be started as follows:
49+
2. Start the restore by creating the Restore object. Use the following command:
4450

4551
``` {.bash data-prompt="$" }
4652
$ kubectl apply -f deploy/backup/restore.yaml
4753
```
4854

4955
!!! note
5056

51-
Storing backup settings in a separate file can be replaced by passing its content to the `kubectl apply` command as follows:
57+
Instead of storing restore settings in a separate file, you can pass them directly to the `kubectl apply` command as follows:
5258

5359
```bash
5460
$ cat <<EOF | kubectl apply -f-
@@ -62,18 +68,19 @@ When the correct names for the backup and the cluster are known, backup restorat
6268
EOF
6369
```
6470
65-
## With point-in-time recovery
71+
## Make a point-in-time recovery
6672
67-
1. Set appropriate keys in the [deploy/backup/restore.yaml :octicons-link-external-16:](https://github.com/percona/percona-server-mongodb-operator/blob/main/deploy/backup/restore.yaml) file.
73+
1. Modify the [deploy/backup/restore.yaml :octicons-link-external-16:](https://github.com/percona/percona-server-mongodb-operator/blob/main/deploy/backup/restore.yaml) manifest and specify the following configuration:
6874
69-
* set `spec.clusterName` key to the name of the target cluster to restore the backup on
70-
* set `spec.backupName` key to the name of your backup
71-
* put additional restoration parameters to the `pitr` section:
72-
* `type` key can be equal to one of the following options
73-
* `date` - roll back to specific date
75+
* 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.
76+
* set the `spec.backupName` key to the name of your backup
77+
* configure point-in-time recovery settings in the `pitr` section:
78+
* `type` - specify one of the following options
79+
* `date` - roll back to a specific date
7480
* `latest` - recover to the latest possible transaction
75-
* `date` key is used with `type=date` option and contains value in datetime format
76-
The resulting `restore.yaml` file may look as follows:
81+
* `date` - specify the target datetime when `type` is set to `date`
82+
83+
Here is the example configuration of the `restore.yaml` file:
7784
7885
```yaml
7986
apiVersion: psmdb.percona.com/v1
@@ -90,23 +97,23 @@ When the correct names for the backup and the cluster are known, backup restorat
9097
9198
!!! note
9299
93-
<a name="backups-latest-restorable-time"></a> 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:
100+
<a name="backups-latest-restorable-time"></a> 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:
94101
95102
``` {.bash data-prompt="$" }
96103
$ kubectl get psmdb-backup <backup_name> -o jsonpath='{.status.latestRestorableTime}'
97104
```
98105
99-
2. Run the actual restoration process:
106+
2. Start the restore by creating a Restore object:
100107
101108
``` {.bash data-prompt="$" }
102109
$ kubectl apply -f deploy/backup/restore.yaml
103110
```
104111
105112
!!! note
106113
107-
Storing backup settings in a separate file can be replaced by passing its content to the `kubectl apply` command as follows:
114+
Instead of storing restore settings in a separate file, you can pass them directly to the `kubectl apply` command as follows:
108115
109-
``` {.bash data-prompt="$" }
116+
```bash
110117
$ cat <<EOF | kubectl apply -f-
111118
apiVersion: psmdb.percona.com/v1
112119
kind: PerconaServerMongoDBRestore
@@ -115,16 +122,15 @@ When the correct names for the backup and the cluster are known, backup restorat
115122
spec:
116123
clusterName: my-cluster-name
117124
backupName: backup1
118-
pitr:
119-
type: date
120-
date: YYYY-MM-DD hh:mm:ss
121125
EOF
122126
```
123127
124128
## Selective restore
125129
126130
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.
127131
132+
Selective restores have a number of limitations. Learn more about the [current selective restore limitations :octicons-link-external-16:](https://docs.percona.com/percona-backup-mongodb/features/known-limitations.html#selective-backups-and-restores) in Percona Backup for MongoDB documentation.
133+
128134
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:
129135
130136
```yaml
@@ -136,9 +142,39 @@ spec:
136142
- "db2.collection2"
137143
```
138144
139-
The `selective.namespaces` field allows you to specify several "namespaces" (subsets of data) as a list. Each "namespace" is represented as a pair of database and collection names, or just `database_name.*` to get everything from the specific database. Specifying "*" as an item in the `namespaces` means restoring all databases and collections.
145+
You can specify several "namespaces" (subsets of data) as a list for the `selective.namespaces` field. You can specify a namespace as follows:
146+
147+
* as a pair of database and collection names to restore just this database and collection. The format is `db1.collection1`
148+
* as a database name with a wildcard to restore everything from the specific database. The format is `database_name.*`
149+
* as a single star "*" to restore all databases and collections
150+
151+
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 :octicons-link-external-16:](https://docs.percona.com/percona-backup-mongodb/usage/restore-selective.html#restore-with-users-and-roles).
152+
153+
## Restore from a backup with a prefix in a bucket path
154+
155+
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.
140156
141-
Also, you can use `selective.withUsersAndRoles` set to `true` to restore a custom database with users and roles from a full backup.
157+
To illustrate, let's say you defined a prefix `my-prefix` for your AWS s3 bucket `my-example-bucket`. You wish to restore a backup`2025-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:
142158
143-
Selective restores support only logical backups and have a number of other limitations. See the full list of [current selective restore limitations :octicons-link-external-16:](https://docs.percona.com/percona-backup-mongodb/features/known-limitations.html#selective-backups-and-restores) in Percona Backup for MongoDB documentation.
159+
```yaml
160+
apiVersion: psmdb.percona.com/v1
161+
kind: PerconaServerMongoDBRestore
162+
metadata:
163+
name: restore1
164+
spec:
165+
clusterName: my-cluster-name
166+
backupSource:
167+
type: logical
168+
destination: "s3://my-example-bucket/my-prefix/2025-05-19T07:23:46Z"
169+
s3:
170+
credentialsSecret: my-cluster-name-backup-s3
171+
region: us-east-1
172+
bucket: chetan-testing-percona
173+
prefix: my-prefix
174+
```
144175
176+
Apply this configuration to start a restore:
177+
178+
``` {.bash data-prompt="$" }
179+
$ kubectl apply -f deploy/backup/restore.yaml
180+
```

0 commit comments

Comments
 (0)