Skip to content

Restore External Backup

Before you end up with this guide, we expect that you have already check out and read Restore Backup. The cluster supported are MySQL Replication and Galera built clusters.

Similar to Restore Backup feature, they share the same fundamentals of restoring data from backup to its exisitng cluster. Data recovery, verifying your backup data to your target cluster, or restoring the previous health of your cluster.

Difference with restoring internal vs external backup

We have discussed the purpose of restoring a backup in Restore Backup. Primarily, the difference between internal and external backup are how they are stored and accessed by ClusterControl to perform a backup restoration. Internal backups are stored with metadata involved such that ClusterControl knows its location and how it was created. Whereas, external backups, you need to make sure what backup method is this created.

If you're looking to understand the difference between restoring an internal backup and restoring from an external backup, here's a breakdown of the key distinctions between the two:

  1. External Backup Restore
    • Primarily, you can store a backup that was taken without using ClusterControl or backups that have been taken outside ClusterControl or tools provided by ClusterControl technology.
    • Only in the primrary node you can restore an external backup.
    • Backup you can restore are either located on ClusterControl controller host, or from any of your database nodes registered in that cluster as long as its directory location is accessible in the host.
    • Only mysqldump and xtrabackup/mariabackup are supported for external backup restore.
  2. Internal Backup Restore
    • Only backups taken using ClusterControl can be restored.
    • You can restore the backup on the primary database server.
    • You can restore the backup on the replica database server.
    • If a backup verification server is already existent or setup, then you can also restore the backup on that backup verification server.
    • Backup you can restore are either located on ClusterControl controller host, or from any of your database nodes registered in that cluster as long as its directory location is accessible in the host.
    • You can restore your internal backup in the primary nodes. If you have a MySQL Replication Cluster, you can restore either from a primary or to a replica node.
    • You can restore with more options to chose from such as PITR and restore your system database.

Support Matrix

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

Database Vendor Topology
MySQL Replication Cluster Percona, Oracle, MariaDB Standalone, replication
Galera Cluster MariaDB, Percona Galera certification-based replication

Prerequisites

  • Backup should be supported by ClusterControl backup method.
  • 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.
  • Backup should be accessible via file system and make sure your directory. If shared, should have enough permission to access the directory and files in the network.
  • 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 an external 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

  • Backup should be supported by ClusterControl backup method. Currently, you can restore backups created using mysqqldump, xtrabackup, or mariabackup
  • Restore can only be done on the current cluster. Only on the primary database node you can target to restore the external backup.
  • Bootstrap cluster from restored node is enabled or set to On.

Steps to restore an external backup (Backup method: mysqldump)

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

  2. Go to the Backups tab and find More... button just beside after the Create backup button.

  3. Click More... button and choose Restore backup in the drop-down selection button.

  4. A command prompt will be displayed and select Restore an external backup by clicking the option.

  5. First step is Configuration.

    • Cluster: This is your selected database cluster in ClusterControl on which your target external backup restore shall be applied.
    • Restore backup on: This is the primary server where the external backup shall initiate from.
    • Backup Method: This is a drop-down list. You can choose from mysqldump or xtrabackup/mariabackup(for MariaDB databases). For this step, make sure you choose mysqldump
    • Storage Host: Select the host where the backuup file is stored
    • Backup Path (absolute path): This is required. You need to specify the absolute path of your backup. In mysqldump created backup, supported extensions: sql.gz, sql.bz2, aes, aes256, aes128
    • Temporary Directory: The tmpdir is used as temporary storage area for the backup files during restore. It must be as big as the datadir
    • The dump file sets the database to restore the data into: This is a checkbox button and is enabled by default. When check this means that dump includes database. If the dump does not include databases then set this off.
    • Reset master before restore: This is a checkbox button and is disabled or unchecked by default. Enable or check since this maybe needed if the dumpfile contains GTID information.

  6. Click Continue to proceed the last step Summary.

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

  8. Click Finish button to execute the job.

To be added soon

Steps to restore an external backup (Backup method: xtrabackup or mariabackup)

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

  2. Go to the Backups tab and find More... button just beside after the Create backup button.

  3. Click More... button and choose Restore backup in the drop-down selection button.

  4. A command prompt will be displayed and select Restore an external backup by clicking the option.

  5. First step is Configuration.

    • Cluster: This is your selected database cluster in ClusterControl on which your target external backup restore shall be applied.
    • Restore backup on: This is the primary server where the external backup shall initiate from.
    • Backup Method: This is a drop-down list. You can choose from mysqldump or xtrabackup/mariabackup(for MariaDB databases). For this step, make sure you choose mysqldump
    • Storage Host: Select the host where the backuup file is stored
    • Backup Path (absolute path): This is required. You need to specify the absolute path of your backup. In mysqldump created backup, supported extensions: sql.gz, sql.bz2, aes, aes256, aes128
    • Temporary Directory: The tmpdir is used as temporary storage area for the backup files during restore. It must be as big as the datadir
    • The dump file sets the database to restore the data into: This is a checkbox button and is enabled by default. When check this means that dump includes database. If the dump does not include databases then set this off.
    • Reset master before restore: This is a checkbox button and is disabled or unchecked by default. Enable or check since this maybe needed if the dumpfile contains GTID information.

  6. Click Continue to proceed the last step Summary.

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

  8. Click Finish button to execute the job.

To be added soon

MySQL Galera

The following vendors and versions are supported for restoring an external 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 Continue to 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

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