Applies to: Exchange Server 2013

Topic Last Modified: 2012-11-02

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 should see a log replay rate of two logs per second per database.

What do you need to know before you begin?

  • Estimated time to complete this task: 1 minute, plus the time it takes to duplicate the lagged copy, replay the necessary log files, and extract the data or mount the database for client activity.

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

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

  • For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard Shortcuts in the Exchange Admin Center.

Tip:
Having problems? Ask for help in the Exchange forums. Visit the forums at: Exchange Server, Exchange Online, or Exchange Online Protection.

What do you want to do?

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

Note:
You can't use the EAC to activate a lagged mailbox database copy to a specific point in time. Instead, you perform a series of steps using the Shell and the command line.
  1. This example suspends replication for the lagged copy being activated by using the Suspend-MailboxDatabaseCopy cmdlet.

    Copy Code 
    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.

    Copy Code 
    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. This example uses Eseutil to perform the recovery operation.

    Copy Code 
    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, this example resumes replication for the database that was used as part of the recovery process.

    Copy Code 
    Resume-MailboxDatabaseCopy DB1\EX3

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

Use the Shell to activate a lagged mailbox database copy by replaying all uncommitted log files

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

    1. This example suspends replication for the lagged copy being activated by using the Suspend-MailboxDatabaseCopy cmdlet.

      Copy Code 
      Suspend-MailboxDatabaseCopy DB1\EX3 -SuspendComment "Activate lagged copy of DB1 on Server EX3" -Confirm:$false
    2. You can use the vssadmin.exe tool that's included in Windows to take a VSS snapshot, as shown in this example.

      Copy Code 
      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.
  2. This example activates the lagged mailbox database copy using the Move-ActiveMailboxDatabase cmdlet with the SkipLagChecks parameter.

    Copy Code 
    Move-ActiveMailboxDatabase DB1 -ActivateOnServer EX3 -SkipLagChecks

Use the Shell to activate a lagged mailbox database copy by using SafetyNet recovery

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

    1. This example suspends replication for the lagged copy being activated by using the Suspend-MailboxDatabaseCopy cmdlet.

      Copy Code 
      Suspend-MailboxDatabaseCopy DB1\EX3 -SuspendComment "Activate lagged copy of DB1 on Server EX3" -Confirm:$false
    2. You can use the vssadmin.exe tool that's included in Windows to take a VSS snapshot, as shown in this example.

      Copy Code 
      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.
  2. Preserve and move off the log files for the copy being activated so that they aren't replayed when the databases is mounted.

  3. This example mounts the database using the Mount-Database cmdlet with the AcceptDataLoss parameter.

    Copy Code 
    Mount-Database DB1 -AcceptDataLoss
  4. At this point, the database will automatically mount and request redelivery of missing messages from SafetyNet.

How do you know this worked?

To verify that you've successfully activated a lagged mailbox database copy, do one of the following:

  • In the EAC, navigate to Servers > Databases. Select the appropriate database, and in the Details pane, click View details to view the database copy properties.

  • In the Shell, run the following command to display status information for a database copy.

    Copy Code 
    Get-MailboxDatabaseCopyStatus <DatabaseCopyName> | Format-List