When disaster strikes and the database or log files in the active copy of the storage group have become corrupted...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
and have shut down, you have the option to recover database availability by switching to the LCR copy (the passive copy of the storage group).
So the command to run in the EMS is:
Restore-StorageGroupCopy -Identity "First Storage Group" -ReplaceLocations:$true
An integrity check will now be passed for the log files, and if it's completed without errors, the storage group copy switch will be completed and the production paths will be updated, as shown in Figure 8.10.
All there is to do now is to mount the database using either the EMC or the EMS. Now notice that the Database File Path will have changed, as shown in Figure 8.11.
|Note: When you have run the Restore-StorageGroupCopy CMDlet against a storage group, LCR for the respective storage group will be disabled. So remember to re-enable LCR for the particular storage group after you perform a switch to the LCR copy.|
Although this method is straightforward and fully supported, Microsoft actually recommends that instead you use a method whereby you run the Restore-StorageGroupCopy CMDlet without the ReplaceLocations parameter, to activate the copy in its current location, and then either move the files manually, change drive letters, or use mount point assignments to have the copy files reflected under the respective production paths so that the production database is maintained in the expected location. Following this method means that the active storage group copy will continue to have meaningful filenames that represent that they indeed are active production copies. Why is this the preferred method? Because Microsoft believes that using the Restore-StorageGroupCopy CMDlet with the ReplaceLocations parameter could lead to future confusion in distinguishing the active copy of the data from the passive copy of the data, and to be honest, we agree. That said, we cannot see why you shouldn't use the ReplaceLocations parameter if you know what you're doing; just make sure that you switch back to the original disk set again.
Let's examine an example of how you would use the recommend method. First, make sure that the production database is dismounted. Then open the EMS and type Restore- StorageGroupCopy-Identity "First Storage Group".
This command will activate the copy and leave the path for the production storage group intact. Now you can choose between either moving the LCR copy files to the location of the original production database manually using Windows Explorer or using Xcopy or a similar tool. Just be sure to move or delete the files in the folder you move the files to first. When the files have been moved, you simply need to mount the database again, and that's it.
The second option available when using the Restore-StorageGroupCopy CMDlet without the ReplaceLocations parameter is to change the drive letter for the partition holding the LCR copy to the drive letter used by the production storage group. This can be done using either the Disk Management MMC snap-in or the Diskpart tool.
- To do so using the MMC snap-in, click Start -> Run and type Diskmgmt.msc. This will bring up the MMC snap-in shown in Figure 8.12. Now right-click the partition holding the production storage group and its database, then select Change drive letter and paths in the context menu.
- In the Change Drive Letter and Paths For window, click Change, then specify an unallocated drive letter and click OK, as shown in Figure 8.13.
- Click OK to the confirmation message and click OK to close the Change Drive Letter and Paths window.
- Now change the drive letter for the partition holding your LCR copy to the drive letter that originally was assigned the partition that holds the production storage group, which in this example is E:.
It's important that the partition for which you change the drive letter for doesn't contain any other data used by other applications. If it does, you will most likely destroy functionality for the respective applications!
When you have changed the drive letter, all there is to do is to mount the database again, but remember, the paths for the active and passive storage groups must be the same on each partition.
|Note: A restart of the server might be required for you to be able to assign the E: drive to the partition holding the LCR copy.|
The last option available involves the use of mount points.A mount point is a feature with which you can surpass the 26-drive-letter limitation that exists in Windows 2003 Server. Using volume mount points, you can graft, or mount, a target partition into a folder on another physical disk. Since volume mount points are transparent to Exchange 2007 as well as most other programs, they are pretty popular, especially in deploying Exchange 2000/2003 cluster environments.
To use mount points to switch LCRstorage group copies, you must already have configured the partitions holding the storage group copies to use them. If you haven't done so, the mount point option cannot be used. In this example, the Third Storage Group's folder as well as the LCR copy for this storage group, which is called Third Storage Group, point to an NTFS volume mount point.
You can see whether a particular folder in Windows Explorer is a mount point because the icon is represented as a disk and not the normal yellow folder icon (see Figure 8.14).
- As is the case with the options we have covered, the first thing you should do before switching the storage group copies using NTFS volume mount points is to make sure that the database is in a dismounted state. If this is not the case, you should dismount it manually now. The next step is to open the EMS and type Restore-StorageGroupCopy-Identity " Third Storage Group" (which is the storage group used in this example).
- Next open the Disk Management MMC snap-in, right-click the partition that is used as the NTFS volume mount point by the production storage group, then select Change Drive Letter or Paths in the context menu. In the Change Drive Letter and Paths window, remove the existing path by highlighting it, then click the Remove button (see Figure 8.15).
- You now need to confirm that you want to remove the path. Click Yes.
- Now remove the mount point for the partition used for the LCR copy, using the same steps.This is required to be able to use the LCR copy path as a mount point for the Production Storage Group copy.
- We're now ready to mount the LCI:L copy to the Production Storage Group. We do so by right-clicking the partition that was used for the LCR copy, then choosing Change Drive Letter or Paths in the context menu. Now click Add and select Mount in the following empty NTFS folder. Click Browse and specify the path to the production storage group (see Figure 8.16). Finally, click OK twice and close the Disk Management MMC snap-in.
- Now verify that the folder within Windows Explorer contains the expected data, and then mount the database again.
Is that cool or what?
Managing Local Continuous Replication in Exchange 2007
Part 1: Exchange 2007 Local Continuous Replication overview
Part 2: Enabling Local Continuous Replication on a storage group
Part 3: Viewing the status for a Local Continuous Replication copy
Part 4: Switching to the LCR copy for database disaster recovery
Part 5: Suspending and resuming LCR for an Exchange 2007 storage group
Part 6: Manually adding an Exchange 2007 database to a storage group copy
Part 7: Use Exchange Eseutil for a passive storage group copy integrity check
Part 8: Disabling LCR on an Exchange 2007 storage group
Part 9: Adding Local Continuous Replication performance objects and counters
Part 10: Exchange 2007 LCR administration summarized
|This chapter excerpt from How to Cheat at Configuring Exchange Server 2007: Including Outlook Web, Mobile, and Voice Access, by Henrik Walther, is printed with permission from Syngress, a division of Elsevier, Copyright 2007.
Click here for the chapter download.
Dig Deeper on Microsoft Exchange Server Backup and Disaster Recovery