What is Local Continuous Replication in Exchange 2007

Local Continuous Replication

In previous version Exchange 2000/2003 single server database, let say database suddenly crashed or disk failed to read\write database. So here my database is no more in use due to some disaster and my solution would bring back my database by mode of replacement of disk and then restoring the database by mode of RSG. What will be my server availability and time consumption to restore my database it is comparatively high and SLA will effect and business ofcourse.

But in Exchange 2007 we have concept of LCR where you can mount your database as soon as possible with less time consumption. LCR is nothing but it will keep a copy of the database and log files in another location which is called as “Passive Storage Group” from the Active Storage Group”. For copying the database and log file it uses shipping technology which is nothing replicating the data from source to destination.

Background Process of LCR

Whenever you enable the LCR function, the database are first pass through seeding process, seeding is nothing but a process that creating starting point to copy the database file, then the database is copied to destination folder and then finally logs are shipped into it. Then it will write that information to the database. When you enable the LCR you will find this event id in the application log 2014, 2015 & 2016.

Prior with the release of Exchange 2007 Beta Version we need to do seeding manually for seeding we need manually enter this following command from the powershell

suspend storagegroupcopy -identity "first storage group' (temporarily stop LCR )

update-storagegroupcopy -identity "first storage group" (seeding done here)

resume-storagegroupcopy -identity "first storage group" (resume the LCR)

With the release of Beta2 by default seeding is done at the time of enabling LCR.

Monitoring the LCR

Msexchange replication under this

copygenerationnumber & replay queue length

copygenerationnumber : The number of log file which is currently replicated

Replayqueuelength : the number of log file which is still need to play and waiting in the queue

How you can recover the database through LCR Mode

Let say I have one database called as Mailbox Store stored under First Storage Group.

Open => EMC => Server Configuration => Mailboxes => First Storage Group => Enable LCR and then follow the wizard for selecting the folder.

Now the database is seeded then log files are shipped to target folder.

One fine day let say mailbox database.edb got corrupted.

Run this command Restore-Storagegroupcopy -identity "Third Storage Group" -ReplaceLocations:$true

The above command will check the path of LCR like database, logs and check point file it will redirect the path location in EMC to LCR folder.

Then you can mount the database (mount-database –identity “Third mailbox store”)

Once you mount the database then you need to re-enable the LCR because it will stop the LCR function but before that you need to clean up all the files if you are using any old LCR folder or create a new folder instead

Disadvantages of LCR

Even though it is very good pre-backup solution for database but still there is some disadvantages

1) We can't expect that the all the data can be potentially recovered because the log files will not be in synch as they are shipped.

2) If our active storage group fails then we need to manually switch to passive storage group but it is inexpensive solution.

3) It will be used for the storage group which has only one database per storage group

----------------------------------------------------------------------------------------