none
Determine changes driving size of data for Hyper-V backup RRS feed

  • Question

  • I'm trying to determine what is driving the data size for the backups of my Hyper-V VM's.  I am protecting a 2012 R2 Hyper-V host and the VM's are a mix of 2008 R2 and 2012 R2 VM's.  The daily backups of the Hyper-V VM's send 3GB-4GB per VM every day.  Some of these machines are not doing much as they run a specific application that does not process much data.

    I've created a separate VHDX which houses the pagefile, system temp, software distribution, and shadow copies.  The VHD's are excluded from the Hyper-V backup using the registry keys documents here: http://social.technet.microsoft.com/wiki/contents/articles/23300.scdpm-2012-r2-troubleshooting-exception-virtual-disk-vhd-vhdx-of-vm-backup-hyper-v.aspx.  I have verified the excluded VHDX is NOT on the DPM server in the replica folder structure.

    My registry key for exclusions on the host looks like this: HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup\MyExclusions type MULTI_SZ with value "E:\Virtual Machines\ExcludedFromBackup\*.* /s".  All the VHDX's for the excluded volumes on the VM's are housed in this directory.

    I've used Resource Monitor to view real-time I/O.  I've also checked modified dates on files.  I can't find anything that is changing that much on the VM's. 

    Any suggestions on how to track down the driver for the relatively large incremental backup? 

    By the way, the reason I need to minimize the data transmission is that these VM hosts are remotely located on a WAN connection and there are several VM's on each host, generating about 75GB in incremental backups each day.


    Rob

    Monday, June 30, 2014 1:50 PM

All replies

  • You can try the the PowerShell Get-FileHash which is described here to get the changes: http://blogs.technet.com/b/heyscriptingguy/archive/2014/05/08/powertip-verify-if-file-changes-by-computing-hash.aspx

    Please remember, if a file is changed in VM, not only this File will be transferred, the whole Block of the VM will be transferred, so a changed 1KB File will be cause a lot more Data Transfer.

    Here you can find some Informations; http://flemmingriis.com/changes-in-hyper-v-backup-in-2012-r2/


    Seidl Michael | http://www.techguy.at | twitter.com/techguyat | facebook.com/techguyat

    Tuesday, July 1, 2014 6:57 PM
  • Are you proposing to do a hash on every file in the file system, store that, then redo the hash?  that will only tell me if the file changed...not necessarily indicate the size of the change.  What I'm trying to do is narrow down the drivers of the large block changes.

    FYI, the second link you sent has only to do with the way the underlying Hyper-V host houses the writes that occur while a shadow copy backup is underway.  it doesn't really address the size of changed files when the backup is not happening.

    Feel free to clarify if I'm missing something.


    Rob

    Tuesday, July 1, 2014 7:44 PM
  • Hi,

    There is more writing going on than you think under the covers, download diskmon.exe from http://technet.microsoft.com/en-us/sysinternals/bb896646 and run it using administrative privileges.  The sector offsets and size in sectors will be displayed.  Each sector = 512 bytes.

    To see what files the sectors are associated with you can run NFI.EXE.  NFI is part of the OEM tools available at http://support.microsoft.com/kb/253066/en-us

    Direct link:  http://download.microsoft.com/download/win2000srv/utility/3.0/nt45/en-us/oem3sr2.zip

    Run:  NFI C: Sector#

    Example:

    C:\\NFI>nfi c: 49655752
    NTFS File Sector Information Utility.
    Copyright (C) Microsoft Corporation 1999. All rights reserved.


    ***Logical sector 49655752 (0x2f5afc8) on drive C is in file number 44124.
    \Windows\ServiceProfiles\NetworkService\AppData\Local\PeerDistRepub\Store\0\1\1195.dat
        $STANDARD_INFORMATION (resident)
        $FILE_NAME (resident)
        $DATA (nonresident)
            logical sectors 49647640-49655831 (0x2f59018-0x2f5b017)

    Another option is to dump the USN journal file and see what files have been updated. NOTE: Not all volumes may have a usn journal.

    1) Download the DPM 2010 diagnostic and install it on the protected sever.

    http://www.microsoft.com/en-us/download/details.aspx?id=9462

    2) After it's installed from an administrative command prompt cd to: C:\Windows\MPSReports\DPM\bin

    3) Run dumpusn.exe X: -e -o C:\temp\usnlog.txt (Where X: is a volume drive letter)

    4) Open the file and see what it contains - then use find /I "string" usnlog.txt to search for just updates to see what files have been written to, it may surprise you.


    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, July 2, 2014 12:43 AM
    Moderator
  • Mike,

    The utility you mention is very helpful, thanks.  I think I found the issue, however, without using it.  We run an AV product (Bitdefender) and I was looking more closely how it does the updates.  I believe it is copying the previous entire threat database before creating a new patched version.  This could easily generate 2GB per day.

    I found it by finding a server that was similar and had only 200MB-500MB of backups per day.  it didn't have that AV product installed which put me onto it.

    As a test, I reinstalled the AV on my excluded drive.  I'll report back what I find.

    Otherwise I'll look for the USN journal, that could be helpful.


    Rob

    Wednesday, July 2, 2014 4:40 AM
  • Moving the anti-virus to the separate drive reduced the daily backup from 3GB to 650MB.  So I guess the answer is you really have to analyze every potential application to see what is driving the changed blocks. 


    Rob

    Thursday, July 3, 2014 12:17 PM