Understanding SnapManager Restore

SnapManager Restore restores the SQL Server databases you select. For more information, see the following topics:

Sources for a restore operation

SnapManager Restore enables you to restore databases from a SnapManager backup set.

Restore from a SnapManager backup set

You can restore databases from SnapManager backup sets created for the same SQL Server instance or created for a different instance. The LUNs containing the selected SQL Server's databases are restored from the backup.

If SQL Server system databases fail, they can be restored from stream-based SnapManager backup sets of those databases. For more information, see Restoring system databases from SnapManager backup sets.

Restore from an archive of SnapManager backup sets

You can also use SnapManager Restore to restore databases from offline archives of Snapshot copies containing SnapManager backup sets.

For information about creating offline archives of Snapshot copies containing SnapManager backup sets, see Chapter 13, Archiving SnapManager Backups.
For information about recovering SQL Server databases from archives, see Recovering SQL Server databases using archives.

Restore an online database as a new database

You can use SnapManager Restore to restore an online database as a new database on the same SQL Server instance. However, you cannot restore an online database as a new database on a different SQL Server instance.

Destinations for a restore operation

You can restore databases to various types of destinations.

Restore to the original database location

By default, SnapManager restores to the same database names and on the same SQL Server instance.

Restore to an alternate location

Instead, you can use any combination of the following options to restore databases to alternate locations:

Restore to different database names
Restore to a different SQL Server instance on the same or different SQL Server computer

Restore to a temporary, alternate location

The database is mounted at a temporary, alternate location using a writable Snapshot copy, and then the transaction logs are applied. Because the logs are applied, the data is current.

Mount at a temporary, alternate location without restoring

The database is mounted at a temporary, alternate location, but the transaction logs are not applied. Because the data is not current, you should use this function to view only the layout of the data.

Databases restored to or mounted at temporary, alternate locations

The following information applies to databases that have been restored to or only mounted at temporary, alternate locations using writable Snapshot copy.

Backup set label

A database restored to or mounted at a temporary, alternate location is listed in the Backup and Verification tab with the following label:

SnapLUN

Backup set name

If the database name already exists on the server, or if the backup set consists of more than one database, the database is listed using the following naming convention:

databasename__Mount

Avoiding a busy Snapshot condition

Explicitly detach the temporary database and dismount the Snapshot copy LUNs as soon as you finish viewing the data or data layout, otherwise you might encounter a busy Snapshot condition when you attempt to delete the Snapshot copy. There are two ways to do this:

If the database was restored with a post-restore state of Read-Only or is in the loading state and you cannot bring the database into read-write mode, use SQL Server Enterprise Manager or Management Studio and SnapDrive.
Otherwise, use a SnapManager function that is available from the Backup and Verification tab.

For a detailed description, see Detaching a database and dismounting Snapshot LUNs.

How SnapManager Restore works

The following list summarizes the steps that SnapManager performs when restoring databases from a backup set:

SnapManager Restore checks the SnapManager license.
If the "Create transaction log backup before restore" option is selected, the transaction log is backed up before the restore is performed.
Note
If you are restoring to a temporary, alternate location using a writable Snapshot copy, a transaction log backup will not be created before the restore, even if this option is selected. If you want to create a transaction log backup, do so as a separate operation before you restore to the alternate location.

For reasons to deselect this option, see Understanding the restore options.
All of the databases that reside on the LUN in a selected backup set are restored to the active file system. The restore method used by SnapManager depends on (1) the method that was used to create the backup set and (2) the specific subset of databases you choose to restore from the backup set.
SnapManager uses the stream-based restore method if you are restoring from a stream-based backup set. With this method, each of the databases is restored individually. Depending on the composition of the backup set, a stream-based restore could require additional time and free space on the storage system as compared to an online Snapshot copy restore.

SnapManager uses the online Snapshot copy restore method if you are restoring from a backup set that contains all of the databases that reside on the same LUN. Starting with Data ONTAP 7.1, online Snapshot copy restore speed increased significantly, due to the replacement of the single-file SnapRestore method (SFSR) with the LUN clone split restore method.

SnapManager uses the copy-based restore method if any of the following conditions are true:
- The backup set contains only a subset of the databases that reside on the same Data ONTAP LUN (not recommended).
- You select only a subset of the databases contained in the backup set.
- A new database was added to the same LUN after the backup was created.
- The backup was split when the number of databases sharing one or two LUNs exceeded the maximum concurrent database setting. For more information, see Using the Number of Databases that Can Be Backed Up Concurrently screen.
If the database has transaction log backups, SnapManager Restore can apply the transaction log backups (if necessary).
Depending on the database restore option selected, SnapManager Restore performs a point-in-time restore or an up-to-the-minute restore.

Restore Snapshot copies

Every time you perform a restore operation using SnapManager, SnapManager first creates a Snapshot copy on each storage system volume that contains files for the databases you will be restoring. That way, in the unlikely event that a catastrophic failure occurs during a restore, you have recent Snapshot copies of the LUNs that can be used to re-create those databases as they existed prior to the start of the failed restore operation.

Each restore Snapshot copy is named using the following naming convention:

rstrsnap__SqlServerName_date_time

The Snapshot copy name contains the name of the SQL Server instance to which the backup was restored (indicated by the variable SqlServerName) and the Snapshot copy creation date and time (indicated by the variable date_time).

After you verify that a restore was completed successfully and you are satisfied with the results, you can delete the restore Snapshot copy. For details, see Deleting restored Snapshot copies.

SQL Server cluster group state during a restore

If you are using SnapDrive 4.1, SnapManager 2.1 can restore databases in a Windows cluster without taking the SQL Server cluster group offline while restoring a LUN. This requires that you have set a registry variable on the Windows host so that SnapDrive can restore the MSCS LUN without taking the resource offline. This requirement is described in the procedure Installing SnapManager and creating a new Windows cluster.

This feature was introduced in SnapManager 2.0 and is available only if you are using SnapDrive 3.2 and higher versions.

Cluster failure during a restore operation

If a cluster failure (a cluster group move operation) occurs during the restore operation--for example, if the node that owns the resources goes down--you must reconnect to the SQL Server instance, restart the SnapManager user interface, and then restart the restore operation.

Transaction log restore operations

A SnapManager transaction log restore uses the SQL recovery process to play forward transactions from the log backup into the restored database.

Importance of verifying databases to be restored

The database verification process protects you from restoring a backup that contains any physical-level corruption. Physical-level database corruption can occur silently in SQL Server databases. The only way to know whether a particular database backup incurred physical-level corruption is to run database verification on that backup.

Before allowing a restore operation to proceed, SnapManager enables you to check that the selected backup set was verified through the use of DBCC CHECKDB.

Backup verification status

SnapManager Restore shows you a list of the backups that have been taken. For each backup, the date and time of the backup is displayed, as well as an icon that indicates the backup verification status.

Icon description	Backup verification status
Green-circled black check mark	The databases in this backup have been verified.
Yellow-circled black question mark	The databases in this backup have not been verified.

Note
If you select a database on which a consistency check has not been run successfully, SnapManager prompts (but does not require) you to run DBCC before performing a restore. Running database consistency checking as part of recovery increases the time the recovery takes.