We've got 30 physical servers protected by DPM.

We are about migrate to a new 3PAR.

This means that existing servers (not the DPM-servers themselves of course) will have both their bootdisk as well as their data-disks copied to a new LUN, provisioned from the new storage.

Since DPM use change block tracking, Im guessing that a datamigration plan using robocopy will cause all the files to be treated as new, causing the recoverypoints to be maxed out beyond our resources.

Any ideas how we can copy files to new disks and keep the journ

Hi Ivarson,

I contact DPM team about this question. There is no specific step to do this job. Also they mentioned that maybe we can use software mirror to "duplicate" the operation system drive as a workaround. However it is not tested so you may try on a test machine before applying to your environment. Here is the reply:

There really is no clean solution here except possibly using Windows software mirroring and when you break the mirror, you keep the half located on the 3PAR. This would mean attaching the 3PAR lun to the system, convert both disks to Dynamic make sure DPM continues protection then make and break a Mirror.

Thank you Shaon.

I tried this at home on a simple storagespace with some usbdrives.

Im not sure what DPM is reading to determine whether the file/folder is modified,

but i can verify that as you say, convert, make'n break of a mirrored volume doesn't modify the output from "

fsutil usn readdata <filename>

", looking at the USN-field.

But if issuing

fsutil usn queryjournal <driveletter>

the property "Next Usn" increments when I "break" the mirroring.

The question remains, will an offline diskclone (from a bootable WinPE envionment) retain all journaling?

I know Windows keeps track on the disks after clone process within the registry at HKLM\System\MountedD

I took a server at work to test stuff a bit further, although our 3PAR isn't up til' tomorrow so was only able to provision LUNs from our existing storage.

Basically it seems pretty straight forward in terms of DPM (there's tons of considerations elsewhere with sanboot and all).

I did find the initial hint from the DPM-group pretty clever, I like that the migration is being done in such low-level and that you won't get any distruptions at all.

But converting all 30 servers disks from basic to dynamic as well as having a 2 TB drive with critical data in a "sync"-state... it sort of feels a bit more risky.

Consideration 1; The changejournal which DPM activates when protecting a volume will not retain the same USN when a file is simply copied (like robocopy) even if driveletters are 'swapped' so a full backup will be performed.

Solution: VSS-aware application such as DriveImage XML can do live copying without causing the changelog to update the sequence number for a file. It's awfully slow though. don't know if its the vss-lock or the specific application here that makes it slow.

An 'offline' disk-to-disk copy performed via WinPE is much faster (a free but proprietary backup/restore application) and will also retain the journal.

Only drawback is that we can't speed up migration by pre-copying everything before maintanence window and do a final mirroring (robocopy /MIR), 

Consideration 2: DPM binds its protected source to a protected member's volume GUID (not the driveletter). Cloning a disk/partition at the protected member will effectively result in Windows giving the new disk a unique volume guid, since a disk has a unique serialnumber, and this in turn will result in a unique hex checksum as seen in HKLM\system\mounteddevices.

After cloning, an error occurs in DPM during recoverypoint saying <volume guid> is missing at protected member

solution: The script 'migrate-datasource.ps1' which is located and shipped in the dpm-servers installdir takes care of this just fine.

 Any corrections, suggestions or whatnot input is welc