Restoring data: an overview
This topic outlines the plug-in’s restore process and describes all the functionality available for use. In addition, Examples of restore scenarios for MySQL Standard/Community and Examples of restore scenarios for MySQL Enterprise Backup offer examples of the various types of restore. Quest recommends that you review these topics to ensure that you understand the functionality available and how it applies to the various types of restore.
Reviewing the available restore methods for MySQL Standard/Community
When the plug-in performs a Full or Individual Database/Table Copy Only backup, it uses MySQL’s mysqldump utility to stream the SQL statements that are used to create and populate the tables, directly to the backup media. When the plug-in restores one of these forms of backup, the SQL statements are read directly from the backup media, and run automatically.
When the plug-in performs Incremental or Differential Backups, MySQL’s Binary Log Index is used to determine which Binary Logs must be copied to the backup media. When these backups are restored, the Binary Logs are restored to a temporary directory, “NETVAULT_HOME/tmp/MySQL”. The mysqlbinlog utility is then used to generate SQL statements for each transaction that was recorded in the Binary Logs. These statements are then run automatically. This process is called “applying Binary Logs.”
Time-based PIT Recovery is typically a one-step process: Restore the Binary Logs from the Incremental or Differential Backup by selecting the Restore and Apply Binary Logs option on the Options tab, and specifying the stop time to be just before the unwanted transaction.
Position-based PIT Recovery is a three-step process:
|
1 |
Restore the Binary Logs from the Incremental or Differential Backup to a temporary directory on the MySQL Server by selecting the Restore Binary Logs to Temporary Directory to Identify Time or Position option on the Options tab. |
|
2 |
Use MySQL’s mysqlbinlog utility to identify the specific position of the unwanted transaction. For more information, see the Point-in-Time Recovery section of the MySQL Reference Guide. |
|
3 |
Restore the same Incremental or Differential Backup again; however, select the Apply Binary Logs from Temporary Directory restore option, and specify the stop position that exists right before the unwanted transaction. |
Restoring data in MySQL
A standard restore with Plug‑in for MySQL includes the steps outlined in the following topics.
Selecting data for a restore
|
1 |
In the Navigation pane, click Create Restore Job. |
|
2 |
On the Create Restore Job — Choose Saveset page, select Plug‑in for MySQL from the Plugin Type list. |
|
3 |
|
5 |
Click Next. |
|
6 |
On the Create Selection Set page, select the data that you want to restore. |
|
• |
Full or Individual Database/Table Copy Only Backups: The root node is listed as “All Databases” — because the actual database and table data was included in the backup. |
|
IMPORTANT: Although the root node is entitled “All Databases,” it does not account for all the databases that currently exist for a target MySQL Instance. Selecting this option only restores all the data items that were selected for the backup job; that is, by selecting this node for a restore, you are not performing a restore of all the databases that currently exist in a MySQL Instance — only those databases included in the backup. |
|
• |
Incremental or Differential Backups: The root node is listed as “Binary Logs” — because the transactions (Binary Logs) that occurred since the previous backup was performed are included in this form of backup. |
|
IMPORTANT: MySQL uses multiple file-formats to storage database information. Verify that you include the .frm files in the restore process to ensure that the restored database is functional. |