You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
K8sPS-801 Fixed the restore to new cluster doc: (#223)
* K8SPS-801 Fixed the restore to new cluster doc:
Update the yaml example to define storage settings under spec.backupSource.storage
Added prefix to examples
Updated PITR to remove non valid example with spec.storageName as this is not supported
-[Make a point-in-time recovery](#restore-with-point-in-time-recovery)
16
-
-[Restore from an encrypted backup](#restore-from-an-encrypted-backup)
14
+
-[Restore from a backup to a new Kubernetes-based environment](#restore-from-a-backup-to-a-new-kubernetes-based-environment)
15
+
-[Restore scenarios](#restore-scenarios)
16
+
-[Preconditions](#preconditions)
17
+
-[Before you begin](#before-you-begin)
18
+
-[Restore from a backup without point-in-time recovery](#restore-from-a-backup-without-point-in-time-recovery)
19
+
-[Restore with point-in-time recovery](#restore-with-point-in-time-recovery)
20
+
-[Restore from an encrypted backup](#restore-from-an-encrypted-backup)
21
+
-[View restore details](#view-restore-details)
22
+
-[Post-restore steps](#post-restore-steps)
23
+
-[Troubleshooting](#troubleshooting)
17
24
18
25
To restore from a backup, you create a Restore object using a special restore configuration file. The example of such file is [deploy/backup/restore.yaml :octicons-link-external-16:](https://github.com/percona/percona-server-mysql-operator/blob/v{{release}}/deploy/backup/restore.yaml).
19
26
@@ -123,6 +130,7 @@ Configure the `PerconaServerMySQLRestore` Custom Resource. Specify the following
@@ -141,6 +149,7 @@ Configure the `PerconaServerMySQLRestore` Custom Resource. Specify the following
141
149
gcs:
142
150
bucket: operator-testing
143
151
credentialsSecret: ps-cluster1-gcp-credentials
152
+
prefix: <PREFIX-WHERE-BACKUP-IS-STORED>
144
153
type: gcs
145
154
```
146
155
@@ -165,16 +174,16 @@ When restoring to a new cluster, the Operator starts a temporary Binlog Server P
165
174
166
175
Binlog storage currently supports only AWS S3 and S3-compatible services, even when the base backup is stored elsewhere. Read more in the [Point-in-time recovery](backups-pitr.md) documentation.
167
176
168
-
### Approach 1. Define the storage configuration within the Restore object
177
+
Edit the [deploy/backup/restore.yaml](https://github.com/percona/percona-server-mysql-operator/blob/v{{release}}/deploy/backup/restore.yaml) manifest.
169
178
170
179
1. Specify the following keys:
171
180
172
181
* Set `spec.clusterName` key to the name of the target cluster to restore the backup on
173
182
* Configure the `spec.backupSource` subsection to point to the cloud storage where the backup is stored. This subsection should include:
174
183
175
184
* A destination key. Take it from the output of the `kubectl get ps-backup` command on the source cluster
176
-
* The necessary [storage configuration keys](backups-storage.md#configure-storage-for-backups), just like in the `deploy/cr.yaml` file of the source cluster.
177
-
185
+
* The necessary [storage configuration keys](backups-storage.md#configure-storage-for-backups), just like in the `deploy/cr.yaml` file of the source cluster. Make sure to set the `prefix` in the restore object to the exact same value used for the backup, so the Operator can find the correct backup location.
186
+
178
187
* Configure the `pitr` subsection:
179
188
180
189
* `type` - specify one of the following:
@@ -199,12 +208,14 @@ Binlog storage currently supports only AWS S3 and S3-compatible services, even w
### Approach 2. The storage is defined on the target
325
-
326
-
Use this approach when the target cluster already has backup storage configured in its Custom Resource. The storage name must match the source environment and use the same bucket, prefix, and credentials.
327
-
328
-
However, you must provide the binlog storage configuration within the restore object using `spec.pitr.backupSource.binlogServer`. This ensures the Operator can locate and access the binlogs needed for point-in-time recovery.
329
-
330
-
1. Specify the following keys:
331
-
332
-
* Set `spec.clusterName` key to the name of the target cluster to restore the backup to
333
-
* Set the `spec.storageName` to the storage name. It must match the name you defined in the target cluster's configuration.
334
-
* Configure the `spec.backupSource` subsection with the backup destination. Take it from the output of the `kubectl get ps-backup` command on the source cluster.
335
-
336
-
* Configure the `pitr` subsection:
337
-
338
-
* `type` - specify one of the following:
339
-
340
-
* `date` - to restore up to a specific time
341
-
* `gtid` - to restore up to a specific transaction
342
-
343
-
* For the `type=date` option, set the `date` key in the datetime format.
344
-
* For the `type=gtid` option, set the `gtid` to the GTID set to restore the database to. It has the format `source_id:transaction_id`
345
-
346
-
* `pitr.backupSource.binlogServer` - configure access to the binlog storage on the source cluster. Use the same settings as in the source cluster's `spec.backup.pitr.binlogServer`, including the `prefix`for the binlog folder.
347
-
348
-
=== "Restore to a timestamp"
349
-
350
-
=== "S3-compatible storage"
351
-
352
-
```yaml
353
-
apiVersion: ps.percona.com/v1
354
-
kind: PerconaServerMySQLRestore
355
-
metadata:
356
-
name: restore-timestamp
357
-
spec:
358
-
clusterName: ps-cluster1
359
-
storageName: s3-us-west
360
-
backupSource:
361
-
destination: s3://S3-BUCKET-NAME/BACKUP-NAME
362
-
pitr:
363
-
backupSource:
364
-
binlogServer:
365
-
storage:
366
-
s3:
367
-
bucket: S3-BINLOG-BUCKET-NAME
368
-
credentialsSecret: ps-cluster1-s3-credentials
369
-
region: us-west-2
370
-
endpointUrl: https://URL-OF-THE-S3-COMPATIBLE-STORAGE #Optional for AWS S3
0 commit comments