It is important to understand how a SnapManager restore operation works before performing one.
SnapManager restores the databases that you select 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 can require additional time and free space on the storage system as compared to an online Snapshot copy restore.
SnapManager uses LUN, SMB share, and VMDK cloning if you are restoring from a backup set that contains multiple databases that reside on the same LUN, SMB share, or VMDK.
SnapManager uses the copy-based restore method if any of the following conditions are true:
In a volume-wide backup, all the databases that reside on a single volume are backed up concurrently using Snapshot copies. Because the maximum number of databases supported per storage system volume is 35, the total number of Snapshot copies created equals the number of databases divided by 35.
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.
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 operation, you have recent Snapshot copies of the LUNs, SMB shares, or VMDKs 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:
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 restored Snapshot copy.
SnapManager can restore databases in a Windows cluster without taking the SQL Server cluster group offline.
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 and then restart the restore operation.
A SnapManager transaction log restore uses the SQL recovery process to play forward transactions from the log backup into the restored database.
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.
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|
Circled check mark
The databases in this backup have been verified.
Circled question mark
The databases in this backup have not been verified.
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.