SnapManager Restore enables you to restore your Exchange databases from a backup that you created previously with SnapManager Backup, or from an archive, then optionally recover the databases up to their current state by replaying the associated transaction logs. This would become necessary if your Exchange data became corrupted or unavailable.
SnapManager 3.1 for Microsoft Exchange supports restoring an entire storage group or an individual database.
SnapManager Restore uses the following process when restoring from a backup.
Caution
If you are restoring in a Windows cluster, do not attempt to manage any cluster resources while the restore is running.
| 1 |
Checks that the selected backup was verified, or that the Database Verification Override was selected. Caution |
| 2 |
Creates a snapshot of the volume containing the storage group or database to be restored, so that the pre-restore state is preserved. |
| 3 | |
| 4 | |
| 5 |
Uses the Exchange recovery process to play forward transaction logs into the restored databases. Note |
You can use SnapManager Restore to do either of the following types of restore:
In an up-to-the-minute restore, all the transaction logs that were not committed to the databases, from the time the backup set was created up to the most current time, are played forward and applied to the databases. This includes transaction logs from the backup sets, as well as the existing transaction logs in the transaction log directory. A contiguous set of transaction logs is required for an up-to-the-minute restore to succeed.
This option is selected by default.
Suppose you run SnapManager Backup every day at noon, and on Wednesday at 4 p.m. you decide to restore from a previous backup. For some reason, the backup set from Wednesday lunchtime failed verification, so you decide to restore from the Tuesday lunchtime backup. After that backup is restored, all the transaction logs are played forward and applied to the restored databases, starting with those that were not committed when you created Tuesday's backup set and continuing through the latest transaction log written on Wednesday at 4 p.m.
In this case, only the transaction logs that existed in the active file system at the time the backup was taken (and were not committed to the databases) are replayed. All the transaction logs beyond the point-in-time that exist in the transaction log directory belonging to the restored storage group are removed.
You can use this method to restore a database or storage group back to a time before a corruption occurred.
For more information about choosing the restore type, see Guidelines for choosing the type of restore to perform.
Using SnapManager 3.1 for Microsoft Exchange, you can override the verification requirement when restoring from a SnapManager backup. However, NetApp strongly recommends that you restore only from verified backups. The verification process protects you from restoring a backup with any physical-level corruption. Physical-level database corruption can occur silently in Exchange databases. The only way to know whether a particular database backup incurred physical-level corruption is to run database verification on that backup.
For Exchange 2003 running on Windows 2000, when the Exchange Recovery Storage Group is present, Exchange automatically performs any restore to that storage group. Therefore, SnapManager Restore cannot function correctly if a Recovery Storage Group is present in this configuration.
If you are running Exchange 2003 on Windows 2000, and you configured a Recovery Storage Group, you need to delete it or override the Recovery Storage Group restore redirection before a SnapManager Restore can be completed successfully. For more information about overriding the Recovery Storage Group restore redirection, see Microsoft KB article 824126.
Every time you perform a restore, a snapshot is created on the volume containing the transaction logs. The name of this snapshot contains the prefix "rstrsnap".
After you verify that a restore was completed successfully and you are satisfied with the results, you can delete the restore snapshot using the Action menu. For details, see Deleting backups using the Action menu.
When you perform a restore, you can optionally choose to decrease the time the restore takes by skipping the pre-restore transaction log sequence and database metadata checks. If you skip these checks, and a problem exists with your transaction log sequencing or your database metadata, your restore will fail.
You can choose from the following metadata checks:
For this option, select both the Verify Transaction Log Sequence... and the Exhaustive Verification check boxes.
For more information about this option, see What the exhaustive transaction log sequence verification does.
For this option, select the Verify Transaction Log Sequence... check box and clear the Exhaustive Verification check box.
For more information about this option, see What the non-exhaustive transaction log sequence verification does.
For this option, clear both the Verify Transaction Log Sequence... and the Exhaustive Verification check boxes.
Note
For backward compatibility with previous SnapManager versions, select the exhaustive check, which is selected by default.
The exhaustive option of the transaction log sequence verification performs the following checks:
The non-exhaustive option of the transaction log sequence (selected if you clear the Exhaustive Verification check box) uses the transaction log file names to verify that the transaction log sequence is correct and that all log files are present.
When running on Windows 2000 Server, SnapManager Restore creates temporary files. Usually, these files are deleted after the restore is done, but you can retain them for debugging by selecting the Keep Log and Patch Files in Temp Directory After Restore check box in the Restore tab or Wizard.
If the directory or subdirectory you specify to contain these files does not exist, SnapManager creates it automatically. SnapManager does not access this directory directly. Rather, it is accessed through the administrative share for the drive letter specified, for example, C$. If the administrative share does not exist, SnapManager prompts you for whether you want SnapManager to create the share automatically.
Note
The temporary files cannot be placed in the root directory. For example, C:\Temp is a valid location for the temporary files; putting them in C:\ causes the restore to fail.
SnapManager takes the storage group that is to be restored offline before performing the restore, if that storage group is still online.
In a Windows cluster, all resources that are directly or indirectly dependent on the LUN that is to be restored are taken offline, as well as the LUN itself. This means that the entire Exchange virtual server (all storage groups) is offline.
If a cluster move group operation occurs during the restore (for example, if the node that owns the resources goes down) you must restart the SnapManager user interface and the restore.
If you perform a point-in-time backup from the most recent backup and then decide to perform an up-to-the-minute backup from the same backup, SnapManager will successfully complete each operation. However, the results might not be what you intended, because any transactions that occurred after the backup was taken and before the point-in-time restore will not be restored. The reason is that when you perform the point-in-time restore, the transaction logs containing transactions recorded after the selected backup are removed.
For this reason, use caution when selecting a point-in-time restore.
Copyright © 1994-2004, Network Appliance, Inc. All rights
reserved.
Part No. 215-00858
File: restore2.htm
Last updated: Tue Jun 15 15:34:12 2004