Written by W. Curtis Preston
Sunday, 07 August 2011 09:00
The title may surprise none of you, but it is actually the opposite of what I said 1.5 years ago in a blog post called Hyper-V ahead of VMware in the backup race.
Back then I was concerned that VMware did not have full VSS support. They have since rectified that. [Update: by "full VSS support," what I mean is that it can talk properly to all versions of VSS. Before, they did not support Windows 2008. Now they support all versions of Windows. There is still the problem that they only have one style of snapshot, so they aren't telling applications that they've been backed up, which means that the applications aren't truncating their logs.]
They also added changed block tracking (AKA "CBT") in vSphere, so it is possible to perform block-level incrementals on image-level backups. And since VMware is talking properly to VSS, the applications are doing what they are supposed to be doing before a backup as well.
Now it is Hyper-V that is behind. There is no API within Hyper-V that can present to you a map of changed blocks in order to back them up. You can perform an incremental backup of-course, but an incremental backup via the Hyper-V host is going to back up everything, as every .VDK file will have changed.
This changed blocked block tracking feature of VMware makes finding which blocks have changed must faster, and backing up just the blocks that have changed (vs the files that have changed) is the fastest way to do an incremental backup.
Just like with VMware, third parties have stepped in to fill the void. So far, I know of Veeam and Arkeia that are using their source deduplication capabilites to perform sub-file incremental backup of Hyper-V machines. I'm sure there are more as well -- and if any of them mention themselves in a comment, I'll update my post.