none
DPM large (6.4TB) sync transfers, why?

    Question

  • Can someone explain why DPM thinks it has to transfer 6.4TB of “changed” data for a Hyper-v host recovery point? From what I can tell, only a tiny fraction of that data is needed/used to create the recovery point. For more information, read on.

    I have two protected member servers, comparably configured, at two remote sites. The servers are running Windows Server 2012 R2 Standard (as Hyper-V Host) and are hosting Windows Server 2012 R2 Standard (guest w/dedup enabled). The only real difference between these sites are the size of the .vhdx files:

    Site A: has a protected member that has a 11TB DATA.vhdx file

    Site B: has a protected member that has a 16TB DATA.vhdx file

    These systems are being protected with DPM 2016 UR4 (v5.0.342.0). The guest is protected by an off-site DPM server connected via a 100 mbps WAN link. While the host is protected by an on-site DPM server utilizing a 1GB connection.

    DPM is supposed to query the NTFS Change Journal and transfer what has changed from the last sync job. This appears to be true for the off-site DPM server protecting the guest over the WAN connection, with both sites transferring a small number of GB every night and finishing the recovery point within an hour.

    However, when using the on-site DPM server to protect the volume that contains the .vhdx, it doesn’t appear to work correctly (read as, efficiently). As an example, Site A is doing data transfers of 650GB to 1.5TB every night and the situation is even worst for Site B. It is transferring 6.2TB to 6.4TB every night, taking 17hours to complete a single backup.

    Move over, it is clear that not all of the data being transferred is stored in the Protection Group’s Recovery point. I know this because, I have 31 recovery points with only 1.8TB (in total) of data being used by the on-site DPM server.

    Can anyone explain this behavior?

    UPDATE #1:

    Instead of protecting the volume that contains the .vhdx, I am now protecting via the Hyper-v method. There is no change in the behavior. My next move is to disable Dedup and Defrag process and monitor for a few days. 

    Site A Host transfers:

    Site B Host transfers:


    Wednesday, February 21, 2018 1:57 PM

All replies

  • Update #2:

    I have disabled Dedup and Defrag processes on the fileserver at both sites.

    I found a forum post titled "Data transferred during recovery point is always very large (Hyper-V)" - https://social.technet.microsoft.com/Forums/en-US/7b6b0c8a-d6d0-4981-8745-23de25841ab0/data-transferred-during-recovery-point-is-always-very-large-hyperv?forum=dpmhypervbackup

    I followed the advice given by Mike Jacquet, Microsoft Corp, and added the below Regkey to the guest VMs.
     
    HKLM\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore 
    REG_DWORD ScopeSnapshots 0x0 

    No changes in the daily transfers (holding steady at 1.1TB and 6.5TB, respectfully). The file server has some data churn, just not at those levels. Recovery point used for site A is 520GB for 11 snaps and Site B is using 851GB for 8 snaps. 

    What am I missing? Anyone?
    Wednesday, March 7, 2018 12:47 PM