Sign in
 
Exchange Server TechCenter > Exchange Server Forums > High availability/Disaster Recovery > CCR lossy failover - how far back in time could data be lost for contacts, tasks, etc...
Ask a questionAsk a question
Search Forums:
 

AnswerCCR lossy failover - how far back in time could data be lost for contacts, tasks, etc...

  • Friday, November 06, 2009 12:50 PMgkriggs Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote
    When a CCR lossy failover occurs (for example, the active node loses power), how far back in time could changes be lost, for changes made to contacts, tasks, personal appointments (e.g. the stuff not backed up in the transport dumpster queue)?  Or, in other words, how often does the data get backed up from the active node to the passive node?  Would this depend upon some configuration settings?  Does it just wait for the transaction log to fill up before sending it over?  Or if the server has been idle for awhile, would it send a partially filled up transaction log to the passive server?

    Thanks,
    Greg
     

Answers

  • Friday, November 06, 2009 3:29 PMjader3rd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Sign In to Vote
    0
    Sign In to Vote
    It depends on your Automountdail setting. If it's set to lossless, you'll never lose anything (but you risk down time). GoodAvailability is 3 logs (3 MB) and BestAvailability is 6 logs (6 MB). The vast majority of the data in the logs will be system information type stuff or SMTP items. So while it's possible to lose a non SMTP item, it's high unlikely.
    • Proposed As Answer byJon-Alfred Smith Friday, November 06, 2009 8:16 PM
    • Unmarked As Answer bygkriggs Friday, November 13, 2009 10:26 PM
    • Marked As Answer bygkriggs Friday, November 13, 2009 10:28 PM
    • Marked As Answer bygkriggs Saturday, November 07, 2009 12:17 AM
    •  
     

All Replies

  • Friday, November 06, 2009 1:16 PMWill Shepherd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    1
    Sign In to Vote
    That really depends on your Storage Group Copy Status, as long as it's healthy then you shouldn't be more than 3 logs behind. http://technet.microsoft.com/en-us/library/bb124521.aspx

    Thanks

    Will
    Will Shepherd - MCSE/MCITP/MCTS (Windows 2008,Exchange 2007,OCS 2007)
     
  • Friday, November 06, 2009 3:29 PMjader3rd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Sign In to Vote
    0
    Sign In to Vote
    It depends on your Automountdail setting. If it's set to lossless, you'll never lose anything (but you risk down time). GoodAvailability is 3 logs (3 MB) and BestAvailability is 6 logs (6 MB). The vast majority of the data in the logs will be system information type stuff or SMTP items. So while it's possible to lose a non SMTP item, it's high unlikely.
    • Proposed As Answer byJon-Alfred Smith Friday, November 06, 2009 8:16 PM
    • Unmarked As Answer bygkriggs Friday, November 13, 2009 10:26 PM
    • Marked As Answer bygkriggs Friday, November 13, 2009 10:28 PM
    • Marked As Answer bygkriggs Saturday, November 07, 2009 12:17 AM
    •  
     
  • Friday, November 06, 2009 3:31 PMjader3rd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    1
    Sign In to Vote
    The log copier only sends over a transaction log once it's full. The active copy will flush a log if data has been written to it after fifteen minutes. So even on a quite database you won't risk losing something more than fifteen minutes old.
     
  • Friday, November 13, 2009 10:28 PMgkriggs Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    Hello thank for your replies.  However, I was wondering is there any microsoft documentation you can point me to that says it will flush the log on a quite database?  Also where can I find Microsoft doucmentation on the Automountdail setting?  A google search didn't turn up much.

    Thanks,
    Greg