Skip to content
logo
Percona Operator for MySQL
Restore from a previously saved backup
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
          • Restore the cluster without point-in-time recovery
          • Restore the cluster with point-in-time recovery
        • 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
      • 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

    Restore the cluster from a previously saved backup¶

    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 cannot be restored to emptyDir and hostPath volumes, but it is possible to make a backup from such storage (i. e., from emptyDir/hostPath to S3), and later restore it to a Persistent Volume.

    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.

    Following things are needed to restore a previously saved backup:

    • Make sure that the cluster is running.
    • Find out correct names for the backup and the 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.backupName key to the name of your backup,

      • 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):

        apiVersion: pxc.percona.com/v1
        kind: PerconaXtraDBClusterRestore
        metadata:
          name: restore1
        spec:
          pxcCluster: cluster1
          backupName: backup1
          storageName: s3-us-west
        
    2. After that, the actual restoration process can be started as follows:

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

      Note

      Storing backup settings in a separate file can be replaced by passing its content to the kubectl apply command as follows:

      $ cat <<EOF | kubectl apply -f-
      apiVersion: "pxc.percona.com/v1"
      kind: "PerconaXtraDBClusterRestore"
      metadata:
        name: "restore1"
      spec:
        pxcCluster: "cluster1"
        backupName: "backup1"
      EOF
      

    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,

      • set spec.backupName key to the name of your backup,

      • 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
      • use backupSource.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).

      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:
            storageName: "s3-us-west"
      
    2. Run the actual restoration process:

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

      Note

      Storing backup settings in a separate file can be replaced by passing its content to the kubectl apply command as follows:

      $ cat <<EOF | kubectl apply -f-
      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:
            storageName: "s3-us-west"
      EOF
      

    Take into account, that Operator monitors the binlog gaps detected by binlog collector, if any. If backup contains such gaps, the Operator will mark the status of the latest successful backup with a new condition field that indicates backup can’t guarantee consistent point-in-time recovery. This condition looks as follows:

    apiVersion: pxc.percona.com/v1
    kind: PerconaXtraDBClusterBackup
    metadata:
      name: backup1
    spec:
      pxcCluster: pitr
      storageName: minio
    status:
      completed: "2022-11-25T15:57:29Z"
      conditions:
      - lastTransitionTime: "2022-11-25T15:57:48Z"
        message: Binlog with GTID set e41eb219-6cd8-11ed-94c8-9ebf697d3d20:21-22 not found
        reason: BinlogGapDetected
        status: "False"
        type: PITRReady
      state: Succeeded
    

    Trying to restore from such backup (with the condition value “False”) with point-in-time recovery will result in the following error:

    Backup doesn't guarantee consistent recovery with PITR. Annotate PerconaXtraDBClusterRestore with percona.com/unsafe-pitr to force it.
    

    You can disable this check and force the restore by annotating it with pxc.percona.com/unsafe-pitr as follows:

    apiVersion: pxc.percona.com/v1
    kind: PerconaXtraDBClusterRestore
    metadata:
      annotations:
        percona.com/unsafe-pitr: "true"
      name: restore2
    spec:
      pxcCluster: pitr
      backupName: backup1
      pitr:
        type: latest
        backupSource:
          storageName: "minio-binlogs"
    

    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.