Chat now with support
Chat with Support

NetVault Plug-in for MySQL 12.2.1 - User Guide

Introducing NetVault Backup Plug-in for MySQL Installing and removing the plug-in Configuring the plug-in Backing up data Restoring data Working with native MySQL replication Using the plug-in in a Failover Cluster environment Troubleshooting

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
•
Reviewing the available restore options for MySQL Enterprise Backup

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.

Full or Individual Database/Table Copy Only Restores

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.

Incremental or Differential Restores

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.

Time-based Point-in-Time (PIT) Recovery

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.

Position-based Point-in-Time (PIT) Recovery

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:

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.

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:

•
Make sure that the destination MySQL Server is running, because a connection with the server must be established.
•
Make sure that the tables you are restoring do not exist on the destination server.
•
Make sure that the destination server uses the same page size used on the original MySQL Server on which the backup was performed.
•
Make sure that the innodb_file_per_table option is enabled on the destination server.
•
Restore fails if the InnoDB file (.ibd file) you are restoring does not match the value of the innodb_file_format variable on the destination server.

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.

•
Selecting data for a restore
•
Setting restore options
•
Finalizing and submitting the job
•
Examples of restore scenarios for MySQL Standard/Community
•
Examples of restore scenarios for MySQL Enterprise Backup
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating