Restoring a storage system volume using backups archived with SnapVault

Using SQL Server Enterprise Manager or SQL Server Management Studio, detach the failed databases to be recovered from archive.

If the source LUNs for the failed databases are still online and mapped on the primary storage, do the following:

1. Note the LUN drive letter assignments.
2. Unmap the LUNs using FilerView or the lun command on the storage system console.
3. Destroy the LUNs using FilerView or the lun command on the storage system console.

   Do not delete the SnapInfo LUNs.

4. In MSCS configurations, remove any cluster resource dependencies you might have configured on these LUNs.

Delete the source qtrees where the LUNs once resided.

Qtrees are deleted the same way a regular folder is, using Windows Explorer. The primary storage volume should have a share created on it. You can browse to the share via a UNC path or by mapping a drive letter to it. The qtrees will look like regular folders under the root of the volume (share).

Run the Computer Management MMC, then right click on the Disk Management icon and select Rescan Disks. This will clear out any drive letters that might remain from the disconnected LUNs.

Perform a SnapVault restore using the snapvault restore command, specifying one of the archived Snapshot copies as the source. Restore only the qtrees that contain the databases and transaction logs that you want to restore.

Note
SnapVault restores entire qtrees; therefore, any data in the same qtree as the desired LUN will also be overwritten.

Following is an example where the Snapshot copy sqlsnap_srvr1.0 on the SnapVault secondary storage system is used to recover the qtree db1 on the primary storage system filer_pri.

Snapvault restore -s sqlsnap_srvr1.0 -S filer_sec:/vol/sv_SQL/Srvr1_db1 filer_pri:/vol/Srvr1/db1

Attention
Do not perform a SnapVault restore of the qtree where the SnapInfo LUN resides. Instead, you will mount the LUN in Snapshot copy on the secondary storage system in a subsequent step. The reason for doing this is that performing a restore of the SnapInfo LUN on the primary storage will overwrite all SnapInfo data for all other databases on the SQL Server, whether part of the same backup set or not. This will overwrite newer backup sets for all of the databases on the SQL Server, and you could experience an inability to restore backup sets that were not part of this restore.

Note
You can monitor the status of the recovery transfer by issuing the snapvault status command at the storage system console. When the recovery transfer is complete, its status will be listed as "Broken-off" by the snapvault status command. This does not necessarily indicate that the transfer was successful, only that it is complete. Any errors encountered by SnapVault will be posted directly to the storage system console.

Reinitialize the original SnapVault relationship.

This can be done by issuing a command similar to command used to create the relationship in earlier steps.

snapvault start -r -S filer_pri:/vol/Srvr1/db1 filer_sec:/vol/sv_SQL/Srvr1_db1

SnapVault does not automatically delete the residual Snapshot copy that was used for the restore, because the copy is required to be in place for this step. It is the only common Snapshot copy and is the basis of restarting the relationship.

Delete the residual Snapshot copy left by the SnapVault restore operation.

Do this using FilerView or by using the snap delete command at the primary storage system console. A residual Snapshot copy is distinguished by the following syntax:

primary host (nvram_id)_vol1_mytree-dst.2

Using FilerView or the lun command on the storage system console, unmap the newly restored LUNs.

Run the Computer Management MMC, then right click on the Disk Management icon and select Rescan Disks. This will clear out any mappings from the newly restored LUNs. This step is intentionally performed twice in this procedure.

Use SnapDrive to reconnect to the newly restored LUNs.

Use SnapDrive to connect to the SnapInfo LUN. This LUN needs to be connected on the secondary storage system, using the same Snapshot copy as was used to restore the LUNs in the previous step.

Be sure to keep this LUN mounted for as little time as possible. If a Snapshot copy is created on the secondary storage volume while the LUN backed up by the Snapshot copy is mounted, it will create a "busy Snapshot." The chances of this are increased in configurations in which a single secondary storage volume is used to coalesce Snapshot copies from numerous primary storage qtrees.

Note
On Windows Server 2003 Enterprise systems, check to make sure that all of the restored LUNs are writable by creating and then deleting a temporary file or folder. If you find that one or more LUNs are write-protected, use the SnapDrive MMC to disconnect those LUN again. Reconnect to them a second time using the same drive letter.

Exit SnapManager if it is running, then restart it from the command- line using the optional command-line switch -restorearchive or /restorearchive.

Example:

C:\Program Files\NetApp\SnapManager for SQL Server\SnapManager.exe -restorearchive

Using this command-line option brings up SnapManager in a mode that enables the restore-from-archive procedure to work.

In the Restore from Archive window, enter or browse to the SnapInfo directory corresponding to the latest backup for the first storage group you want to restore. This will be located on the LUN backed up by Snapshot copy on the secondary storage volume, which you connected to in the previous step.

If you have multiple-instances or databases to restore from the same backup set, you might need to restore them one at a time. Wait until the first restore finishes, then press the F5 key to open the Restore from Archive window again. This enables you to specify the SnapInfo directory for the next database or instance. Be sure to select the directory corresponding to the most recent backup in that archive set.

Note
If this is a disaster recovery scenario and the LUN on the primary storage system containing the SnapInfo directory was lost, the LUN will need to be re-created using SnapDrive before SnapManager can be used to perform the restore. Create the LUN using the same drive letter that the original LUN had.

Perform a point-in-time restore.

Verify the database data updated by the point-in-time restore operation.

Exit SnapManager.

Disconnect the SnapInfo LUN in the Snapshot copy on the secondary storage.

Launch SnapManager again, this time without the -restorearchive command-line option, and then perform a backup immediately.

After a database has been restored from archive, previously created backups will no longer be available. will You need to delete these orphaned SnapManager Snapshot copies manually using FilerView or the storage system console. Ensure that they do not belong to any other backup sets by comparing the time stamps in the Snapshot copy names to the timestamps on backups that might still be valid for any storage groups that were not restored from archive.