Restore External Backup
Restore External Backup lets you restore a backup that was created outside of ClusterControl onto a cluster it manages. You provide the storage host and path to the backup file, and ClusterControl handles the rest: staging the file, stopping the database, applying the backup, and bringing the node back online.
This feature is only available for MySQL Replication and MySQL Galera clusters.
Restoring internal vs. external backups
An internal backup is one ClusterControl itself created: it already knows the backup's method, storage location, and any incremental chain it belongs to, so restoring it is mostly a matter of picking it from a list. An external backup was taken independently, so you have to tell ClusterControl what it is and where it lives.
| Internal backup | External backup | |
|---|---|---|
| Created by | ClusterControl | Any tool, outside ClusterControl |
| Selecting a backup | Pick it from the backup list | Specify its storage host and absolute path |
| Restore target | Primary or replica node | Primary node only |
| Backup methods | Every method in Schedule Backup → Supported backup methods | mysqldump, xtrabackup, mariabackup |
| Verify on a standalone host | Yes, see Backup Verification | No |
| Point-in-time recovery (PITR) | Yes, for PITR-compatible backups | No |
| Restore system database | Yes (mysqldump) |
No |
Supported backup methods
| Method | Notes |
|---|---|
mysqldump |
Supported file extensions: .sql.gz, .sql.bz2, .aes, .aes256, .aes128 |
xtrabackup |
Percona Server and Oracle MySQL clusters |
mariabackup |
MariaDB clusters |
Prerequisites
- The backup must have been created with one of the methods above; ClusterControl cannot restore an external backup taken with anything else.
- Sufficient disk space on the target node for both the restored data and the temporary directory used during restore.
- The backup file must be reachable over the filesystem from the host you specify, with enough permissions to read it if it sits on a shared network path.
- Network connectivity between the ClusterControl controller and the source cluster.
- Appropriate user permissions and privileges on the target node. If SELinux or AppArmor is enabled, ensure it is configured to allow the restore operation to complete.
- The cluster's topology should be otherwise healthy going into the restore, the same as for Restore Backup → Prerequisites.
Warning
Restoring a backup overwrites the existing data on the target node. Make sure you have selected the correct backup file and target before confirming the restore.
Common Wizard Steps
Opening the wizard
- Go to the Clusters dashboard and click your target cluster.
- Go to the Backups tab and click More..., next to Create backup.
- Choose Restore backup, then Restore an external backup.
Step 1: Configuration
| Field | Required | Purpose and guidance |
|---|---|---|
| Cluster | Yes | The database cluster that will receive the restored data. Confirm the cluster name and ID before proceeding. |
| Restore backup on | Yes | The target database host the backup will be imported onto. External backups can only be restored to the primary node. |
| Backup Method | Yes | The restore engine matching your backup type: mysqldump or xtrabackup/mariabackup. |
| Storage Host | Yes | The host from which ClusterControl can access the external backup file. |
| Backup Path (absolute path) | Yes | Full path to the backup file on the storage host. Supported mysqldump extensions: .sql.gz, .sql.bz2, .aes, .aes256, .aes128. |
| Temporary directory | No | Staging area for the backup files during restore. Choose a location with sufficient free space and suitable permissions. |
| Use database root/admin credentials | No | Defaults to On. When enabled, provide the root or admin credentials that are stored in the backup. After the restore completes, ClusterControl uses these credentials to reconnect to the database and finalize the restoration. Reveals the two fields below. |
| Database user | Yes, if the option above is On | The root or admin username stored in the backup (for example, root). |
| Database password | Yes, if the option above is On | Password for the database user. |
| The dump file sets the database to restore the data into | No | For mysqldump-created backups only. Defaults to On. Uses the database selection already contained in the dump file. Review the dump file first and look for USE <databasename> if you have any doubt about its target database before turning this Off. If Off, specify the target database name in the Database textbox. |
| Reset master before restore | No | Defaults to Off. Requests a reset of the binary log state before the import (for example, when the backup file contains GTID information that would otherwise conflict with the target's history). This can affect replication and recovery history, so use it only when explicitly required. |
| Bootstrap cluster from the restored node | No | Defaults to On. Uses the restored node as the starting point for cluster recovery. Confirm that this node contains the authoritative data set before proceeding. |
Click Continue.
Step 2: Summary
Review the selected backup path and restore options. Click Finish to run the job.
No s9s CLI flags are currently documented for restoring an external backup. Use the ClusterControl GUI for this operation.
No RPC operation is currently documented for restoring an external backup. Use the ClusterControl GUI for this operation.