Restore What

Restore From

If users are restoring from a Full Backups and no incremental backups exist, then the backup set just prior to the time entered will be used to restore the data.

When incremental backups exist, ZMC for MySQL provides the ability to restore till the specified time. One of the more common reasons for a restore is to roll back the database to the point before a particular event (such as a mistake or malicious activity) damaged the database. In that case, you should use the Database Events viewer to launch the restore, and all of this information will be automatically prefilled on the Restore What page.

If the Restore from time is not specified, ZRM restores the most recent full backup and also looks at the subsequent incremental backup for transactions to restore to fulfill the user-specified Restore to time.

For example: A full backup was completed on Oct 8 at 16:17:29 and the next incremental backup occurred on Oct 8 at 18:00:00. If you specify a Restore to time of Oct 8, 16:17:29 and do not specify a "restore from" time, ZRM restores from the full backup dated Oct 8, 16:17:29 and all transactions that are present in the next incremental backup (Oct 8, 18:00:00) that occurred at Oct 8, 16:17:29.

What to Restore

All Databases

When the default choice, All Databases is accepted, the GUI does not change any further. Note that in this context the term All Databases means all the databases that have been backed up as part of the current backup set; such a restore could be all databases, selected databases, or selected table(s).

Specific Database

Choose this option to display the list of databases backed up within the set.

 

Specific Tables

This option of restoring specific tables from a database backup is available only for backups performed using logical or parallel logical or Xtrabackup tool. 

 

If you have performed logical or parallel logical backup, there are no restrictions. 

 

If you have performed backup using Xtrabackup tool, you can restore a table from a database backup to Percona MySQL server running XtraDB engine. For this functionality, innodb tables should be stored in separate data files i.e,innodb_file_per_table must be specified in my.cnf MySQL configuration file during the backup and requires innodb_expand_import to be enabled on the destination Percona server running XtraDB engine. See Percona documentation for the requirements.

Restoration involves the importing the table to the Percona MySQL server and this step has to be performed manually. You can perform the import only to Percona MySQL server.

The above figure shows customers table from the classicmodels database has been selected for restoration. The Restore Type Specific Table  will appear only for backups performed using Logical or Parallel logical or Xtrabackup tool. 

You can select to restore a table from the backup images if you are backing certain backup methods. If you are using parallel logical backup using MyDumper command, you can restore a specific table. You can do specific table restoration from full backups done using Xtrabackup command. When you restore specific tables, stored procedures, views and triggers that are backed up will not be restored.

If you are performing table level restores of logical or parallel logical backups done using earlier releases of ZRM, you will have to run following command as mysql user on the ZRM server before restores can be performed.

$ /usr/bin/mysql-zrm-parse-sql --source-directory <backup image directory> 
--update-table-list

Clicking Next Step button Initiates an error checking routine, first checking that the Go button has been clicked first. If the Go button has not been clicked, you are prompted to do that. You must correct any errors displayed by clicking Go before you can proceed to the next step. If there are no problems, clicking Next Step takes you to the Restore Where page, with parameters in the Restore What page saved and transferred to Restore Restore page.