Cutting over to an Exchange 2010 lagged database copy

Exchange 2010 allows us a new replication topology when it comes to our mailbox databases, DAG (Database availability groups). You may have noted I didn’t use the general term databases. Public folder databases cannot be used in a DAG. Now to avoid corruption passing to Db copies throughout your organization we now have a capability to use a Lagged copy of the database. which still has all of the transaction logs but just have not applied them.

Walter from this week’s 10135 class was looking for some more information on the entire process of activating a lagged copy and more specifically

“what do I do with the transaction logs if I know where the corruption occurred?”

here ya go buddy – taken from this page – Activate a Lagged Mailbox Database Copy

A lagged mailbox database copy is a mailbox database copy configured with a replay lag time value greater than 0. Activating and recovering a lagged mailbox database copy is a simple process if you want the database to replay all log files and make the database copy current. If you want to replay log files up to a specific point in time, it’s a more difficult operation because you have to manually manipulate log files and run Eseutil.

Note:

You can’t use the Exchange Management Console (EMC) to activate a lagged mailbox database copy to a specific point in time.

1. Suspend replication for the lagged copy being activated by using the Suspend-MailboxDatabaseCopy cmdlet, as shown in this example.

Suspend-MailboxDatabaseCopy DB1\EX3 -SuspendComment "Activate lagged copy of DB1 on Server EX3" -Confirm:$false

2. Optionally (to preserve a lagged copy), take a file system-based (non-Exchange aware) Volume Shadow Copy Service (VSS) snapshot of the volumes containing the database copy and its log files. You can use the vssadmin.exe tool that’s included in Windows to take a VSS snapshot, as shown in this example.

   vssadmin create shadow /For=C:\mountpoints\db01
   vssadmin create shadow /For=C:\mountpoints\db01_logs

   Note:

   At this point, you have shadow copies outstanding for the database and log volumes. Continuing to perform this procedure on the existing volume would incur a copy on write performance penalty. If this isn’t desirable, you can copy the database and log files to another volume to perform the recovery.

3. Determine which log files are required to replay into the database to meet your point-in-time requirement for this recovery (based on log file date and time, as shown in Windows Explorer). All logs created after this point should be moved to a different directory, until the recovery process is completed, and the logs are no longer needed.
4. Delete the checkpoint (.chk) file for the database.
5. Use Eseutil to perform the recovery operation, as shown in this example.

   Eseutil.exe /r eXX /a

   Note:

   In the preceding example, eXX is the log generation prefix for the database (for example, E00, E01, E02, and so on).

   Important:

   This step may take a considerable amount of time, depending on several factors, such as the length of the replay lag time, the number of log files generated during that period, and the speed at which your hardware can replay those logs into the database being recovered.

6. After log replay is finished, the database is in a clean shutdown state and can be copied and used for recovery purposes.
7. After the recovery process is complete, resume replication for the database that was used as part of the recovery process, as shown in this example.

   Resume-MailboxDatabaseCopy DB1\EX3