permalink | sidebar | keywords | summary |
---|---|---|---|
protect-scsql/task_restore_a_sql_server_database_from_secondary_storage.html |
sidebar |
restore operation |
You can restore the backed-up SQL Server databases from the physical LUNs \(RDM, iSCSI, or FCP\) on a secondary storage system. The Restore feature is a multiphase process that copies all of the data and the log pages from a specified SQL Server backup residing on the secondary storage system to a specified database. |
You can restore the backed-up SQL Server databases from the physical LUNs (RDM, iSCSI, or FCP) on a secondary storage system. The Restore feature is a multiphase process that copies all of the data and the log pages from a specified SQL Server backup residing on the secondary storage system to a specified database.
-
You must have replicated the Snapshots from primary to secondary storage system.
-
You must ensure that the SnapCenter Server and the plug-in host are able to connect to the secondary storage system.
-
Most of the fields on the Restore wizard pages are explained in the basic restore process. The following information describes some of the fields for which you might need guidance.
For SnapLock enabled policies, for ONTAP 9.12.1 and below version, if you specify a Snapshot locking period, the clones created from the tamper proof Snapshots as part of restore will inherit the SnapLock expiry time. Storage admin should manually cleanup the clones post the SnapLock expiry time.
-
In the left navigation pane, click Resources, and then select SnapCenter Plug-in for SQL Server from the list.
-
In the Resources page, select Database or Resource Group from the View drop-down list.
-
Select the database or resource group.
The database or resource group topology page is displayed.
-
In the Manage Copies section, select Backups from the secondary storage system (mirrored or vault).
-
In the Location page, choose the destination volume for restoring selected resource.
-
Complete the Restore wizard, review the summary, and then click Finish.
If you restored a database to a different path that is shared by other databases, you should perform a full backup and backup verification to confirm that your restored database is free of physical-level corruption.