Table of contents
Restore Where
The Restore Where page lets you specify where the database is to be restored: either the original source, or to some other machine (Database or Table name cannot be changed).
These are the same fields on the Backup What page MySQL Server Parameters panel describe here. As noted, you can fill them out to connect to the original database (in other words, with the same values used in the Backup What page), or fill them out to point to a different server. Click Next Step when you are done.
If you are restoring a database from logical or parallel logical backups, you can change the name of the database being restored. Please provide the name of the database in the Alternate Database field.
If you are restoring selected databases/tables (especially with InnoDB storage engine) and have not used Xtrabackup as the backup method, do NOT restore to MySQL server that already has other innoDB tables. MySQL server may not start after the restoration. You should restore to a temporary MySQL server or restore the complete backup set that was running on the original MySQL server. If you have used Xtrabackup as backup method, you can restore InnoDB tables to a Percona MySQL server that already has other InnoDB tables.
If you are restoring backup images created using MySQL Enterprise Backup tool to a MySQL server, you must have the same data file configuration as the original MySQL server i.e, innodb_data_file_path and innodb_data_home_dir values must be identical to the original MySQL server.
EBS snapshot restore parameters
In addition to other restore parameters, restoration from Amazon Elastic Block Storage snapshot full backups requires the target Amazon EC2 instance id to where the snapshots are restored to. ZMC also provides an option to change device mapping from the original backup. Device mapping maps how the EBS volumes and mount points on the original Amazon EC2 instance which was backed up. For example: the mapping at the time of backup could be:
/innodb_data : /dev/sda /db : /dev/sdb /innodb_logs : /dev/sdd
It could be changed at the time of restoration on the restore target EC2 instance. ZRM remembers the original mapping as part of the backup image.
If you are changing the mount points at the time of restoration, you should provide next available device in lexicographic order. For example: If the system has "/dev/sda,/dev/sdb,/dev/sdc" devices, the customer must enter the next device name in lexicographic order - /dev/sdd. In newer kernels, the device names have "xv" prefix instead of "s" prefix. So, in newer kernels, if the system has devices attached as /dev/xvda, /dev/xvdb and /dev/xvdm, then you should enter "/dev/xvdc" since its available and is the next in lexicographic order.
The snapshots are restored and incremental backups are replayed on the target EC2 instance. If there are EBS volumes already mounted at the mount point, the restoration will fail. To prevent this, Check Unmount Existing to allow ZRM to unmount existing volumes before restoration of full backups.
Above panel appears only when the backup being restored contains Amazon EBS snapshots.