To Lag or Not to Lag?


  • From Technet

    "How will you detect and prevent logical corruption in an active database copy from replicating to the passive copies of the database? What is your recovery plan for this situation? How frequently has this scenario occurred in the past? If logical corruption occurs frequently in your organization, we recommend that you factor that scenario into your design by using one or more lagged copies, with a sufficient replay lag window to allow you to detect and act on logical corruption when it occurs, but before that corruption is replicated to other database copies."   

    In all of my years i have never once restored a db from backup due to logical corruption, but this very question came up in a Sales meeting yesterday.  "How do we mitigate logical database corruption?"  We are currently running with three copies and using Exchange Native Protection, but now I'm starting to question our decision, and to add a 4th lagged copy would require an extensive amount of rework and additional hardware.

    So the question:

    Has anyone running a large 2010 installation experienced a a corruption issue that was replicated to all copies of the db?

    2012年3月8日 16:32


  • I'm not a huge fan of lags for a few reasons;

    1. How do you know when you have a logical corruption? Someone tells you something isn't right. Problem is...;
    2. When did it happen? If you don't know, how can the lag be used to restore to the right time?
    3. There are tools for detecting and repairing anyway; Calendar repair assistant, Single item recovery, mailbox move, mailboxrepairrequest etc. So use those instead.

    So I think it's a rare situation, and likely one you can't even detect in time anyway. I'd rather you used more HA copies and understood all the other ways you can fix/repair mailboxes.

    2012年3月10日 2:59