Skip to content
logo
Percona Operator for MySQL
How to restore backup to a new Kubernetes-based environment
Initializing search
    percona/k8spxc-docs
    percona/k8spxc-docs
    • Welcome
      • System Requirements
      • Design and architecture
      • Comparison with other solutions
      • Install with Helm
      • Install with kubectl
      • Install on Minikube
      • Install on Google Kubernetes Engine (GKE)
      • Install on Amazon Elastic Kubernetes Service (AWS EKS)
      • Install on Microsoft Azure Kubernetes Service (AKS)
      • Install on OpenShift
      • Generic Kubernetes installation
      • Multi-cluster and multi-region deployment
      • Application and system users
      • Changing MySQL Options
      • Anti-affinity and tolerations
      • Labels and annotations
      • Local Storage support
      • Defining environment variables
      • Load Balancing with HAProxy
      • Load Balancing with ProxySQL
      • Transport Encryption (TLS/SSL)
      • Data at rest encryption
      • Telemetry
        • About backups
        • Configure storage for backups
        • Make scheduled backups
        • Make on-demand backup
        • Store operations logs for point-in-time recovery
        • Enable compression for backups
        • Restore from a previously saved backup
        • Copy backup to a local machine
        • Delete the unneeded backup
      • Upgrade Database and Operator
      • Horizontal and vertical scaling
      • Monitor with Percona Monitoring and Management (PMM)
      • Add sidecar containers
      • Restart or pause the cluster
      • Crash recovery
      • Initial troubleshooting
      • Exec into the container
      • Check the logs
      • Special debug images
      • How to install Percona XtraDB Cluster in multi-namespace (cluster-wide) mode
      • How to upgrade Percona XtraDB Cluster manually
      • How to use private registry
      • How to restore backup to a new Kubernetes-based environment
        • Restore the cluster without point-in-time recovery
        • Restore the cluster with point-in-time recovery
      • How to use backups and asynchronous replication to move an external database to Kubernetes
      • Monitor Kubernetes
      • Custom Resource options
      • Percona certified images
      • Versions compatibility
      • Operator API
      • Frequently Asked Questions
      • Old releases (documentation archive)
      • Copyright and licensing information
      • Trademark policy
      • Release notes index
      • Percona Operator for MySQL based on Percona XtraDB Cluster 1.13.0 (2023-07-11)
      • Percona Operator for MySQL based on Percona XtraDB Cluster 1.12.0 (2022-12-07)
      • Percona Operator for MySQL based on Percona XtraDB Cluster 1.11.0 (2022-06-03)
      • Percona Distribution for MySQL Operator 1.10.0 (2021-11-24)
      • Percona Distribution for MySQL Operator 1.9.0 (2021-08-09)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.8.0 (2021-05-26)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.7.0 (2021-02-02)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.6.0 (2020-09-09)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.5.0 (2020-07-21)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.4.0 (2020-04-29)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.3.0 (2020-01-06)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.2.0 (2019-09-20)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.1.0 (2019-07-15)
      • Percona Kubernetes Operator for Percona XtraDB Cluster 1.0.0 (2019-05-29)

    • Restore the cluster without point-in-time recovery
    • Restore the cluster with point-in-time recovery

    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.secrets key in the deploy/cr.yaml (my-cluster-name-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¶

    1. 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 the 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"
        ...
        

        The destination key should have value composed of three parts: the s3:// prefix, the S3 bucket, and the backup name, which you have already found out using the kubectl get pxc-backup command. Also you should add necessary S3 configuration keys, same as those used to configure S3-compatible storage for backups in the deploy/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: 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
            ...
        
    2. 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.

    1. 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
        
    2. Run the actual restoration process:

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

    Contact Us

    For free technical help, visit the Percona Community Forum.

    To report bugs or submit feature requests, open a JIRA ticket.

    For paid support and managed or consulting services , contact Percona Sales.


    Last update: 2023-10-12
    Percona LLC and/or its affiliates, © 2009 - 2023
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better. Read more about Percona Cookie Policy.