Share via

Activate a Lagged Mailbox Database Copy

  • Article

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.

Looking for other management tasks related to mailbox database copies? Check out Managing Mailbox Database Copies.

Note

The amount of time it takes to activate a lagged mailbox database copy directly depends on how many log files need to be replayed and how fast the hardware can replay them. At a minimum, you can expect a log replay rate of two logs per second per database.

Prerequisites

  • The mailbox database copy being activated must be configured with a replay lag time greater than 0.
  • The mailbox database copy being activated must have all log files to the point in time to which you want to recover it. Keep in mind that database transactions can span multiple log files when determining the point in time to which you want to recover.

Use the Shell to activate a lagged mailbox database copy to a specific point in time

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Mailbox database copies" entry in the High Availability Permissions topic.

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

For detailed syntax and parameter information, see Suspend-MailboxDatabaseCopy or Resume-MailboxDatabaseCopy.