How to restore backup to a new Kubernetes-based environment¶
The Operator allows restoring a backup not only on the Kubernetes cluster where it was made, but also on any Kubernetes-based environment with the installed Operator.
When restoring to a new Kubernetes-based environment, make sure it has a Secrets
object with the same user passwords as in the original cluster. More details
about secrets can be found in System Users.
The name of the required Secrets object can be found out from the
spec.secretsName
key in the deploy/cr.yaml
(cluster1-secrets
by default).
To restore a backup, you will use the special restore configuration file. The example of such file is deploy/backup/restore.yaml . The list of options that can be used in it can be found in the restore options reference.
You will need correct names for the backup and the cluster. If you have access to the original cluster, available backups can be listed with the following command:
$ kubectl get pxc-backup
And the following command will list available clusters:
$ kubectl get pxc
Note
If you have configured storing binlogs for point-in-time recovery, you will have possibility to roll back the cluster to a specific transaction, time (or even skip a transaction in some cases). 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.
Restore the cluster without point-in-time recovery¶
-
Set appropriate keys in the deploy/backup/restore.yaml file.
-
set
spec.pxcCluster
key to the name of the target cluster to restore the backup on, -
set
spec.backupSource
subsection to point on the appropriate PVC, or cloud storage:The
storageName
key should contain the storage name (which should be configured in the main CR), and thedestination
key should be equal to the PVC Name:... backupSource: destination: pvc/PVC_VOLUME_NAME storageName: pvc ...
Note
If you need a headless Service for the restore Pod (i.e. restoring from a Persistent Volume in a tenant network), mention this in the
metadata.annotations
as follows:annotations: percona.com/headless-service: "true" ...
The
destination
key should have value composed of three parts: thes3://
prefix, the S3 bucket , and the backup name, which you have already found out using thekubectl get pxc-backup
command. Also you should add necessary S3 configuration keys, same as those used to configure S3-compatible storage for backups in thedeploy/cr.yaml
file:... backupSource: destination: s3://S3-BUCKET-NAME/BACKUP-NAME s3: bucket: S3-BUCKET-NAME credentialsSecret: my-cluster-name-backup-s3 region: us-west-2 endpointUrl: https://URL-OF-THE-S3-COMPATIBLE-STORAGE ...
The
destination
key should have value composed of three parts: theazure://
prefix, the Azure Blob container , and the backup name, which you have already found out using thekubectl get pxc-backup
command. Also you should add necessary Azure configuration keys, same as those used to configure Azure Blob storage for backups in thedeploy/cr.yaml
file:... backupSource: destination: azure://AZURE-CONTAINER-NAME/BACKUP-NAME azure: container: AZURE-CONTAINER-NAME credentialsSecret: my-cluster-azure-secret ...
-
-
After that, the actual restoration process can be started as follows:
$ kubectl apply -f deploy/backup/restore.yaml
Restore the cluster with point-in-time recovery¶
Note
Disable the point-in-time functionality on the existing cluster before restoring a backup on it, regardless of whether the backup was made with point-in-time recovery or without it.
-
Set appropriate keys in the deploy/backup/restore.yaml file.
-
set
spec.pxcCluster
key to the name of the target cluster to restore the backup on, -
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,transaction
- roll back to a specific transaction (available since Operator 1.8.0),latest
- recover to the latest possible transaction,skip
- skip a specific transaction (available since Operator 1.7.0).
-
date
key is used withtype=date
option and contains value in datetime format, gtid
key (available since the Operator 1.8.0) is used withtype=transaction
option and contains exact GTID of a transaction which follows the last transaction included into the recovery,
-
-
set
spec.backupSource
subsection to point on the appropriate S3-compatible storage. This subsection should contain adestination
key equal to the s3 bucket with a specials3://
prefix, followed by necessary S3 configuration keys, same as indeploy/cr.yaml
file.
The resulting
restore.yaml
file may look as follows:apiVersion: pxc.percona.com/v1 kind: PerconaXtraDBClusterRestore metadata: name: restore1 spec: pxcCluster: cluster1 backupName: backup1 pitr: type: date date: "2020-12-31 09:37:13" backupSource: destination: s3://S3-BUCKET-NAME/BACKUP-NAME s3: bucket: S3-BUCKET-NAME credentialsSecret: my-cluster-name-backup-s3 region: us-west-2 endpointUrl: https://URL-OF-THE-S3-COMPATIBLE-STORAGE
-
you can also use a
storageName
key to specify the exact name of the storage (the actual storage should be already defined in thebackup.storages
subsection of thedeploy/cr.yaml
file):... storageName: s3-us-west backupSource: destination: s3://S3-BUCKET-NAME/BACKUP-NAME
-
-
Run the actual restoration process:
$ kubectl apply -f deploy/backup/restore.yaml