[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 473
  • Last Modified:

DISASTER RECOVERY: SCR OR SCR WITH STANDBY CLUSTERING?

Microsoft recently helped me with a straight forward SCR solution for offsite replication of Exchange 2007, to be available and employed only in the event of a disaster in our office which disabled our production environment.  SCR is designed so that there is always 50 log lag meaning that in the best of situations I would always lose 50 megabytes of the last transcactions.  This is to ensure that corruption that might have occurred on the source database is not read into the target.

Microsoft has also published another solution that mixes SCR with standby clustering, that is more expensive in terms of Windows 2008 enterprise and Exchange 2007 licenses that I do not have as well as the time it will take to redo the current Exchange 2007 installation (on Windows 2008 standard, all servers on the same box, only two user accounts at the moment thankfully).  However, this solution obviates the 50 log lag and apparently can be deployed faster in an emergency.  I understand that mounting the mail databases in the straight-forward SCR scenario would take about an hour while in the mixes scenario abuout fifteen minutes.

The question is, if anybody has experience with these disaster recovery options, is the straight forward SCR solution adequate in an office where the 50 megabytes of lost transactional data would be spread over 165 users and the hour or so it took to get the target system operational was acceptable?
0
mwcollins31
Asked:
mwcollins31
1 Solution
 
Exchange_GeekCommented:
You cannot mount a database where the active node (SCR) is ahead than the passive node (SCR) than more than 6 (max setting done for AutoDatabaseMountDial setting)
Ref: http://technet.microsoft.com/en-us/library/bb124389.aspx

So you are not loosing any log file - the delay is only for replaying the log files into database to avoid reseed - read the following documentation.

"In addition to the administrator-configured delay of replay that is specified using the ReplayLagTime parameter, Exchange will also prevent a fixed number of log files from being replayed on an SCR target, regardless of the value for ReplayLagTime using the formula Maximum of ("value of ReplayLagTime" or "X log files") where X=50. This is an additional safeguard against the need to reseed a storage group in situations when an SCR source that is in a continuous replication environment (for example, LCR or CCR) experiences a lossy failover and is brought online using the Restore-StorageGroupCopy cmdlet. By delaying replay activity on the SCR targets, when a lossy failover for an SCR source occurs, the chance of needing to reseed the SCR copies will be minimized because the nature of the data loss on the SCR source puts the two copies closer together in time."

Ref: http://technet.microsoft.com/en-us/library/bb676502.aspx
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now