Chatee ahora con Soporte
Chat con el soporte

NetVault Plug-in for MySQL 4.4 - User Guide

Introducing Dell™ 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-inin a Failover Cluster environment Troubleshooting About Dell

Restoring data

•
Restoring data – an overview
•
Restoring data in MySQL
•
Using advanced restore procedures for MySQL Standard/Community

Restoring data – an overview

This section 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. Dell recommends that you review these sections 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.
Full or Individual Database/Table Copy Only Restores
When Plug‑in for MySQL performs a Full or Individual Database/Table Copy Only backup, MySQL’s mysqldump utility is used 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 executed automatically.
Incremental or Differential Restores
When the plug-in performs Incremental or Differential Backups, MySQL’s Binary Log Index is used to determine which Binary Logs need to 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 executed automatically. This process is referred to as “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 executing 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, refer to 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 sections.
•
Selecting data for restore
•
Setting restore options
•
Finalizing and submitting a job
•
Examples of restore scenarios for MySQL Standard/Community
•
Examples of restore scenarios for MySQL Enterprise Backup
Selecting data for restore
To select data to 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
To filter the items displayed in the saveset table further, use the Client, Date, and Job ID lists.
The table displays the saveset name (Job Title and Saveset ID), creation date and time, and size. By default, the list is sorted alphabetically by saveset name.
4
In the saveset table, select the applicable item.
When you select a saveset, the following details are displayed in the Saveset Information area: Job ID, Job Title, name of the NetVault Backup Server, name of the client from which the data was backed up, plug-in used to create the saveset, saveset creation date and time, saveset retirement setting, whether it is an Incremental Backup, whether it is an Archive, and saveset size.
5
To continue, click Next.
6
On the Create Selection Set page, select the data that you want to restore.
The first selectable node for inclusion in the restore will vary, based on the type of backup that is being recovered:
•
Full or Individual Database/Table Copy Only Backups – The root node is listed as “All Databases” — because the actual database/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. Selection of this will only restore all the data items that were actually selected for the backup job (that is, by selecting this node for a restore, you will not be performing a restore of all the databases that currently exist in a MySQL Instance — only those actually 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.
7
If a more granular restore is desired, double-click the root node to open it and reveal the individual databases that were included in the backup.
As well, an individual database can be opened to reveal its tables for selection.
 
 
*IMPORTANT: MySQL uses multiple file-formats to storage database information. Make sure that you include the .frm files in the restore process to ensure that the restored database is functional.
Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación