The whole concept of continuous replication has been a fantastic addition to Exchange Server and few can argue with the importance of its inclusion within the product. With Local Continuous Replication (LCR) and Cluster Continuous Replication (CCR), Volume Shadow Copy Service (VSS) backups taken from the passive copy of the database are supported although it’s still possible to take a backup from the active copy. What about testing the consistency of the copy of the database that hasn’t been backed up? Additionally, with the introduction of Standby Continuous Replication (SCR), Microsoft does not support backups taken from the target copy of a database enabled for SCR so how would this copy be checked? Contrast this to the legacy streaming backup API used in earlier versions of Exchange which performed a page-level integrity check of the database as the backup was taken. Microsoft has supplied information about what can be done to manually perform a consistency check against an Exchange 2007 database that has been enabled for continuous replication and in this article we’ll look at the steps required.
It is important to note that this information is not strictly confined to Exchange 2007 SP1 since the procedure also works on the Release to Manufacturing (RTM) version of Exchange 2007. It’s always useful to know how to perform different tasks on different versions of Exchange and in this article I’ll be focusing on a lab CCR environment, although the steps below are essentially the same for other types of continuous replication including the new SCR feature. The whole process involves a mixture of Exchange Management Shell cmdlets as well as other tools supplied with Windows 2003 and Exchange 2007. Let’s get going and see how this method works.
Step 1 – Suspend the Storage Group
The first thing that you need to do is to temporarily stop the transaction log shipping and replaying that occurs on the storage group. This is achieved by running the Suspend-StorageGroupCopy cmdlet. Let’s use the example where the Exchange mailbox server is called E2K7 and the storage group that we wish to work with has the default name of First Storage Group. In this case, the full cmdlet to use is:
Suspend-StorageGroupCopy –Identity “E2K7\First Storage Group”
Once this cmdlet has been executed, a successful operation is indicated simply by the Exchange Management Shell returning back to the prompt. In this case, no news is good news!
Step 2 – Create the Shadow Copy
The next stage of the operation is to create a shadow copy of the volume that contains the databases. In my example scenario, the mailbox database has been stored on drive E: on both CCR nodes. To create the shadow copy of the volume, the Volume Shadow Copy Service Administrative Tool (vssadmin.exe) can be used; this tool is supplied with Windows 2003.
First let’s look at the list of options available with vssadmin by simply running the tool with no options specified. The results are displayed in Figure 1.
Figure 1: Vssadmin Options
As you can see from Figure 1, the list of options is fairly self-explanatory. For example, to create a new shadow copy the commands to use are simply “create shadow”. Running the vssadmin tool with the “create shadow” commands reveals that there are two additional parameters possible, namely the /For={Volume to copy} parameter and the /AutoRetry={number of minutes to attempt retries} parameter. The /AutoRetry parameter is only required to force a retry if another process is already creating a shadow copy. Obviously the /For parameter is required and in my example scenario this will be set to E: since this is the database volume. Therefore, the full command is:
vssadmin create shadow /for=e:
The result of running this command is shown in Figure 2.
Figure 2: Creation of Shadow Copy for E:
You can see that the shadow copy has been successfully created and has both an ID and a volume name. It’s the volume name that we’re interested in but before we go any further we must remember that our storage group is still suspended, so let’s get that going again as we now have our shadow copy available.
Step 3 – Resume the Storage Group
To continue with the transaction log shipping and replaying functionality that occurs on the storage group, we need to run the Resume-StorageGroupCopy cmdlet. As you will remember, the Exchange mailbox server name is E2K7 and the storage group is called First Storage Group. The Resume-StorageGroupCopy cmdlet is essentially identical to the Suspend-StorageGroupCopy cmdlet in that the parameter required is the identity of the storage group which means that the full cmdlet to use is:
Resume-StorageGroupCopy –Identity “E2K7\First Storage Group”
Again, once this cmdlet has been executed a successful operation is indicated simply by the Exchange Management Shell returning back to the prompt.
More on the Shadow Copy
The next step is to run ESEUTIL against the database to check for consistency. However, before we do that, let’s take some time to look a bit more closely at the shadow copy produced by vssadmin. You will remember from Figure 2 above that the shadow copy produced by vssadmin has a volume name associated with it. This is important as we will use this to reference the shadow copy later on. You can also find out a lot more information about this shadow copy by running the following command:
vssadmin list shadows
This produces a list of all shadow copies available but in our case there is only a single shadow copy present at the moment. The result of this command is shown below in Figure 3.
Figure 3: Result of List Shadows Command
From Figure 3 you can see that there is additional information displayed such as details of the original volume that was copied, as well as the originating machine that produced the shadow copy. A shadow copy volume won’t be displayed in Explorer in the traditional sense, so you might be wondering how it’s possible to display the contents of the shadow copy. Well, thanks to Adi Oltean’s blog, one way of doing this involves the use of the command “for /r” which itself is quite complex with many configurable options. You can get full details on this command by entering “for /?” at a command prompt. If you do this, you may notice that we need to define something known as %variable which in our case equates to the need to assign a variable name for the shadow copy volume. I’ll use “SHADOWCOPY” and %s in our command. Therefore, we first need to set “SHADOWCOPY” to point to the shadow copy volume name that we first identified in Figure 2 above and we can do this via the SET command as follows:
set SHADOWCOPY=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
Notice that the volume name has a generation number at the end, which will be incremented each time a shadow copy of this volume is taken. Now that the shorter variable of SHADOWCOPY has been set to the much longer volume name, we can use the following command to list the contents of the shadow copy:
for /r %SHADOWCOPY% %s in (*.*) do @echo %s
An example result of this command is shown in Figure 4. This command loops through every file (*.*) in %SHADOWCOPY% (including a recursion of subfolders via the /r option), assigning the file to the %s parameter. Each value assigned to %s is then echoed to the screen.
Figure 4: Listing the Shadow Copy Contents
As you can see, the shadow copy contains the same file structure as the original volume as you might expect. On the top line of the output you can see the \Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group folder with the Mailbox Database.edb file beneath it. Similarly you can see the catalogdata folders, so we know that our shadow copy volume contains valid data.
Step 4 – Running ESEUTIL
The penultimate step of the overall process is to use the ESEUTIL tool in checksum mode against the copy of the database held in the volume shadow copy. Checksum mode means that we need to use the /k switch. Also, Microsoft states that we need to use the /p switch with a value of 20 added, which, according to the ESEUTIL help file, will add an artificial 1 second delay every 20 IOs. Taking the full path to the Mailbox Database.edb file as obtained from Figure 4 above and remembering to include the path in quotes due to the use of spaces, our full command becomes:
Eseutil /k /p20 “\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\Mailbox Database.edb”
Of course, since we’ve already allocated %SHADOWCOPY% to the shadow copy volume name, you could also use the following shorter command:
Eseutil /k /p20 “%SHADOWCOPY%\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\Mailbox Database.edb”
The result of running this command is shown below in Figure 5, where you can see that the process is almost complete.
Figure 5: ESEUTIL in Progress
Once the ESEUTIL process has finished, you should see a screen similar to the one shown in Figure 6. In this case, the process has completed successfully but you’ll note that this was against a really small and clean test database.
Figure 6: ESEUTIL Completion
So there you have it – a database held in volume shadow copy that has been checked via the ESEUTIL tool.
Step 5 – Delete the Shadow Copy
Now that you’ve proved the database is consistent, the last thing to do is to clean up by removing the volume shadow copy since this is no longer needed. As you might expect, this can be achieved by running the vssadmin.exe tool once more. This time, we can use the “delete shadows” commands to delete our shadow copies. Note the fact that “shadows” is plural this time, unlike when we created the shadow copy. Our command to use is therefore:
vssadmin delete shadows /for=e:
You will be prompted to confirm that you are sure you wish to delete the volume shadow copy unless you also use the /Quiet command.
Summary
As stated earlier in this article, use of the continuous replication feature of Exchange 2007 could mean that you need to manually check the consistency of the copy of the database. Use of a mixture of Exchange 2007 cmdlets and Windows 2003 tools allows us to do this as you’ve seen from the above series of steps.
