Aidan Finn, IT Pro

In Microsoft endeavors to finally close the book on backup issues, the Hyper-V team is switching to file-based backup, and moving from the non-scalable VSS backup. Let’s face it – most hardware VSS Providers have been like a curse.

When you backup a VM in vNext, a “backup checkpoint” is created. This forks the VM’s configuration is forked and the virtual hard disk(s) is forked too using an AVHD. This is done for a short period of time. This allows changes to continue while the backup is being done. The virtual machine can be live exported as a backup.

After this operation a dateless Reference Point is created. The AHVD(s) is merged back into the parent VHD(s). This reference point notes the Resilient Change Tracking ID (per VHD), so we know what changes are made after the AVHD was created, and now we know what blocks must be backed up in a following incremental backup.

Some notes:

• Incremental and “synthetic full” backups can now follow the full backup and this is done using a Differential Export.
• A restore is basically a process of copying the VM files from backup media and importing the VM.

SAN-based backup is different. A LUN snapshot will retain the parent VHD and AVHD, and only the VM configuration is exported by Hyper-V. CDS, SMI-S or network providers be used to create the LUN backup. The LUN snapshot is removed and job done.

Hyper-V PM Taylor Brown talks about file-based backup in his session at TechEd Europe 2014.

Windows Server Hyper-V has had an … interesting … history when it comes to backup. It has been a take-it-personally mission of the Hyper-V team to stop backup being an issue for Hyper-V customers. Backup of CSV in Windows Server 2008 R2 was not fun. Things got better in WS2012, and again in Windows Server 2012 R2. And we might finally be getting there with the next release of Windows Server.

An important change to Hyper-V backup is to enable partners to keep up with the pace of change of Windows Server – we’ve seen some backup vendors take years to catch up with a new version, and this prevents mutual customers from keeping their hosts in step with Microsoft.

In order for a backup product to do incremental backups, it needs to do block based change tracking. Each vendor has to create one of these filter drivers that sits in the storage stack. This stuff is hard to do right, and it can cause stability and performance issues if not done correctly. And it also slows down the development/re-test/re-certify of BackupProduct2016 to keep up with the release of Windows Server 2016.

Some bad change tracking implementations, that you may know of, lived in memory as bitmaps. If the host had an un-planned outage then the next backup had to be a full backup. Or maybe if the VM live migrated to another host, that VM would have to do a full backup because the change tracking was no longer in the memory of the host.

Resilient Change Tracking is built-in backup change tracking of changed blocks within virtual hard disks. It is used for incremental backup, and it is the underlying engine for differential export. The change tracking bitmap lives in memory and on-disk. The on-disk bitmap is not as granular because it is the fallback from the much more detailed in-memory bitmap.

The goal now is that backup vendors should stop writing their own filter driver to implement change tracking. If they use the built-in resilient change tracking then they can focus more time on feature development testing/certification, and keep up with Microsoft’s frequent releases of Windows Server. And hopefully, Microsoft’s change tracking will undergo suitable levels of testing that will give all customers a universally stable and well-performing subsystem.

Hyper-V PM Taylor Brown talks about Change Tracking in his session at TechEd Europe 2014.