Switching to the LCR copy for database disaster recovery

When Exchange 2007 log files and databases become corrupted, the Exchange Local Continuous Replication copy can recover database availability. Learn the methods here.

When disaster strikes and the database or log files in the active copy of the storage group have become corrupted

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).

You are reading part 4 from "Managing Local Continuous Replication in Exchange 2007," excerpted from Chapter 8 of the book "How to Cheat at Configuring Exchange Server 2007: Including Outlook Web, Mobile, and Voice Access," by Henrik Walther, copyright 2007, published by Syngress, a division of Elsevier.
You can recover from corruption of either one or more log files or the database using a variety of methods, depending on whether you use mount points or not. One method is to run the Restore-StorageGroupCopy CMDlet with the ReplaceLocations parameter, which will activate the LCR copy as the active storage group copy in one step. To activate the LCR copy as the active storage group, you first need to make sure that the active database is dismounted, which should already be the case if it's corrupted. If this is not the case, you should dismount it now. When you have done so, we're ready to run the Restore-StorageGroupCopy CMDlet, which in the case of this example is done for the First 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.

Switching to the LCR copy using the Restore-
StorageGroupCopy CMDlet.
Figure 8.10 Switching to the LCR copy using the Restore- StorageGroupCopy CMDlet. (Click on image for enlarged view.)

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.

Database file path change.
Figure 8.11 Database file path change. (Click on image for enlarged view.)

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.

  1. 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.
  2. 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.
  3. The Disk Management MMC Snap-in.
    Figure 8.12 The Disk Management MMC Snap-in. (Click on image for enlarged view.)

    Specifying the Drive Letter for the partition.
    Figure 8.13 Specifying the Drive Letter for the partition. (Click on image for enlarged view.)

  4. Click OK to the confirmation message and click OK to close the Change Drive Letter and Paths window.
  5. 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).

The Mount Point icon in Windows Explorer.
Figure 8.14 The Mount Point icon in Windows Explorer. (Click on image for enlarged view.)

  1. 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).
  2. 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).
  3. Changing the NTFS volume mount point path.
    Figure 8.15 Changing the NTFS volume mount point path. (Click on image for enlarged view.)

  4. You now need to confirm that you want to remove the path. Click Yes.
  5. 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.
  6. 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.
  7. Specifying the new path for the NTFS volume mount point.
    Figure 8.16 Specifying the new path for the NTFS volume mount point. (Click on image for enlarged view.)

  8. 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

 Home: Introduction
 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

 How to cheat at configuring Exchange Server 2007 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.

This was first published in February 2008

Dig deeper on Microsoft Exchange Server Backup and Disaster Recovery

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close