NetVault Plug-in for MySQL 12.0 - User Guide

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

To perform a restore successfully, you must understand the types of restore that are available for use.

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, the MySQL 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.”

During Incremental and Differential Restores, all transactions recorded in the Binary Logs can be applied, or they can be applied up to a particular time (PIT Recovery). PIT Recovery is useful when trying to recover up to the point directly preceding data corruption, such as a developer accidentally dropping a table or running an incorrect update.

PIT Recovery can be performed on the Binary Logs that are to be restored during an Incremental or Differential Restore. Time-based PIT Recovery is useful when the time that the data corruption occurred is known. For example, if a developer dropped a table at 6:00 A.M., PIT Recovery can be performed with a stop time of 5:55 A.M.

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.

When the actual time of the data corruption is unknown, or a more precise recovery is required, a position-based PIT Recovery should be used. For example, if a developer dropped a table from the database, but does not know the exact time when the table was dropped, a position-based PIT Recovery should be used.

Position-based PIT Recovery is a three-step process:

Reviewing the available restore options for MySQL Enterprise Backup

With the MEB-based method, you can perform a Full or Incremental Restore. If you used the TTS Backup option, you also have the option of completing a TTS Restore. Within the TTS Restore process, you have the additional option of restoring specific tables, known as a partial restore, and renaming one of the specified tables.

IMPORTANT: Because of the limited capabilities of using a TTS Backup or Restore, Quest recommends that you use the TTS options with discretion.

Be aware of the following restrictions for restoring a TTS Backup:

For more information, see https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/restore-use-tts.html.

Restoring data in MySQL

A standard restore with Plug‑in for MySQL includes the steps outlined in the following topics.