Issues mounting NDMP Backed Up Luns

A coworker of mine cracked the case on this one with a bit of help from NetApp, but I thought I'd share as it was a strange little issue.  First off, what is an NDMP backup?

NDMP stands for Network Data Management Protocol, and was actually pioneered by Network Appliance (NetApp) in association with Intelliguard.  The purpose was to backup various platforms and provide interoperability.  Fast forward back to our current predicament..  

The current predicament is that someone uses Veritas to backup and restore.  They want to be able to restore from this, and have it correctly mount such that a they can recover data in Exchange.  The problem is that the restored lun won't mount in Snapdrive or otherwise.  Initially NetApp merely told us that the lun had to be in the root of the share rather than in a folder.. no problem.  Veritas must restore to a folder, but we can move it after the fact to the root. 

We then try to mount the lun, but it doesn't work.  It instead tells us that it is already mounted. 

The trick that my compatriot discovered was that it requires you to change the name as well by doing the following via command line:

lun move /vol/Volume1/restore.lun /vol/Volume1/restorenew.lun

He was then able to mount the lun.  Go team.

DPM - Consistency Checking Versus SLAs

There can sometimes be issues with meeting SLAs while using DPM within tight constraints.  The problem is that while consistency checking is essential, it kills other scheduled synchornizations while it runs.

"Synchronization with consistency check, also referred to as “a consistency check,” is the process by which DPM checks for and corrects inconsistencies between a protected volume and its replica. As part of the synchronization process, a consistency check performs block-by-block verification to ensure that all the data on the replica is consistent with the protected data. This process is slower than incremental synchronization because all the data on the replica is compared rather than just applying the data changes to the replica."

-Microsoft

Example:

Lets say your SLA is something very low such as having the ability to restore to the last 30 minutes.  We set up a 30 minute synchronization in DPM, which in itself isn't bad (though it seems to be more commonly set around 3-4 hours).  The issue comes when the consistency check runs, which could take for example 1.5-2 hours.  This would result in at least 3 failed synchronizations, thus breaking the SLA.

The only methods I am aware of to somewhat work around this would be to modify the SLA, or manually schedule consistency checks.