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.

Continue reading →

I’m in the process of trying to convert my church’s use of an onsite file and email server to a cloud file synchronization service and a hosted Exchange service.  I’ve chosen SugarSync, as that appears to have a little more flexibility than Dropbox, and Sherweb for the Exchange service, as that is what we’re currently using for Exchange at Truth in IT.

For file services, the idea would be to move any folder that a given person needs access to their local PC, synchronize that folder to SugarSync, then share that folder out to other people who would need access to it.  That user would then synchronize that folder to their PC and have local access to it as well.  Changes would automatically be synchronized to every computer accessing the same folder.  (This is the same way we use Dropbox at Truth in IT. We share one big folder, and it’s synchronized to all our Macbooks.)  In order for this to work at the church, I need each PC to have enough local storage space to hold the data that they need to access on a regular basis.  (They can get access to infrequently accessed files via the web.)  The good news is that most PCs today have way more storage than they need if they’re using a fileserver. 

I’ve started the SugarSync pilot with three of the office workers, and selected about 20GB of folders to synchronize.  They have a 1.5 Mb T-1, so it took about a little over 24 hours to upload that 20GB up to SugarSync, and another 24+ hours to sync it to each computer that needs to have access to it.

Besides doing away with the server (and the costs associated with maintaining it), different people have experienced different benefits.

• One staff member who does not have an Internet connection can work on his files on his laptop at home and have them automatically synchronized to SugarSync when he plugs into the church’s Wi-Fi
• One staff member who likes to work from home a lot can access all of her files at home just like she was at the church, and can stop using thumb drives to bring files back and forth, or waiting ages to download a file via the VPN
• Another staff member needs infrequent access to office files from the house, but doesn’t feel the need to sync any folders to his house.  He will instead download or upload any files he needs via the SugarSync website.

There you have it: different strokes for different folks.

Continue reading →