Thursday, July 28, 2016

Exchange Lagged Database Copy-DAG

Microsoft introduced lagged copy concept in Exchange 2007, when we are configuring the Standby Continuous Replication (called SCR). In Exchange Server that will hold an additional copy of the Mailbox Database. This is not for High Availability solution but for the disaster recovery solution. A lagged copy is the copy of the mailbox database that has certain lag time, this copy is certain amount of time behind the production server. The log file are copied to the SCR server immediately, but they are replayed into the Mailbox Database only after a specific, configurable time. This is also called lag time.
As we all know in Exchange Server we can configure the Database Availability Group (DAG) and a Database Availability Group also hold a legged copy. In DAG the lagged time can be up to 14 days. In this scenario the log files are copied from the Active Database to the passive Database, but they are replayed into the Database only after 14 days, means we can say we need quite an amount of the disk space to accommodate 14 days of log files.

So a few things to keep in mind when doing this process – If you have lagged copies of your databases you might want to make sure they can’t ever be activated. Because that would be very bad as you would lose the lag. In my case I lag for 8 days on my lagged copies.  In the EMC, it will always show a Activation Preference even if you have blocked the activation so it’s always good to set this when adding a copy of your database.

Let’s take a look, how we can add new database to the DAG

Create a new Database in your DAG and mount the Database.

Add Mailbox Database Copy to add the copy to your other mailbox servers.

Set your lag copy up.  This is done via Powershell.

Block the activation so it can’t ever fail over to the lag copy unless you do it manually.

When the cmdlet is run with the “-ActivationOnly” parameter, the database copy cannot be activated unless you do it manually.  

NOTE: You can run this command for every database on a server (if you have a server dedicated to hosting your lagged copies for example) this is done like this:

To disable this set the -databasecopyautoactivationpolicy to “unrestricted”


1. Identify the lagged copy of the database 
Get-MailboxDatabaseCopyStatus DB5 | Where {$_.ReplayLagStatus.Enabled -eq $true} | ft -auto
2. Now suspend the lagged copy of the database
C:\>Suspend-MailboxDatabaseCopy DB5\MX1
3. Make sure the backup of the database and log file for lagged database copy, or     we can simply copy to another location in server itself.
4. Once you have safe copy of your database & logs delete the .chk file from           transaction log in original location.
5. Use ESEUtil for dirty shutdown eseutil /mh c:\Exchange\DB5.edb, it will   
    show you dirty shutdown status of the database.
6. Next step run the soft recovery eseutil /r e00 /a
7. Again check the database status with help of /mh command.
8. Now database can be copied to another location and used as a recovery 
    database for restore purpose.

The lagged database copy automatically can be resumed as well.

You can also activate a lagged mailbox database copy by using SafetyNet recovery-check here 

No comments:

Post a Comment