Protecting Exchange 2010 DAG (Single Site) Using Data Protection Manager 2010

The thing that a lagged copy will give you over a classic backup is that the log files are copied from the source server ASAP. With backups the copying of the data happens on a schedule. So with a backup there's a window of data where it could be possible that the data will most likely not get recovered.

Hi Ross,

Thanks! But look a the following case:

Customer has one active DB, one copy and one lagged copy. A user synchronizes PDA and for some reason the Calendar gets emtpy in the active DB (I've seen this at a customer) and also in the copy DB but not yet in the lagged copy. In this way, recovering the whole calendar seems easier from within a lagged copy than recovering all individual calendar items with single item recovery.

Martijn

Ah, I see. So, in short, DPM provides all the benefits that the lagged copy would do for me, except that I can keep my PIT backups longer than 14 days. I can still do a log replay to fill in the data from a PIT restore to present time without having that lagged copy. Would that be correct?

Constantino

DPM allows you to have longer point in time backups.  Lagged copies can only do a max of 14 days.  DPM also provides automated means to recover from the point in time backups, whereas with lagged copies you will have to take a non-Exchange aware snapshot, surface the snapshot, roll the logs into the exposed snapshot copy and place it in a recovery database.

Ross

One other question raised by one of my colleagues: what advantages does the lagged copy provide us vs DPM (and vice versa)? What can one do that the other cannot?

Ross - that's exactly the info I was looking for. Thank you! Up until now, we were looking at having both DPM and Lagged Copies in place, but this information is a game changer for us, in a good way. You may have saved us $30,000 in our proposed deployment!

So, some followup questions- what can we do proactively to monitor for database corruption? Would an eventlog entry pop up as soon as unrepairable corruption is detected in a DB? I'd hate to have corruption in a DB occur on a saturday night, and not discover it until monday morning, and the best I'd be able to do is recover from that saturday PIT. What options are there to repopulate the DB from that PIT if I'm not using lagged copies?

Hi Martijn,

No, if you need to recover data from the lagged copy, you will need to surface a version of it to a recovery database.  The easiest way to do that is to take a snapshot using vssadmin and expose the snapshot (that way you don't tamper with your real lagged copy).

However, I should point out that this type of recovery should only be needed to address recoving from logical corruption events or deleted mailboxes.  Single Item recovery is what you should use to recover deleted items or expose different versions of messages.

Ross

Hi Ross,

Is it possible to use a lagged copy database as a recovery database to read and merge mailbox data into an active copy? As far as I know this is only possible by means of:
* Using recovery database and restore from backup
* Using Single Item Recovery

Martijn

Also, I want to make one thing clear - nothing in our guidance or architecture requires you do deploy a lagged copy. Lagged copies are optional.

Ross

Hi Constantino,

Typically you need a backup to mitigate the following concerns:

1.  Hardware/Software/Datacenter failures
2.  Accidental/Malicious deletion of items
3.  Logical corruption events / deleted mailboxes

Exchange 2010 offers the following features to help address those concerns:

1.  Mailbox Resiliency (i.e. multiple database copies) helps mitigate Hardware/Software/Datacenter failures.
2.  Single Item Recovery mitigates the need to restore backups to recover deleted items.
3.  Point-in-time backups (like a lagged copy) can be used to mitigate the need to maintain backups for Logical corruption events / deleted mailbox recovery.

As for whether you need to have a solution to prevent logical corruption is something your business will need to decide as part of the risk mitigation planning process.  The things to keep in mind with trying to recover from a logical corruption:
- You don't know a logical corruption has occurred until you are notified by the user(s).
- You don't know when the logical corruption occurred (reliant upon end user testimony as to when they discovered the data corruption).
- You need to have a point-in-time backup that goes back to that time frame.
- You need to make a decision as to how you will handle the recovery.  Will you erase all new data to recover the data that was corrupted?

The answers to those questions will help drive whether you need to maintain a point-in-time backup for this scenario.  If you decide you do need a point-in-time backup, then you need to decide what technology will you use.  Will you use a lagged copy (replay lag max of 14 days) or a VSS backup solution like DPM.  You do not need both.

Ross