To recover successfully from a failure or data corruption, various settings must be made when setting up the job regarding data selected for restore and options available on the Options tab. The following topics offer examples of various types of recovery and cover the specific options required.
On Monday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 6:00 A.M. on Monday before the DBA’s arrival at work.
The DBA decides to recover up to the time right before the Drop Table command was issued. This decision means that the DBA must restore the Sunday’s Full Backup, and perform PIT Recovery on the current Binary Logs.
1 |
Select the Full Restore from Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery on Current Binary Logs: Selected to enable this form of restore and all associated options. |
• |
Time Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Date/Time to “5:59” and “8 Jan 2007”; that is, one minute before 6:00 A.M. on Monday. |
The DBA decides to recover up to the time right before the Drop Table command was issued. The DBA also wants to recover the transactions that occurred to the remaining tables from the time after the erroneous statement was issued, and up until the end of the current Binary Logs. This decision ensures that he has recovered as many of the transactions as feasible, in addition to recovering the dropped table.
1 |
Select the Full Restore from Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery on Current Binary Logs: Selected to enable this form of restore all associated options. |
• |
Time Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Date/Time to “5:59” and “8 Jan 2007”; that is, one minute before 6:00 A.M. on Monday. |
• |
Enable Recovery After Erroneous/Bad SQL Statements: Selected to recover transactions that occurred after the Order table was dropped, and entered a later time and date in the Start Date/Time. Finally, because the recovery is to be performed to the end of the named Binary Log, the None option was selected for the Stop Date/Time. |
On Monday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 6:00 A.M. on Monday before the DBA’s arrival at work.
The DBA decides to recover up to the time right before the Drop Table command was issued. Furthermore, because the DBA wants a more precise recovery than estimating the time at which the developer dropped the table, the DBA chooses to use a position-based recovery. To accomplish this process, the DBA must restore Sunday’s Full Backup and perform a PIT Recovery on the current Binary Logs.
1 |
Use the mysqlbinlog utility against the current Binary Logs: This step is performed outside of NetVault Backup to identify the position of the Drop Table command that the DBA does not want to restore. (For information on this utility and process, see the MySQL Reference Guide.) In this process, the DBA identified the Drop Table command as log position “805” in the “MYSQLSVR-bin.000009” Binary Log. |
2 |
Select the Full Restore from Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
3 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery on Current Binary Logs: Selected to enable this form of restore and all associated options. |
• |
Position Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Position to “804,” the position before the one identified using mysqlbinlog. Set Binary Log Containing Stop Position to OTHER FILE, and entered the name of the target binary file in the text box, for example, “MYSQLSVR-bin.000009.” |
IMPORTANT: Stop and Start positions must be actual positions listed in a Binary Log, not arbitrary numbers that are greater than the position of the unwanted transaction. |
The DBA decides to recover up to the time right before the Drop Table command was issued. The DBA also wants to recover the transactions that occurred to the remaining tables from the time after the Orders table was dropped, and up until the end of the current Binary Logs. This decision ensures that he has recovered as many of the transactions as feasible, in addition to recovering the dropped table. Furthermore, the DBA wants a more precise recovery, so he decides to use a position-based recovery. To accomplish this process, the DBA must restore Sunday’s Full Backup and perform a PIT Recovery on the current Binary Logs.
1 |
Use the mysqlbinlog utility against the current Binary Logs: This step is performed outside of NetVault Backup to identify the position of the Drop Table command that the DBA does not want to restore. (For information on this utility and process, see the MySQL Reference Guide.) In this process, the DBA identified the Drop Table command as log position “805” in the “MYSQLSVR-PM-bin.000009” Binary Log. |
2 |
Select the Full Restore from Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
3 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery on Current Binary Logs: Selected to enable this form of restore and all associated options. |
• |
Position Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Position to “804,” the position before the one identified using mysqlbinlog. Set Binary Log Containing Stop Position to OTHER FILE, and entered the name of the target binary file in the text box, for example, “MYSQLSVR-PM-bin.000009.” |
• |
Enable Recovery After to Erroneous/Bad SQL Statement(s): Selected this option, and set the Start Position to “806,” the position after the one identified using mysqlbinlog. Set Binary Log Containing Start Position to OTHER FILE, and entered the name of the target binary file in the text box, for example, “MYSQLSVR-bin.000009.” Finally, because the recovery is to be performed to the end of the named Binary Log, the None option was selected for the Stop Position. |
IMPORTANT: Stop and Start positions must be actual positions listed in a Binary Log, not arbitrary numbers that are greater than the position of the unwanted transaction. |
The DBA has established a backup policy in which Full Backups are performed every Sunday at 11:00 P.M. and Incremental Backups are performed Monday through Saturday, at 11:00 P.M. Because the DBA is performing Incremental Backups, the Binary Logs are deleted after each Incremental Backup. This process makes the overall backup faster, but requires more time and steps when performing the restore.
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors for the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped the table sometime early Thursday, before the DBA’s arrival at work.
The DBA decides to perform a complete recovery up to the point of the last Incremental Backup — the backup performed on Wednesday night.
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Monday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Monday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Tuesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Tuesday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 8:00 P.M. on Wednesday.
The DBA needs to perform a recovery that restores the database up to the time right before the developer dropped the table at 8:00 P.M. on Wednesday. Therefore, the following phases would be performed:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Monday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Monday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Tuesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Tuesday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Incremental Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to specify PIT Recovery and enable all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to specify the Binary Log included in the backup for use. |
• |
Time Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Date/Time to “19:59” and “10 Jan 2007,” that is, one minute before 8:00 P.M. on Wednesday. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 8:00 P.M. on Wednesday.
The DBA decides to recover up to the time right before the Drop Table command was issued at 8:00 P.M. The DBA also wants to recover the transactions that occurred to the remaining tables from the time after the Orders table was dropped, and up until the end of the backed-up Binary Logs. This decision ensures that he has recovered as many of the transactions as feasible, in addition to recovering the dropped table. Therefore, the following phases would be performed:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Monday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Monday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Tuesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Tuesday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Incremental Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to specify PIT Recovery and enable all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to specify the Binary Log included in the backup for use. |
• |
Time Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Date/Time to “19:59” and “10 Jan 2007,” that is, one minute before 8:00 P.M. on Wednesday. |
• |
Enable Recovery After Erroneous/Bad SQL Statements: Selected to recover transactions that occurred after the Order table was dropped, entered a later time and date in the Start Date/Time. Finally, because the recovery is to be performed to the end of the Binary Log included in the backup, the None option was selected for the Stop Date/Time. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 6:00 A.M. on Thursday.
The DBA needs to perform a recovery that restores the database up to the time right before the developer dropped the table at 6:00 A.M. on Thursday.
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Monday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Monday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Tuesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Tuesday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Incremental Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to specify PIT Recovery and enable all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to indicate that the Binary Log included in the backup is to be used. |
• |
Include Current Binary Logs: Selected to use the current Binary Logs to apply entries that occurred between the time the backup was completed on Wednesday, and the issuance of the Drop Table command. |
• |
Time Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Date/Time to “05:59” and “11 Jan 2007,” that is, one minute before 6:00 A.M. on Thursday. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 6:00 A.M. on Thursday.
The DBA decides to recover up to the time right before the Drop Table command was issued. The DBA also wants to recover the transactions that occurred to the remaining tables from the time after the Orders table was dropped, and up until the end of the current Binary Logs. This decision ensures that he has recovered as many of the transactions as feasible, in addition to recovering the dropped table. Therefore, the following phases would be performed:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Monday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Monday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Tuesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Tuesday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Incremental Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to specify PIT Recovery and enable all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to indicate that the Binary Log included in the backup is to be used. |
• |
Include Current Binary Logs: Selected to use the current Binary Logs to apply entries that occurred between the time the backup was completed on Wednesday, and the issuance of the Drop Table command. |
• |
Time Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Date/Time to “05:59” and “11 Jan 2007,” that is, one minute before 6:00 A.M. on Thursday. |
• |
Enable Recovery After Erroneous/Bad SQL Statements: Selected to recover transactions that occurred after the Order table was dropped, entered a later time and date in the Start Date/Time. Finally, because the recovery is to be performed to the end of the current Binary Log, the None option was selected for the Stop Date/Time. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 8:00 P.M. on Wednesday.
The DBA decides to recover up to the time right before the Drop Table command was issued. Furthermore, the DBA wants a more precise recovery, so he decides to use a position-based recovery. To accomplish this process, the DBA must restore Sunday’s Full Backup and the subsequent Incrementals performed on Monday and Tuesday, and then perform a position-based PIT Recovery using Wednesday’s Incremental Backup. The following phases illustrate this process:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Monday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Monday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Tuesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Tuesday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Incremental Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Restore Logs to Temporary Directory to Identify Time or Position: Selected to restore only the Binary Logs included in Wednesday night’s Incremental Backup. |
• |
Time Based PIT: Selected as the type, but left all options in the Time Based PIT Details section cleared. |
Use the mysqlbinlog utility against the restored Binary Logs: This step is performed outside of NetVault Backup to identify the position of the Drop Table command that the DBA does not want to restore. (For information on this utility and process, see the MySQL Reference Guide.) In this process, the DBA identified the Drop Table command as log position “805” in the “MYSQLSVR-bin.000009” Binary Log that was restored to the temporary location on the MySQL Server, and both values were noted.
1 |
Select the Incremental Backup performed Wednesday night: The DBA again selects the backup saveset on the Create Restore Job — Choose Saveset page that corresponds to Wednesday’s Incremental Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Apply Binary Logs from Temporary Directory: Selected to target the Binary Logs that were restored to the temporary location in the last phase of this procedure. Because the restored Binary Log was used to identify the specific position that the Drop Table command occupied, this option is selected to tell the plug-in to use this same Binary Log. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Position to “804,” the position in the Binary Logs that exists before the Drop Table command position identified using mysqlbinlog. The Binary Log Containing Stop Position option was used to select the Binary Log, “MYSQLSVR-bin.000009,” that was restored to the temporary directory. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 8:00 P.M. on Wednesday.
The DBA decides to recover up to the time right before the Drop Table command was issued. The DBA also wants to recover the transactions that occurred to the remaining tables from the time after the Orders table was dropped, and up until the end of the backed-up Binary Logs. Furthermore, the DBA wants a more precise recovery, so he decides to use a position-based recovery. To accomplish this process, the DBA must restore Sunday’s Full Backup and the subsequent Incrementals performed on Monday and Tuesday, and then perform a position-based PIT Recovery using Wednesday’s Incremental Backup. The following phases illustrate this process:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Monday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Monday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Tuesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Tuesday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Incremental Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Restore Logs to Temporary Directory to Identify Time or Position: Selected to restore only the Binary Logs included in Wednesday night’s Incremental Backup. |
• |
Time Based PIT: Selected as the type, but left all options in the Time Based PIT Details section cleared. |
Use the mysqlbinlog utility against the restored Binary Logs: This step is performed outside of NetVault Backup to identify the position of the Drop Table command that the DBA does not want to restore. (For information on this utility and process, see the MySQL Reference Guide.) In this process, the DBA identified the Drop Table command as log position “805” in the “MYSQLSVR-bin.000009” Binary Log that was restored to the temporary location on the MySQL Server, and both values were noted.
1 |
Select the Incremental Backup performed Wednesday night: The DBA again selects the backup saveset on the Create Restore Job — Choose Saveset page that corresponds to Wednesday’s Incremental Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Apply Binary Logs from Temporary Directory: Selected to target the Binary Logs that were restored to the temporary location in the last phase of this procedure. Because the restored Binary Log was used to identify the specific position that the Drop Table command occupied, this option is selected to tell the plug-in to use this same Binary Log. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Position to “804,” the position in the Binary Logs that exists before the Drop Table command position identified using mysqlbinlog. The Binary Log Containing Stop Position option was used to select the Binary Log, “MYSQLSVR-bin.000009,” that was restored to the temporary directory. |
• |
Enable Recovery After to Erroneous/Bad SQL Statement(s): Selected this option, and set the Start Position to “806,” the position in the Binary Logs that exists after the Drop Table command position identified using mysqlbinlog. The Binary Log Containing Stop Position option was used to select the Binary Log, “MYSQLSVR-bin.000009,” that was restored to the temporary directory. Finally, because the recovery is to be performed to the end of the named Binary Log, the None option was selected for the Stop Date/Time. |
IMPORTANT: Stop and Start positions must be actual positions listed in a Binary Log, not arbitrary numbers that are greater than the position of the unwanted transaction. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors for the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 6:00 A.M. on Thursday.
The DBA needs to perform a recovery that restores the database up to the time right before the developer dropped the table at 6:00 A.M. on Thursday. Furthermore, the DBA wants a more precise recovery, so he decides to use a position-based recovery. To accomplish this process, the DBA must restore Sunday’s Full Backup and the subsequent Incrementals performed on Monday and Tuesday, and then perform a position-based PIT Recovery using Wednesday’s Incremental Backup. The following phases illustrate this process:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Monday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Monday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Tuesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Tuesday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
Use the mysqlbinlog utility against the current Binary Logs: This step is performed outside of NetVault Backup to identify the position of the Drop Table command that the DBA does not want to restore. (For information on this utility and process, see the MySQL Reference Guide.) In this process, the DBA identified the Drop Table command as log position “805” in the current Binary Log, “MYSQLSVR-bin.000009.”
1 |
Select the Incremental Backup performed Wednesday night: The DBA again selects the backup saveset on the Create Restore Job — Choose Saveset page that corresponds to Wednesday’s Incremental Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to tell the plug-in to use the Binary Log included in the backup. |
• |
Include Current Binary Logs: Selected to tell NetVault Backup to use the current Binary Logs to apply all database transactions that occurred after Wednesday night’s Incremental Backup. This step recovers all transactions that occurred between the completion of the Incremental Backup on Wednesday night, and the time the Drop Table command was issued. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Position to “804,” the position in the current Binary Log that exists before the Drop Table command position identified using mysqlbinlog. Set Binary Log Containing Stop Position to OTHER FILE, and entered the name of the current binary file in the text box, for example, “MYSQLSVR-bin.000009.” |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors for the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 6:00 A.M. on Thursday.
The DBA needs to perform a recovery that restores the database up to the time right before the developer dropped the table at 6:00 A.M. on Thursday. Furthermore, the DBA wants a more precise recovery, so he decides to use a position-based recovery. To accomplish this process, the DBA must restore Sunday’s Full Backup and the subsequent Incrementals performed on Monday and Tuesday, and then perform a position-based PIT Recovery using Wednesday’s Incremental Backup. The following phases illustrate this process:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Monday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Monday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Incremental Backup performed Tuesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Tuesday’s Incremental Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
Use the mysqlbinlog utility against the current Binary Logs: This step is performed outside of NetVault Backup to identify the position of the Drop Table command that the DBA does not want to restore. (For information on this utility and process, see the MySQL Reference Guide.) In this process, the DBA identified the Drop Table command as log position “805” in the current Binary Log, “MYSQLSVR-bin.000009.”
1 |
Select the Incremental Backup performed Wednesday night: The DBA again selects the backup saveset on the Create Restore Job — Choose Saveset page that corresponds to Wednesday’s Incremental Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to tell the plug-in to use the Binary Log included in the backup. |
• |
Include Current Binary Logs: Selected to tell NetVault Backup to use the current Binary Logs to apply all database transactions that occurred after Wednesday night’s Incremental Backup. This step recovers all transactions that occurred between the completion of the Incremental Backup on Wednesday night, and the time the Drop Table command was issued. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Position to “804,” the position in the current Binary Log that exists before the Drop Table command position identified using mysqlbinlog. Set Binary Log Containing Stop Position to OTHER FILE, and entered the name of the current binary file in the text box, for example, “MYSQLSVR-bin.000009.” |
• |
Enable Recovery After to Erroneous/Bad SQL Statement(s): Selected this option, and set the Start Position to “806,” the position in the current Binary Log that exists after the Drop Table command position that was identified using mysqlbinlog. Set Binary Log Containing Stop Position to OTHER FILE, and entered the name of the current binary file in the text box, for example, “MYSQLSVR-bin.000009.” Finally, because the recovery is to be performed to the end of the current Binary Log, the None option was selected for the Stop Position. |
IMPORTANT: Stop and Start positions must be actual positions listed in a Binary Log, not arbitrary numbers that are greater than the position of the unwanted transaction. |
The DBA has established a backup policy in which Full Backups are performed every Sunday at 11:00 P.M. and Differential Backups are performed Monday through Saturday, at 11:00 P.M. Because the DBA is performing Differential Backups, the Binary Logs are kept after each form of this backup — which creates a longer backup, but allows for a faster overall restore.
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it sometime early Thursday before the DBA’s arrival at work.
The DBA decides to perform a complete recovery up to the point of the last Differential Backup — the backup performed on Wednesday night.
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Differential Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Differential Backup. |
2 |
Leave all restore-related Options at their default: None of the options available on the Options tab are used. |
IMPORTANT: The DBA does not need to restore Monday and Tuesday night’s Differential Backups. By choosing to perform Differential Backups, each night’s backup is cumulative, back to Sunday night’s Full Backup; that is, Wednesday night’s backup includes all the Binary Logs that were generated on Monday, Tuesday, and Wednesday — back to Sunday’s Full Backup. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 8:00 P.M. on Wednesday.
The DBA needs to perform a recovery that restores the database up to the time right before the developer dropped the table at 8:00 P.M. on Wednesday. Therefore, the following phases would be performed:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Differential Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Differential Backup. |
IMPORTANT: The DBA does not need to restore Monday and Tuesday night’s Differential Backups. By choosing to perform Differential Backups, each night’s backup is cumulative, back to Sunday night’s Full Backup; that is, Wednesday night’s backup includes all the Binary Logs that were generated on Monday, Tuesday, and Wednesday — back to Sunday’s Full Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to specify PIT Recovery and enable all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to specify the Binary Log included in the backup for use. |
• |
Time Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Date/Time to “19:59” and “10 Jan 2007,” that is, one minute before 8:00 P.M. on Wednesday. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 8:00 P.M. on Wednesday.
The DBA decides to recover up to the time right before the Drop Table command was issued at 8:00 P.M. The DBA also wants to recover the transactions that occurred to the remaining tables from the time after the Orders table was dropped, and up until the end of the backed-up Binary Logs. This decision ensures that he has recovered as many of the transactions as feasible, in addition to recovering the dropped table. Therefore, the following phases would be performed:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Differential Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Differential Backup. |
IMPORTANT: The DBA does not need to restore Monday and Tuesday night’s Differential Backups. By choosing to perform Differential Backups, each night’s backup is cumulative, back to Sunday night’s Full Backup; that is, Wednesday night’s backup includes all the Binary Logs that were generated on Monday, Tuesday, and Wednesday — back to Sunday’s Full Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to specify PIT Recovery and enable all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to specify the Binary Log included in the backup for use. |
• |
Time Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Date/Time to “19:59” and “10 Jan 2007,” that is, one minute before 8:00 P.M. on Wednesday. |
• |
Enable Recovery After Erroneous/Bad SQL Statements: Selected to recover transactions that occurred after the Order table was dropped, entered a later time and date in the Start Date/Time. Finally, because the recovery is to be performed to the end of the restored Binary Log, the None option was selected for the Stop Date/Time. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 6:00 A.M. on Thursday.
The DBA needs to perform a recovery that restores the database up to the time right before the developer dropped the table at 6:00 A.M. on Thursday.
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Differential Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Differential Backup. |
IMPORTANT: The DBA does not need to restore Monday and Tuesday night’s Differential Backups. By choosing to perform Differential Backups, each night’s backup is cumulative, back to Sunday night’s Full Backup; that is, Wednesday night’s backup includes all the Binary Logs that were generated on Monday, Tuesday, and Wednesday — back to Sunday’s Full Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to specify PIT Recovery and enable all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to indicate that the Binary Log included in the backup is to be used. |
• |
Include Current Binary Logs: Selected to use the current Binary Logs to apply entries that occurred between the time the backup was completed on Wednesday, and the issuance of the Drop Table command. |
• |
Time Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Date/Time to “05:59” and “11 Jan 2007,” that is, one minute before 6:00 A.M. on Thursday. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 6:00 A.M. on Thursday.
The DBA decides to recover up to the time right before the Drop Table command was issued. The DBA also wants to recover the transactions that occurred to the remaining tables from the time after the Orders table was dropped, and up until the end of the current Binary Logs. This decision ensures that he has recovered as many of the transactions as feasible, in addition to recovering the dropped table. Therefore, the following phases would be performed:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Differential Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Differential Backup. |
IMPORTANT: The DBA does not need to restore Monday and Tuesday night’s Differential Backups. By choosing to perform Differential Backups, each night’s backup is cumulative, back to Sunday night’s Full Backup; that is, Wednesday night’s backup includes all the Binary Logs that were generated on Monday, Tuesday, and Wednesday — back to Sunday’s Full Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to specify PIT Recovery and enable all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to indicate that the Binary Log included in the backup is to be used. |
• |
Include Current Binary Logs: Selected to use the current Binary Logs to apply entries that occurred between the time the backup was completed on Wednesday, and the issuance of the Drop Table command. |
• |
Time Based PIT: Selected as the type. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Date/Time to “05:59” and “11 Jan 2007,” that is, one minute before 6:00 A.M. on Thursday. |
• |
Enable Recovery After Erroneous/Bad SQL Statements: Selected to recover transactions that occurred after the Order table was dropped, entered a later time and date in the Start Date/Time. Finally, because the recovery is to be performed to the end of the current Binary Log, the None option was selected for the Stop Date/Time. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 8:00 P.M. on Wednesday.
The DBA decides to recover up to the time right before the Drop Table command was issued. Furthermore, the DBA wants a more precise recovery, so he decides to use a position-based recovery. The following phases illustrate this process:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Differential Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Differential Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Restore Logs to Temporary Directory to Identify Time or Position: Selected to restore only the Binary Logs included in Wednesday night’s Differential Backup. |
• |
Time Based PIT: Selected as the type, but left all options in the Time Based PIT Details section cleared. |
Use the mysqlbinlog utility against the restored Binary Logs: This step is performed outside of NetVault Backup to identify the position of the Drop Table command that the DBA does not want to restore. (For information on this utility and process, see the MySQL Reference Guide.) In this process, the DBA identified the Drop Table command as log position “805” in the “MYSQLSVR-bin.000009” Binary Log that was restored to the temporary location on the MySQL Server, and both values were noted.
1 |
Select the Differential Backup performed Wednesday night: The DBA again selects the backup saveset on the Create Restore Job — Choose Saveset page that corresponds to Wednesday’s Differential Backup. |
IMPORTANT: The DBA does not need to restore Monday and Tuesday night’s Differential Backups. By choosing to perform Differential Backups, each night’s backup is cumulative, back to Sunday night’s Full Backup; that is, Wednesday night’s backup includes all the Binary Logs that were generated on Monday, Tuesday, and Wednesday — back to Sunday’s Full Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Apply Binary Logs from Temporary Directory: Selected to target the Binary Logs that were restored to the temporary location in the last phase of this procedure. Because the restored Binary Log was used to identify the specific position that the Drop Table command occupied, this option is selected to tell the plug-in to use this same Binary Log. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Position to “804,” the position in the Binary Logs that exists before the Drop Table command position identified using mysqlbinlog. The Binary Log Containing Stop Position option was used to select the Binary Log, “MYSQLSVR-bin.000009,” that was restored to the temporary directory. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors on the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 8:00 P.M. on Wednesday.
The DBA decides to recover up to the time right before the Drop Table command was issued. The DBA also wants to recover the transactions that occurred to the remaining tables from the time after the Orders table was dropped, and up until the end of the backed-up Binary Logs. Furthermore, the DBA wants a more precise recovery, so he decides to use a position-based recovery. The following phases illustrate this process:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
1 |
Select the Differential Backup performed Wednesday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Wednesday’s Differential Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Restore Logs to Temporary Directory to Identify Time or Position: Selected to restore only the Binary Logs included in Wednesday night’s Differential Backup. |
• |
Time Based PIT: Selected as the type, but left all options in the Time Based PIT Details section cleared. |
Use the mysqlbinlog utility against the restored Binary Logs: This step is performed outside of NetVault Backup to identify the position of the Drop Table command that the DBA does not want to restore. (For information on this utility and process, see the MySQL Reference Guide.) In this process, the DBA identified the Drop Table command as log position “805” in the “MYSQLSVR-bin.000009” Binary Log that was restored to the temporary location on the MySQL Server, and both values were noted.
1 |
Select the Differential Backup performed Wednesday night: The DBA again selects the backup saveset on the Create Restore Job — Choose Saveset page that corresponds to Wednesday’s Differential Backup. |
IMPORTANT: The DBA does not need to restore Monday and Tuesday night’s Differential Backups. By choosing to perform Differential Backups, each night’s backup is cumulative, back to Sunday night’s Full Backup; that is, Wednesday night’s backup includes all the Binary Logs that were generated on Monday, Tuesday, and Wednesday — back to Sunday’s Full Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Apply Binary Logs from Temporary Directory: Selected to target the Binary Logs that were restored to the temporary location in the last phase of this procedure. Because the restored Binary Log was used to identify the specific position that the Drop Table command occupied, this option is selected to tell the plug-in to use this same Binary Log. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Position to “804,” the position in the Binary Logs that exists before the Drop Table command position identified using mysqlbinlog. The Binary Log Containing Stop Position option was used to select the Binary Log, “MYSQLSVR-bin.000009,” that was restored to the temporary directory. |
• |
Enable Recovery After to Erroneous/Bad SQL Statement(s): Selected this option, and set the Start Position to “806,” the position in the Binary Logs that exists after the Drop Table command position identified using mysqlbinlog. The Binary Log Containing Stop Position option was used to select the Binary Log, “MYSQLSVR-bin.000009,” that was restored to the temporary directory. Finally, because the recovery is to be performed to the end of the named Binary Log, the None option was selected for the Stop Position. |
IMPORTANT: Stop and Start positions must be actual positions listed in a Binary Log, not arbitrary numbers that are greater than the position of the unwanted transaction. |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors for the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 6:00 A.M. on Thursday.
The DBA needs to perform a recovery that restores the database up to the time right before the developer dropped the table at 6:00 A.M. on Thursday. Furthermore, the DBA wants a more precise recovery, so he decides to use a position-based recovery. The following phases illustrate this process:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
Use the mysqlbinlog utility against the current Binary Logs: This step is performed outside of NetVault Backup to identify the position of the Drop Table command that the DBA does not want to restore. (For information on this utility and process, see the MySQL Reference Guide.) In this process, the DBA identified the Drop Table command as log position “805” in the current Binary Log, “MYSQLSVR-bin.000009”.
1 |
Select the Differential Backup performed Wednesday night: The DBA again selects the backup saveset on the Create Restore Job — Choose Saveset page that corresponds to Wednesday’s Differential Backup. |
IMPORTANT: The DBA does not need to restore Monday and Tuesday night’s Differential Backups. By choosing to perform Differential Backups, each night’s backup is cumulative, back to Sunday night’s Full Backup; that is, Wednesday night’s backup includes all the Binary Logs that were generated on Monday, Tuesday, and Wednesday — back to Sunday’s Full Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to tell the plug-in to use the Binary Log that was included in the backup. |
• |
Include Current Binary Logs: Selected to tell NetVault Backup to use the current Binary Logs to apply all database transactions that occurred after Wednesday night’s Differential Backup. This step recovers all transactions that occurred between the completion of the Differential Backup on Wednesday night, and the time the Drop Table command was issued. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Position to “804,” the position in the current Binary Log that exists before the Drop Table command position identified using mysqlbinlog. Set Binary Log Containing Stop Position to OTHER FILE, and entered the name of the current binary file in the text box, for example, “MYSQLSVR-bin.000009.” |
On Thursday at 9:00 A.M., the DBA learns that users are encountering “table not found” errors for the Orders table. The DBA then learns that the table no longer exists because a developer unknowingly dropped it at 6:00 A.M. on Thursday.
The DBA decides to recover up to the time right before the Drop Table command was issued. The DBA also wants to recover the transactions that occurred to the remaining tables from the time after the Orders table was dropped, and up until the end of the current Binary Log. Furthermore, the DBA wants a more precise recovery, so he decides to use a position-based recovery. The following phases illustrate this process:
1 |
Select the Full Backup performed Sunday night: On the Create Restore Job — Choose Saveset page, the DBA selects the backup saveset that corresponds to Sunday’s Full Backup. |
2 |
Leave all restore-related Options at their default: None of these options are used. |
Use the mysqlbinlog utility against the current Binary Logs: This step is performed outside of NetVault Backup to identify the position of the Drop Table command that the DBA does not want to restore. (For information on this utility and process, see the MySQL Reference Guide.) In this process, the DBA identified the Drop Table command as log position “805” in the current Binary Log, “MYSQLSVR-bin.000009.”
1 |
Select the Differential Backup performed Wednesday night: The DBA again selects the backup saveset on the Create Restore Job — Choose Saveset page that corresponds to Wednesday’s Differential Backup. |
IMPORTANT: The DBA does not need to restore Monday and Tuesday night’s Differential Backups. By choosing to perform Differential Backups, each night’s backup is cumulative, back to Sunday’s Full Backup; that is, Wednesday night’s backup includes all the Binary Logs that were generated on Monday, Tuesday, and Wednesday — back to Sunday’s Full Backup. |
2 |
Set specific options on the restore-related Options tab: The DBA sets the following options: |
• |
Perform PIT Recovery: Selected to enable this form of restore and all associated options. |
• |
Restore and Apply Binary Logs (Used when Time or Position is already known): Selected to tell the plug-in to use the Binary Log that was included in the backup. |
• |
Include Current Binary Logs: Selected to tell NetVault Backup to use the current Binary Logs to apply all database transactions that occurred after Wednesday night’s Differential Backup. This step recovers all transactions that occurred between the completion of the Differential Backup on Wednesday night, and the time the Drop Table command was issued. |
• |
Enable Recovery Prior to Erroneous/Bad SQL Statement(s): Selected this option, and set the Stop Position to “804,” the position in the current Binary Logs that exists before the Drop Table command position identified using mysqlbinlog. Set Binary Log Containing Stop Position to OTHER FILE, and entered the name of the current binary file in the text box, for example, “MYSQLSVR-bin.000009.” |
• |
Enable Recovery After to Erroneous/Bad SQL Statement(s): Selected this option, and set the Start Position to “806,” the position in the current Binary Log that exists after the Drop Table command position that was identified using mysqlbinlog. Set Binary Log Containing Stop Position to OTHER FILE, and entered the name of the current binary file in the text box, for example, “MYSQLSVR-bin.000009.” Finally, because the recovery is to be performed to the end of the current Binary Log, the None option was selected for the Stop Position. |
IMPORTANT: Stop and Start positions must be actual positions listed in a Binary Log, not arbitrary numbers that are greater than the position of the unwanted transaction. |
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Nutzungsbedingungen Datenschutz Cookie Preference Center