• |
Complete database restore: With a Simple Recovery Model database, the goal of a complete database restore is to restore the entire database. This type of restore typically involves restoring a Full Database backup or a Full Database backup followed by a Differential Database backup. The entire database is offline during a complete database restore. |
• |
File restore: In a file restore for a Simple Recovery Model database, the goal is to restore one or more damaged read-only files without restoring the entire database. This type of restore involves a Full File and Filegroup backup. |
• |
Partial database restore: A partial restore for a Simple Recovery Model database includes restoring the primary filegroup and all read/write filegroups that were included in a Partial Database or Differential Partial Database backup. Restores of the read-only filegroups with a Full File and Filegroup backup are required only if the read-only filegroups are damaged. |
• |
Complete database restore: Under the Full and Bulk-Logged Recovery Models, the goal is to restore the entire database to the point-of-failure. A complete restore sequence typically includes: |
1 |
Perform Tail-Log backup. |
2 |
Restore Full Database or Full File and Filegroup backup while selecting With NO RECOVERY restore option. |
3 |
Restore Differential Database or Differential File and Filegroup backup while selecting With NO RECOVERY restore option. |
4 |
Restore all subsequent Incremental Transaction Log backups in order while selecting the With NO RECOVERY restore option. |
5 |
• |
File restore: In a file restore for a Full or Bulk-Logged Recovery Model database, the goal is to restore the entire database while leaving the option available to restore damaged files without restoring the entire database. This type of restore involves the following restore sequence: |
1 |
Perform Tail-Log backup. |
2 |
3 |
4 |
Restore all subsequent Incremental Transaction Log backups in order while selecting the With NO RECOVERY restore option. |
5 |
• |
Point-in-time (PIT) recovery: You can perform a PIT recovery on the transaction logs that are restored during an Incremental Transaction Log restore. Plug‑in for SQL Server supports both time-based — using hours:minutes:seconds — and marked-transaction-based PIT recovery. PIT recovery options are available when restoring Incremental Transaction Log and Tail-Log backups. |
• |
Time-Based Point-in-Time Recovery: 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:00 A.M., PIT recovery can be performed with a stop time of 5:55:00 A.M. Time-based PIT recovery can only be used for unrelated databases; therefore, when multiple SQL Server® databases are required to be logically consistent, marked-transaction PIT recovery should be used. |
• |
Marked-Transaction-Based Point-in-Time Recovery: SQL Server 2005 and later support the ability to insert named marks into a transaction log to allow recovery to a specific mark. This functionality is beneficial if you have two or more databases that must be logically consistent. You can implement special procedures to ensure the recoverability of these databases after a restore. Because you can only recover related databases to a marked transaction, your application must be configured to insert named marks into the transaction log before performing backups. For more information, see Ensuring Recoverability of Related Databases and the Recovering to a Marked Transaction in the SQL Server Books Online. |
© ALL RIGHTS RESERVED. 使用条款 隐私 Cookie Preference Center