none
DPM and CSV backup (Change block tracking or ntfs change journal) RRS feed

  • Question

  • Hi,

    i've been looking into DPM2010 and DPM2012. Does DPM utilize ntfs change journal or Change block tracking on and incremental backups.
    Somehow I think it doesn't. I keep seeying the CSV go into redirected mode and seeying the whoel vhd file being read.

    Is there a backup solution that's smarter with this?

    Wouter

    Wednesday, February 22, 2012 11:58 AM

All replies

  • Hi,

    DPM cannot use the DPMFilter to track block level changes on CSV volumes because the Cluster filter does not expose the changed blocks to our filter.   This is why DPM needs to do a block by block comparison of the VHD files and only bring over changed blocks.   In DPM 2012, we do utilize the DPM filter on non-csv volumes, so basically for standalone hyper-V servers DPM 2012 can do true block level backups.  


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, February 22, 2012 6:40 PM
    Moderator
  • Hi Mike

    As you have mentioned DPM 2012 can utilise the DPM filter for non CSV volumes but not for CSV Volumes as the CSV Filter is not exposed.

    With Server 2012 and DPM 2012 SP1 does this change? That is - is changed block tracking implemented for CSV's therefore making backups of child partitions viable?

    Thanks

    John.

    Monday, December 17, 2012 10:41 AM
  • Hi,

    Yes DPM 2012 SP1 will now perform true express fill backup using block level change detection for Windows Server 2012 Hyper-V clustered guests on CSV.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.


    Monday, December 17, 2012 3:55 PM
    Moderator
  • Hi,

    does the block level change detection work, if inside the VM DEDUP is activated?
    As it does work for all our VM's, but not the one that holds our storage of about 1,5 TB. 

    In 99 % of all cases, it transfers all data again, just sometimes it does it correct and only transfers about 40 GB, which sounds more reasonable. 

    First I thought, the storage is new, DEDUP will have a lot of changes, that causes this, but now after 2 months, it's still the same, so backups take serveral hours, instead of just a short time, as the storage doesn't change that much at all. 

    So I am wondering, as there are no errors whatsoever, just that I see backups take unreasonable long for small changes of a big VHDX. And the odd thing is, all other VM's, including a Linux one, works correct. I read, DEDUP is no problem with DPM, but seems it could be with changed blocks, while I doubt, that 1,5 TB of blocks are changed daily... 

    It is a Windows 2012 Cluster with DPM 2012 SP1, all patches applied. 

    Thanks
    Patrick 

    Friday, June 28, 2013 10:27 PM
  • Hi Patrick,

    The DPMFilter runs on the host and has no knowledge of workloads inside the guest.

    Here are two thoughts and things to try.

    1) It was also reported that some Windows 2012 server guests transfer the whole VM during backups instead on block level changes. 

    Implement this registry key on the effected VM to see if it resolves the issue.  You must add a key called SystemRestore, then add a value called ScopeSnapshots as follows.

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore
    REG_DWORD ScopeSnapshots 0x0

    2)  It could be that windows 2012 dedupe does some scavenging or maintenance work that touches / changes a lot of deduped data blocks that would be tracked by the DPMFilter.

    Try temporarily disabling dedupe for that volume so no more dedupe is performed, then try doing two manual back to back recovery points and see if the amount transferred is more in tune with actual data churn.   Do that a few times during the day and see if that makes a difference.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Saturday, June 29, 2013 3:16 PM
    Moderator
  • Hi,

    thanks for your quick answer, I will first try 1). 
    Just to be sure, 0x0 should be the value, or the default value 0x00000000 used?

    As once I use 0x0, it will show the value to 0x000000410 (1040)

    Thanks
    Patrick

    Saturday, June 29, 2013 5:48 PM
  • Hi,

    No, 0x0 hex = 0 decimal - so basically just make the DWORD (32-bit) value called ScopeSnapshots and that is all.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Saturday, June 29, 2013 5:54 PM
    Moderator
  • Hi,

    I tried the first suggestion, but it didn't work. 

    But what I figured out was, when I do a snapshot, the daily backup size is about 40-70 GB. 
    If there are "no" snapshots, it backups all data, about 1,6TB. 

    Somehow I don't believe that DEDUP is the reason, could it be?

    Thanks
    Patrick

    Sunday, July 7, 2013 11:26 PM
  • Hi Patrick,

    Did you solve your problem?

    Monday, June 1, 2015 10:34 AM
  • Hi,

    we don't use CSV anymore, so sorry, can't help here. 

    Patrick

    • Proposed as answer by bottkars Tuesday, October 27, 2015 8:07 AM
    Monday, June 1, 2015 11:09 AM