orphaned AVHDX Files after Hyper-V Guest Backup (Full/Inc)

[JuergenB]

I have two Hyper-V 2012 R2 Update 1 Host Server with several Hyper-V Guest (2012 R2, 2012, 2008).
I use BE 2014 SP2 and do regular full backups and daily incremental backups of guests.

Within the Virtual Hard Disks folder, a AVHDX File is created during the backup.
These differential VHDX Files are created during running backup jobs.

If i open the explorer at the Hyper-V Host i can see these files beeing created and merged after the the backup has finished.
If i query the state of the VM guest with get-vmsnapshot servername i receive this information

servername   servername  - Backup - (17.01.2015 - 09:20:33)     Recovery     01.01.1601 01:00:00

not all, but some machines are showing the state Recovery and all these machines have growing AVHDX files.

Some of these are backed up with a full backup only and some with incremental.
The machine above has only a full backup once a week.

Is this normal, that AVHDX files are remaining after a full backup or after a incremental backup?
I can´t find any information in the whitepapers or knowledbase how the backup deals with the backup.
Can someone explain how it is by design?

Thanks

Jürgen

[Colin_Weaver · Accepted solution]

Have you turned on the Microsoft Incremental method of backing up Hyper-V VMs (which I believe requires running Powershell scripts/commands) ?

I am not sure, but it is possible that this method does create extra files (which are needed for the next backup). As the basic description I have for this method is:

When a VM has MSFT Incremental Backup Support enabled.  A “checkpoint / snapshot” is created each time the VM is backed up.  Then when the next incremental backup runs, the only data that needs to be backed up is the data in the “checkpoint / snapshot”.  Then when the next incremental backup runs, another “checkpoint / snapshot” is created, and when that backup completes, the previous “checkpoint / snapshot” is merged into the parent “checkpoint / snapshot”.

The differences between MSFT and Symantec (BE Method) when it comes to Incremental backups of Hyper-V VMS are:

1. VMs with MSFT Incremental Backup Support enabled can’t be processed using DIFFERENTIAL backups.
2. VMs with MSFT Incremental Backup Support enabled can’t be backed up by more than one job.
3. VMs with MSFT Incremental Backup Support enabled will backup faster than VMs that don’t have it enabled.  However, the VM will perform somewhat slower as there is always a “checkpoint / snapshot” in effect.  How much slower the VM performs is dependent upon the VM.  VMs that have lots writes, will not notice much degradation, whereas VMs that are mainly reads, will notice some slow down.

[Colin_Weaver]

Extra info (how to enable/disable MSFT Incrementals)

http://www.symantec.com/docs/HOWTO102609

[JuergenB]

Thanks Colin,

i have some VM´s with MSFT Incrementals turned on, i need to check this.
Is there any Powershell to query the current state (inc on/off) VM´s.

Server_A has MSFT incrementals turned off shows in PS a SnapshotType

server_A server_A - Backup - (17.01.2015 - 09:20:33) Recovery     01.01.1601 01:00:00

And in the Hyper-V MAnager it shows a Backup Checkpoint.

Is this by design?

I have some Backups running at 4.8GB/s and some running at 2.3G/s on the same server.

[Colin_Weaver]

I am not aware of a powershell query - however it does not mean there is not one. If there is however the answer would need to come from Microsoft as the commands to enable and disable this function came from them and not anything our developers did.

Likewise the snapshot statuses are really a consequence of snapshot operations against Hyper-V during either standard BE VSS operations OR the MSFT Incremental operations and almost certainly are expected statuses.

As performance can be affected by so many things that dynamically change in a given environment it is difficult to state much about that, although if you are comparing MSFT Incremental Performance with a system that is using BE standard processes then this might be an explanation as we would expect a performance difference.