Hyper-V 2012 Incremental Stalls On First VHDX

[LouisC]

Hey all!

I was curious if anyone else has gotten an incremental backup of a Hyper-V 2012 VM w/ BE 2012 SP2 to work?

Mine starts, backups up a file first in the "User?Data" folder which is about 3.37MB of data, and then when it hits its the first VHDX it stalls. This is repeatable every time. It just goes to 0MB/min and sits there.

BE Media Server

• Server 2008 R2 SP1
• BE 2012 SP2

Hyper-V

• Hyper-V Server 2012 (Core)
• Agent for Hyper-V Server installed (SP2 agent)
• 2 node cluster
• CSV storage

VM

• Server 2012
• Agent for Windows Sever installed (SP2 agent)
• VHDXs sit on a CSV
• No snapshots exist for VM

Job Information

• Full backup finished yesterday
• Incremental started today
• Destination storage is Deduplication Storage using Client-Side processing.
• GRT is enabled and was succesful with the full backup

Just curious what other people's results are far...

v/r,

Louis

[LouisC]

Odd.... 34 minutes into it, the data jumped to 68.3MB and its still on the first VHDX.

[LouisC]

Forgot to mention, the only other job running is a Verify job against a recently finished Duplicate to Tape job so it shouldn't be holding up any disk activity that I know of. The Verify job is humming along at 6,800MB/min.

[LouisC]

Interesting.... 40 some odd minutes later its at 147MB and finally on the second VHDX.

[LouisC]

Well, completed sucessfully, it just took 2 hours to complete including the verify job. Here's the relevant job log informatino:

Summary

Byte count          : 4,039,299,159 bytes
Job rate            : 32.00 MB/Min (Byte count of all backup sets divided by Elapsed time for all backup sets)

Scanned byte count  : 20,302,787,584 bytes
Stored byte count   : 7,356,766,208 bytes
Deduplication ratio : 2.8:1

Files               : 263,826
Directories         : 15,523
Skipped files       : 0
Corrupt files       : 0
Files in use        : 0

Original start time : Friday, August 02, 2013 11:00:00 PM
Job started         : Saturday, August 03, 2013 8:56:43 AM
Job ended           : Saturday, August 03, 2013 11:13:57 AM
Elapsed time        : 02:17:14

Backup

Byte count             : 4,039,299,159 bytes
Rate                   : 32.00 MB/Min

Files                  : 263,826
Directories            : 15,523
Skipped files          : 0
Corrupt files          : 0
Files in use           : 0

Start time             : Saturday, August 03, 2013 11:00:42 AM
End time               : Saturday, August 03, 2013 11:04:33 AM

Verify

Byte count             : 4,016,313,259 bytes
Rate                   : 566.00 MB/Min

Files                  : 6
Directories            : 3
Skipped files          : 0
Corrupt files          : 0
Files in use           : 0

Start time             : Saturday, August 03, 2013 11:07:01 AM
End time               : Saturday, August 03, 2013 11:13:47 AM

It seems a bit odd that the job started at 8:56AM but the backup portion says that it didn't actually started till 11:00AM and ended at 11:04AM even though I watched it attempt to backup VHDXs during the 8:56AM-11:00AM time frame.

Also,  what's interesting is the GRT portion for the VM. If I look at the backup sets for the VM, I have the full that contains the individual drive letters that the VM has and then for the incremental, I see a drive with a GUID and it contains all the files that have changed since the full, all lumped into one "drive".

Does this all look right?

v/r,

Louis

[LouisC]

This is the GRT backup set for the VM. All the drives with the date 8/1/203 are from the full backup. The drive with the GUID that is dated 8/1/2013 is the System Volume and I expect that one, its the drive below it with the GUID that is dated 8/3/2012. That's the incremental set that contains all the changes for all the drives.

[BackupBjoern]

LouisC

You should not see these guid's for the incremental backups. Is it possible to get view of a beremote.log from the node that controls this vm?

[Colin_Weaver]

Hi LouiseC

Have you logged a formal Support case for this problem? It looks like we may need to look into this more thoroughly and will need extra logs (including that asked for by BackupBjoern above.)