Hyper-V 2012R2 backing up with snapshots

[Yanish]

It appears that when backing up VM's on Hyper-V 2012R2 a checkpoint (formally snapshot) is taken, thus creating an avhdx file and merging after backup.
Is there a way to bypass this and return to native VSS like in 2008R2/2012?
As I am worried that heavy loaded VM's may be disrupted during the merge process like in VMware.

[nielsengelen]

Hyper-V uses another way of commiting snapshots compared to VMware and doesn't suffer the same effect.

[Gostev]

We don't use VM checkpoint functionality to preserve the backed up state for the duration of backup. Instead, we use what you call "native VSS". Hyper-V 2012 R2 is no different from 2012 or 2008R2 in that sense.

[Gostev]

The only difference with previous hypervisor versions is VSS provider used to create the in-guest VSS snapshot. For Hyper-V 2012 R2 VMs, Hyper-V Integration Services Shadow Copy Provider is used (instead of VSS software provider used for previous versions). Hyper-V Integration Services Shadow Copy Provider is a hardware provider that initiates VM snapshot (checkpoint) prior to Hyper-V VSS writer freeze. This autorecovery checkpoint does not exist for the entire backup (like in VMware), but rather only for the time required to create a volume snapshot.

Basically, it works this way:
- Volume snapshot is initiated
- Host VSS writer freeze (using guest VSS with Hyper-V Integration Services Shadow Copy Provider; VM checkpoint is created at the end of this process)
- Volume snapshot is created
- Host VSS writer unfreeze (VM checkpoint is merged)
- VM data is backed up from volume snapshot
- Volume snapshot is deleted

This method is actually better in terms of load it puts on VM and underlying storage, as checkpoint is committed almost immediately and using parent partition resources (not child partition, as in case of in-guest software VSS snapshot).

[foggy]

Also, I would like to note that some of the statements regarding backup of Hyper-V 2012 R2 VMs in your blog post are not completely valid and cause invalid conclusions.

The new process involves the use of checkpoints instaed of VSS to backup the VM (VHDX). Originally when backing up Hyper-V VM’s a VSS snapshot would be created, mounted, and that VSS snapshot would be backed up. similar to how we backup (or used to before we started backing up VM’s) Exchange, SQl AD…
The new way basically involves taking a checkpoint (formally known as a snapshot) of the VM, the checkpoint freezes the VHDX file and performs all new writes to a temporary AVHDx file. Thus while the checkpoint is active the original VHDX files can be backed up.
The one thing to take note of is that a checkpoint is crash consistent and not clean.

Not true, since both host and in-guest VSS are also used as previously. VM on the volume snapshot is always in its consistent state as volume snapshot is created after the VM freeze. While the mentioned checkpoint is indeed crash-consistent, it is not even touched by the backup process.

[Yanish]

Thanks for the clear up of this issue. I'll also my update my post accordingally.

[Yanish]

Foggy - Is your answer concerning Veeam or will all hyper-V backups work according to this?
Also if this is the case, what is the purpose of the actuall checkpoint?

[Gostev]

We cannot comment on other solutions, as they may work differently from Veeam. However, any solution that implements Microsoft recommendations on how Hyper-V backup should be performed will function in the same way as Veeam does.

Checkpoint is needed because different VMs on the volume will require different time to complete guest VSS freeze, however obviously you cannot have VMs just hanging with all I/O frozen and waiting for all other VMs on the volume to finish VSS processing before the volume snapshot can be created.

[Yanish]

OK, I have been backking up hyper-v since 2008R2 and never had this problem. Was it a known isue that all VM's would hang? or has this eased the VSS integration?

[Gostev]

Actually, both 2008R2 and 2012 work in the identical manner, but have more cumbersome and somewhat less reliable implementation for the same concept... moreover, the legacy approach does not support non-Windows OS. So, I really like the changes in Server 2012 R2.

Specifically, older Hyper-V versions use in-guest VSS snapshot for the same purpose. There is also the process of reverting to this in-guest snapshot in each VM right after the volume snapshot is created. To achieve that, the created volume snapshot is temporarily mounted to Hyper-V host with R/W access, and the in-guest VSS snapshot revert is initiated for each VM on the snapshot. Once this process ends, the volume snapshot will contain consistent VM states from slightly different points in time (whenever VSS freeze completed), which is exactly what you want to backup. All of this happens under the hood and transparently, so I concur it's not immediately obvious like the new implementation.

[samh22a]

with the newer approach in 2012 R2, is there still a lot of benefit of going with the hardware vss provider versur the software one ?

[Gostev]

Actually, this has nothing to deal with the volume snapshot functionality... no changes there, hardware VSS provider still has all the same benefits in 2012 R2.