Skip to content

Restore Backup

There are two key reasons for engaging with database backups:

  • Recovering a database through restoring from a previous backup
  • Verifying the authenticity and reliability of the backup.

Restoring a backup aids corruption or accidental data deletion or do point-in-time recovery to undo a bad transaction or operation. It can also beneficial and useful for testing or cloning environment. See Create Cluster from Backup to learn more about creating a cluster from backup.

Verifying is particularly important for meeting compliance requirements and ensuring a reliable recovery when a disaster strikes, which is essential for returning the system to a healthy state. See Backup Verification for more details on how to verify the backup.

The Restore Backup feature in ClusterControl tackles these concerns providing a safe, efficient, and user-friendly way to manage your backup and do the appropriate actions you need for your recovery plan.

Overview of Restore Backup

ClusterControl provides two ways to restore the backup.

  1. Restore the backup within the cluster. This is very important especially if your database cluster encounters a disaster such as data loss or data corruption.
  2. Verifying the backup on a single node or external node.

ClusterControl also offers backup restoration taken externally. This means, backups that are created without relying or using ClusterControl supported backup methods. However, only MySQL Replication or MySQL Galera built clusters have this feature. To know more about this feature, checkout Restore External Backup

On this page, the Restore Backup feature focuses on restoring backups that were made or taken using ClusterControl supported backup methods. Restoring the backup means that it can only be restored to its source cluster where the backup data originated. If your cluster experiences data corruption or data loss and you need to restore from its previous state, this page will guide you through the process of recovering your data.

This guide provides step-by-step instructions on how to restore your backup to its own cluster using ClusterControl.

Support Matrix

All database clusters supported by ClusterControl include the backup restore feature. See below for the complete list:

Database Vendor Topology
MySQL Percona, Oracle Standalone, replication
MariaDB MariaDB Standalone, replication
Galera Cluster MariaDB, Percona Galera certification-based replication
PostgreSQL PostgreSQL, EnterpriseDB Standalone, streaming replication
TimescaleDB TimescaleDB Standalone, streaming replication
MongoDB MongoDB, Percona, MongoDB Enterprise Replica set, sharded cluster
Redis Redis, Valkey Sentinel, cluster
Microsoft SQL Server for Linux Microsoft Standalone, Always On availability group
Elasticsearch Elastic Single-node cluster, high availability cluster

Prerequisites

  • Backup should be created using ClusterControl and from an existing cluster.
  • You have sufficient storage space for the target environment. Make sure that the new environment or target nodes has enough disk space to copy and restore the backup.
  • Network interoperability between ClusterControl controller and the source cluster where backup was taken.
  • Ensure that you have appropriate user permissions and privileges on the target environment. If security kernel modules such as AppArmor or SELinux must be enabled, make sure you have appropriate configuration to allow the operation successful.
  • Ensure that the state of your topology are intact. Since restore backup is to recover from failure, restoration means that nodes currently down should be able to get back on normal state once backup restoration process is done.

MySQL Replication

The following vendors and versions are supported for restoring a backup:

  • Oracle MySQL - 8.0.
  • Percona Server for MySQL - 8.0.
  • Percona Server for MySQL Pro - 8.0.
  • MariaDB Server - 10.4, 10.5, 10.6 (LTS), 10.11 (LTS) and 11.4 (LTS).

Default Configuration

  • Backups created using ClusterControl's supported backup method shall be available for restore
  • Restore can only be done on the current cluster. By default, it picks the primary node but you can opt to restore the backup and select on the replica nodes
  • Only successful backups can be listed and can be stored
  • Bootstrap cluster from restored node is enabled or set to On

Steps to Restore a Backup (Backup method: mysqldump, mariabackup)

  1. Go to the Clusters dashboard. Choose your target source cluster then click.

  2. Go to the Backups tab and make sure you click or set the view to All Backups (default).

  3. Choose a backup you would like to restore and click the ellipsis button (...).

  4. Select and click Restore option.

  5. First step is Configuration.

    • Backup: This is selected backup to be restored to the cluster
    • Incremental backups: (Only for mariabackup created backups). This is a drop down element that lists down the incremental backups link if the backup to be restored is a mariabackupfull method.
    • Restore this backup from: This is the path or storage location of the backup
    • Method: This is a panel view just displays information of the backup information such as backup method, size, when it was created, and host where backup was taken

  6. Click Continue.

  7. Second step is How to restore.

    • Restore on node: Make sure you select this option since this is you are going to restore your backup for recovery of your cluster.
    • Restore and verify on standalone host: This is for restoring the backup to verify if data is good or not. This shall be discussed on Backup Verification

  8. Click Continue.

  9. Third step is Settings.

    • Restore backup on: When restoring the backup data, on most cases, you may to revert your cluster back to its previous health especially when disaster had just happened. Make sure you selected the Primary node. Otherwise, if you are just picking up some data for recovery or checking the contets that has been dropped or gone, you can try to restore it to the Replica node.
    • Temporary directory: The tmpdir is used as temporary storage area for the backup files during restore. It must be as big as the datadir
    • Restore system database: (Displays only for mysqldump). This is turned off by default. Turn it On if your data directory is not corrupted and the purpose of storing the backup is just for testing or verification purposes within your existing cluster. Other than that, you might also have valuable data in data directory that you do not want to be wipe out.
    • Make a copy of the datadir before restoring the backup: (Only for mariabackup created backups).This is turned off by default. Turn it On if you want to replace the system database when restoring the backup to its own cluster.
    • Bootstrap cluster from restored node: By default, this is turned On. This is the nature of storing the backup to its own cluster since it requires to bootstrap and make sure the primary starts first to avoid data drift or avoid deltas between your cluster nodes.
    • Point in time recovery (PITR): (Displays only for mysqldump with PITR enabled and mariabackup created backups). This is turned off by default. If you are storing it with PITR, make sure to enable this feature.
      • Time: This tab is displayed when PITR is enabled or On.
        • Restore time in host TZ: When time is selected, this field is displayed and you need to specify the period when you want the PITR to stop. This means that recover the data up until the date and time given by Restore Time (Event time - stop date&time).
      • Position: This tab is displayed when PITR is enabled or On.
        • Binary log name: This is the binary log name for which the PITR shall based on what file will check to based upon until the PITR stops.
        • Log stop position: This is the log position for which the PITR shall based on the binary log name and which log position in that binlog file until the PITR stops.

  10. Click Continueto proceed the last step Summary.

  11. The last step is Summary. This summarizes the action to be taken when restoring the backup to your cluster. This gives you the time to review your actions before executing the restore process.

  12. Click Finish button to execute the job.

To be added soon

Steps to Restore a Backup (Backup method: xtrabackup)

  1. Go to the Clusters dashboard. Choose your target source cluster then click.

  2. Go to the Backups tab and make sure you click or set the view to All Backups (default).

  3. Choose a backup you would like to restore and click the ellipsis button (...).

  4. Select and click Restore option.

  5. First step is Configuration.

    • Backup: This is selected backup to be restored to the cluster
    • Restore this backup from: This is the path or storage location of the backup
    • Method: This is a panel view just displays information of the backup information such as backup method, size, when it was created, and host where backup was taken

  6. Click Continue.

  7. Second step is How to restore.

    • Restore on node: Make sure you select this option since this is you are going to restore your backup for recovery of your cluster.
    • Restore and verify on standalone host: This is for restoring the backup to verify if data is good or not. This shall be discussed on Backup Verification

  8. Click Continue.

  9. Third step is Settings.

    • Restore backup on: When restoring the backup data, on most cases, you may to revert your cluster back to its previous health especially when disaster had just happened. Make sure you selected the Primary node. Otherwise, if you are just picking up some data for recovery or checking the contets that has been dropped or gone, you can try to restore it to the Replica node.
    • Temporary directory: The tmpdir is used as temporary storage area for the backup files during restore. It must be as big as the datadir
    • xtrabackup --use-memory (MiB): This option affects how much memory is allocated for preparing a backup with xtrabackup --prepare, or analyzing statistics with xtrabackup --stats. Its purpose is similar to innodb_buffer_pool_size. It does not do the same thing as the similarly named option in Oracle’s InnoDB Hot Backup tool. The default value is 100MB, and if you have enough available memory, 1024MB to 2048MB is a good recommended value.
    • Bootstrap cluster from restored node: By default, this is turned On. This is the nature of storing the backup to its own cluster since it requires to bootstrap and make sure the primary starts first to avoid data drift or avoid deltas between your cluster nodes.

  10. Click Continueto proceed the last step Summary.

  11. The last step is Summary. This summarizes the action to be taken when restoring the backup to your cluster. This gives you the time to review your actions before executing the restore process.

  12. Click Finish button to execute the job.

To be added soon

MySQL Galera

The following vendors and versions are supported for restoring a backup:

  • Percona XtraDB Cluster - 8.0.
  • MariaDB Cluster - 10.4, 10.5, 10.6 (LTS), 10.11 (LTS) and 11.4 (LTS).

Default Configuration

  • Backups created using ClusterControl's supported backup method shall be available for restore
  • Restore can only be done on the current cluster. By default, it picks the primary node but you can opt to restore the backup and select on the replica nodes
  • Only successful backups can be listed and can be stored
  • Bootstrap cluster from restored node is enabled or set to On

Steps to Restore a Backup

  1. Go to the Clusters dashboard. Choose your target source cluster then click.

  2. Go to the Backups tab and make sure you click or set the view to All Backups (default).

  3. Choose a backup you would like to restore and click the ellipsis button (...).

  4. Select and click Restore option.

  5. First step is Configuration.

    • Backup: This is selected backup to be restored to the cluster
    • Incremental backups: (Only for mariabackup and xtrabackup created backups with incrementals). This is a drop down element that lists down the incremental backups link if the backup to be restored is a mariabackupfull method.
    • Restore this backup from: This is the path or storage location of the backup
    • Method: This is a panel view just displays information of the backup information such as backup method, size, when it was created, and host where backup was taken

  6. Click Continue.

  7. Second step is How to restore.

    • Restore on node: Make sure you select this option since this is you are going to restore your backup for recovery of your cluster.
    • Restore and verify on standalone host: This is for restoring the backup to verify if data is good or not. This shall be discussed on Backup Verification

  8. Click Continue.

  9. Third step is Settings.

    • Restore backup on: When restoring the backup data, on most cases, you may to revert your cluster back to its previous health especially when disaster had just happened. Make sure you selected the Primary node. Otherwise, if you are just picking up some data for recovery or checking the contets that has been dropped or gone, you can try to restore it to the Replica node.
    • Temporary directory: The tmpdir is used as temporary storage area for the backup files during restore. It must be as big as the datadir
    • xtrabackup --use-memory (MiB): (Displays only for xtrabackup).This option affects how much memory is allocated for preparing a backup with xtrabackup --prepare, or analyzing statistics with xtrabackup --stats. Its purpose is similar to innodb_buffer_pool_size. It does not do the same thing as the similarly named option in Oracle’s InnoDB Hot Backup tool. The default value is 100MB, and if you have enough available memory, 1024MB to 2048MB is a good recommended value.
    • Restore system database: (Displays only for mysqldump). This is turned off by default. Turn it On if your data directory is not corrupted and the purpose of storing the backup is just for testing or verification purposes within your existing cluster. Other than that, you might also have valuable data in data directory that you do not want to be wipe out.
    • Make a copy of the datadir before restoring the backup: (Only for mariabackup created backups).This is turned off by default. Turn it On if you want to replace the system database when restoring the backup to its own cluster.
    • Bootstrap cluster from restored node: By default, this is turned On. This is the nature of storing the backup to its own cluster since it requires to bootstrap and make sure the primary starts first to avoid data drift or avoid deltas between your cluster nodes.
    • Point in time recovery (PITR): (Displays only for mysqldump with PITR enabled and mariabackup created backups). This is turned off by default. If you are storing it with PITR, make sure to enable this feature.
      • Time: This tab is displayed when PITR is enabled or On.
        • Restore time in host TZ: When time is selected, this field is displayed and you need to specify the period when you want the PITR to stop. This means that recover the data up until the date and time given by Restore Time (Event time - stop date&time).
      • Position: This tab is displayed when PITR is enabled or On.
        • Binary log name: This is the binary log name for which the PITR shall based on what file will check to based upon until the PITR stops.
        • Log stop position: This is the log position for which the PITR shall based on the binary log name and which log position in that binlog file until the PITR stops.

  10. Click Continueto proceed the last step Summary.

  11. The last step is Summary. This summarizes the action to be taken when restoring the backup to your cluster. This gives you the time to review your actions before executing the restore process.

  12. Click Finish button to execute the job.

To be added soon

PostgreSQL/TimescaleDB

The following vendors and versions are supported for restoring a backup:

Default Configuration

  • Backups created using ClusterControl's supported backup method shall be available for restore
  • Restore can only be done on the current cluster and on its primary node
  • Only successful backups can be listed and can be stored
  • Bootstrap cluster from restored node is enabled or set to On

Steps to Restore a Backup

  1. Go to the Clusters dashboard. Choose your target source cluster then click.

  2. Go to the Backups tab and make sure you click or set the view to All Backups (default).

  3. Choose a backup you would like to restore and click the ellipsis button (...).

  4. Select and click Restore option.

  5. First step is Configuration.

    • Backup: This is selected backup to be restored to the cluster
    • Restore this backup from: This is the path or storage location of the backup
    • Method: This is a panel view just displays information of the backup information such as backup method, size, when it was created, and host where backup was taken

  6. Click Continue.

  7. Second step is How to restore.

    • Restore on node: Make sure you select this option since this is you are going to restore your backup for recovery of your cluster.
    • Restore and verify on standalone host: This is for restoring the backup to verify if data is good or not. This shall be discussed on Backup Verification

  8. Click Continue.

  9. Third step is Settings.

    • Restore backup on: This drop-down element is disabled and defaults to the Primary node for which the restore shall happen.
    • Make a copy of the datadir before restoring the backup: (Displays only for pgbackrest created backups). This is turned off by default. Turn it On if your data directory is not corrupted and the purpose of storing the backup is just for testing or verification purposes within your existing cluster. Other than that, you might also have valuable data in data directory that you do not want to be wipe out.
    • Point in time recovery (PITR): (Displays only for pgbackrest created backups). This is turned off by default. If you are storing it with PITR, make sure to enable this feature.
      • Restore Time: This tab is displayed when PITR is enabled or On. This is the time until what the PostgreSQL forward (the oldest possible timestamp is the backup creation timestamp, or the current timestamp minus the "PITR_RETENTION_HOURS" configuration value if it is greater than 1.)
    • Bootstrap cluster from restored node: By default, this is turned On. This is the nature of storing the backup to its own cluster since it requires to bootstrap and make sure the primary starts first to avoid data drift or avoid deltas between your cluster nodes.

  10. Click Continueto proceed the last step Summary.

  11. The last step is Summary. This summarizes the action to be taken when restoring the backup to your cluster. This gives you the time to review your actions before executing the restore process.

  12. Click Finish button to execute the job.

To be added soon

MongoDB Replica Set

The following vendors and versions are supported for restoring a backup:

  • MongoDB Enterprise - 4.4, 5.0, 6.0 and 7.0
  • MongoDB Community - 4.4, 5.0, 6.0 and 7.0
  • Percona Server for MongoDB - 4.4, 5.0, 6.0 and 7.0

Default Configuration

  • Backups created using ClusterControl's supported backup method shall be available for restore
  • Restore can only be done on the current cluster and on its primary node
  • Only successful backups can be listed and can be stored
  • Only mongodump backups can be attempted for backup restore

Steps to Restore a Backup

  1. Go to the Clusters dashboard. Choose your target source cluster then click.

  2. Go to the Backups tab and make sure you click or set the view to All Backups (default).

  3. Choose a backup you would like to restore and click the ellipsis button (...).

  4. Select and click Restore option.

  5. First step is Configuration.

    • Backup: This is selected backup to be restored to the cluster
    • Restore this backup from: This is the path or storage location of the backup
    • Method: This is a panel view just displays information of the backup information such as backup method, size, when it was created, and host where backup was taken

  6. Click Finish button to execute the job.

To be added soon

MongoDB Sharded Cluster

The following vendors and versions are supported for restoring a backup:

  • MongoDB - 4.4, 5.0, 6.0 and 7.0
  • MongoDB Enterprise - 4.4., 5.0, 6.0 and 7.0
  • Percona - 4.4, 5.0, 6.0 and 7.0

Default Configuration

  • Backups created using ClusterControl's supported backup method shall be available for restore
  • Restore can only be done on the current cluster and on its primary node
  • Only successful backups can be listed and can be stored
  • Only percona-backup-mongodb backups can be restored for backup restore

Steps to Restore a Backup

  1. Go to the Clusters dashboard. Choose your target source cluster then click.

  2. Go to the Backups tab and make sure you click or set the view to All Backups (default).

  3. Choose a backup you would like to restore and click the ellipsis button (...).

  4. Select and click Restore option.

  5. First step is Configuration.

    • Backup: This is selected backup to be restored to the cluster
    • Restore this backup from: This is the path or storage location of the backup
    • Method: This is a panel view just displays information of the backup information such as backup method, size, when it was created, and host where backup was taken

  6. Click Continue.

  7. Second step is Settings.

    • Make a copy of the datadir before restoring the backup: This is turned off by default. Turn it On if your data directory is not corrupted and the purpose of storing the backup is just for testing or verification purposes within your existing cluster. Other than that, you might also have valuable data in data directory that you do not want to be wipe out.

  8. Click Continueto proceed the last step Summary.

  9. The last step is Summary. This summarizes the action to be taken when restoring the backup to your cluster. This gives you the time to review your actions before executing the restore process.

  10. Click Finish button to execute the job.

To be added soon

Redis Sentinel Cluster

The following vendors and versions are supported for restoring a backup:

  • Redis Sentinel - 6 and 7

Default Configuration

  • Backups created using ClusterControl's supported backup method shall be available for restore
  • Restore can only be done on the current cluster and on its primary node
  • Only successful backups can be listed and can be stored
  • Only rdb, aof backups can be restored for backup restore

Steps to Restore a Backup

  1. Go to the Clusters dashboard. Choose your target source cluster then click.

  2. Go to the Backups tab and make sure you click or set the view to All Backups (default).

  3. Choose a backup you would like to restore and click the ellipsis button (...).

  4. Select and click Restore option.

  5. First step is Configuration.

    • Backup: This is selected backup to be restored to the cluster
    • Restore this backup from: This is the path or storage location of the backup
    • Method: This is a panel view just displays information of the backup information such as backup method, size, when it was created, and host where backup was taken

  6. Click Continue.

  7. Second step is How to restore.

    • Restore on node: Make sure you select this option since this is you are going to restore your backup for recovery of your cluster.
    • Restore and verify on standalone host: This is for restoring the backup to verify if data is good or not. This shall be discussed on Backup Verification

  8. Click Continue.

  9. Third step is Settings.

    • Restore backup on: This drop-down element is disabled and defaults to the Primary node for which the restore shall happen.
    • Make a copy of the datadir before restoring the backup: This is turned off by default. Turn it On if your data directory is not corrupted and the purpose of storing the backup is just for testing or verification purposes within your existing cluster. Other than that, you might also have valuable data in data directory that you do not want to be wipe out.

  10. Click Continueto proceed the last step Summary.

  11. The last step is Summary. This summarizes the action to be taken when restoring the backup to your cluster. This gives you the time to review your actions before executing the restore process.

  12. Click Finish button to execute the job.

To be added soon

Redis/Valkey Cluster

The following vendors and versions are supported for restoring a backup:

  • Redis Cluster - 6 and 7
  • Valkey Cluster - 7 and 8 (only RHEL 8/9 are supported)

Default Configuration

  • Backups created using ClusterControl's supported backup method shall be available for restore
  • Restore can only be done on the current cluster and on its primary node
  • Only successful backups can be listed and can be stored
  • Only rdb, aof backups can be restored for backup restore

Steps to Restore a Backup

  1. Go to the Clusters dashboard. Choose your target source cluster then click.

  2. Go to the Backups tab and make sure you click or set the view to All Backups (default).

  3. Choose a backup you would like to restore and click the ellipsis button (...).

  4. Select and click Restore option.

  5. First step is Configuration.

    • Backup: This is selected backup to be restored to the cluster
    • Restore this backup from: This is the path or storage location of the backup
    • Method: This is a panel view just displays information of the backup information such as backup method, size, when it was created, and host where backup was taken

  6. Click Continue.

  7. Third step is Settings.

    • Restore backup on: This drop-down element is disabled and defaults to the Primary node for which the restore shall happen.
    • Make a copy of the datadir before restoring the backup: This is turned off by default. Turn it On if your data directory is not corrupted and the purpose of storing the backup is just for testing or verification purposes within your existing cluster. Other than that, you might also have valuable data in data directory that you do not want to be wipe out.

  8. Click Continueto proceed the last step Summary.

  9. The last step is Summary. This summarizes the action to be taken when restoring the backup to your cluster. This gives you the time to review your actions before executing the restore process.

  10. Click Finish button to execute the job.

To be added soon

SQL Server

The following vendors and versions are supported for restoring a backup:

  • Microsoft SQL Server for Linux - 2019 and 2022

Default Configuration

  • Backups created using ClusterControl's supported backup method shall be available for restore
  • Restore can only be done on the current cluster and on its primary node
  • Only successful backups can be listed and can be stored

Steps to Restore a Backup

  1. Go to the Clusters dashboard. Choose your target source cluster then click.

  2. Go to the Backups tab and make sure you click or set the view to All Backups (default).

  3. Choose a backup you would like to restore and click the ellipsis button (...).

  4. Select and click Restore option.

  5. First step is Configuration.

    • Backup: This is selected backup to be restored to the cluster
    • Incremental backups: (Display only if the backup to be restored is a mssqlfull that has incrementals). This is a drop down element that lists down the incremental backups link to the complete `mssqlfull backup.
    • Restore this backup from: This is the path or storage location of the backup
    • Method: This is a panel view just displays information of the backup information such as backup method, size, when it was created, and host where backup was taken

  6. Click Finish button to execute the job.

To be added soon

ElasticSearch

The following vendors and versions are supported for restoring a backup:

  • Elasticsearch by Elastic versions 7.17, 8.3, 8.15

Default Configuration

  • Backups created using ClusterControl's supported backup method shall be available for restore
  • Restore can only be done on the current cluster and on its primary node
  • Only successful backups can be listed and can be stored
  • Only elasticsearch-snapshot backups can be restored for backup restore

Steps to Restore a Backup

  1. Go to the Clusters dashboard. Choose your target source cluster then click.

  2. Go to the Backups tab and make sure you click or set the view to All Backups (default).

  3. Choose a backup you would like to restore and click the ellipsis button (...).

  4. Select and click Restore option.

  5. First step is Configuration.

    • Backup: This is selected backup to be restored to the cluster
    • Restore this backup from: This is the path or storage location of the backup
    • Method: This is a panel view just displays information of the backup information such as backup method, size, when it was created, and host where backup was taken

  6. Click Continue.

  7. Second step is Settings.

    • Make a copy of the datadir before restoring the backup: This is turned off by default. Turn it On if your data directory is not corrupted and the purpose of storing the backup is just for testing or verification purposes within your existing cluster. Other than that, you might also have valuable data in data directory that you do not want to be wipe out.

  8. Click Continueto proceed the last step Summary.

  9. The last step is Summary. This summarizes the action to be taken when restoring the backup to your cluster. This gives you the time to review your actions before executing the restore process.

  10. Click Finish button to execute the job.

To be added soon

Copyright © 2014-2025 Severalnines AB. All rights reserved.

Severalnines and ClusterControl are registered trademarks in the US, UK, and EU. The 3rd-party trademarks on this site are property of their respective owners and are used for referential purposes only.

Made with Material for MkDocs