How to restore backup to a new Kubernetes-based environment¶

You can restore from a backup as follows:

On the same cluster where you made a backup
On a new cluster deployed in a different Kubernetes-based environment.

This document focuses on the restore on a new cluster deployed in a different Kubernetes environment.

For Operator version 1.17.0 and earlier

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).

Restore scenarios¶

This document covers the following restore scenarios:

Restore from a full backup - the restore from a backup without point-in-time
Point-in-time recovery - restore to a specific time, a specific or latest transaction or skip a specific transaction during a restore. This ability requires that you configure storing binlogs for point-in-time recovery

To restore from a backup, you create a special Restore object using a special restore configuration file. The example of such file is deploy/backup/restore.yaml .

You can check available options in the restore options reference.

Before you start¶

Make sure that the cluster is running.
List the cluster to find the correct cluster name. Replace the <namespace> with your value:
```
$ kubectl get pxc -n <namespace>
```
List backups to retrieve the desired backup name. Replace the <namespace> with your value:
```
$ kubectl get pxc-backup -n <namespace>
```
For point-in-time recovery, disable storing binlogs point-in-time functionality on the existing cluster. You must do it regardless of whether you made the backup with point-in-time recovery or without it. Use the following command and replace the cluster name and the <namespace> with your values:
```
$ kubectl patch pxc cluster1 \
  -n <namespace> \
  --type merge \
  -p '{"spec":{"backup":{"pitr":{"enabled":false}}}}'
```

Restore from a full backup¶

Configure the PerconaXtraDBClusterRestore Custom Resource. Specify the following keys in the deploy/backup/restore.yaml file:

set spec.pxcCluster key to the name of the target cluster to restore the backup on,
configure the spec.backupSource subsection to point to the PVC or the cloud storage where the backup is stored.
PVC volume
The spec.backupSource subsection should include:
- storageName - the storage name, which should be configured in the main CR
- destination 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" ...
S3-compatible storageAzure Blob storage

The spec.backupSource subsection should include:

a destination key. Take it from the output of the kubectl get pxc-backup command. The destination consists of the s3:// prefix, the S3 bucket name and the backup name.

the necessary storage configuration keys, just like in the deploy/cr.yaml file of the source cluster.

verifyTLS to verify the storage server TLS certificate

the custom TLS configuration if you use it for backups. Refer to the Configure TLS verification with custom certificates for S3 storage section for more information.

... backupSource: verifyTLS: true 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 caBundle: #If you use custom TLS certificates for S3 storage name: minio-ca-bundle key: ca.crt

The destination key should have value composed of three parts: the azure:// prefix, the Azure Blob container , and the backup name, which you have already found out using the kubectl get pxc-backup command. Also you should add necessary Azure configuration keys, same as those used to configure Azure Blob storage for backups in the deploy/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 with type=date option and contains value in datetime format,
  - gtid key (available since the Operator 1.8.0) is used with type=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 a destination key equal to the s3 bucket with a special s3:// prefix, followed by necessary S3 configuration keys, same as in deploy/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 the backup.storages subsection of the deploy/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

Last update: December 4, 2025
Created: December 4, 2025