In this case, Windows Server 2008 R2 was P2V (physical to virtual) converted, and hosted on Windows Server 2012 Hyper V cluster. This VM was having several vhds attached, and latest integration services available from Hyper V cluster were successfully installed and running.VMs running on this Hyper V cluster were backed up from Hyper V hosts. During the backup schedule this "new" VM, was the only one that was going into saved state during the backup, and services hosted on this VM were unavailable for several minutes. Backup of the VMs is VSS based, and there were no VSS errors.
In this situation, I've checked the backup solution documentation and found that this behavior of saving the state of the VMs is under jurisdiction of Hyper V, and not under control of the backup software.
So, I've started digging the Hyper V logs and found something interesting: during the backup cycles there was warning event 4098 logged into Hyper V Integration event log:
This event was logged for the VM that was going into saved state during backup. So, I've checked the VM's scheduled volume shadow copies, and found that shadow copies for volumes were stored on separated disk only for storing shadow copies.
After changing the scheduled volume shadow copies to be stored on same disk as data, the VM was successfully live backed up from the Hyper V host without saving state and without losing the VM's offered services during the backup.
In this situation, I've checked the backup solution documentation and found that this behavior of saving the state of the VMs is under jurisdiction of Hyper V, and not under control of the backup software.
So, I've started digging the Hyper V logs and found something interesting: during the backup cycles there was warning event 4098 logged into Hyper V Integration event log:
This event was logged for the VM that was going into saved state during backup. So, I've checked the VM's scheduled volume shadow copies, and found that shadow copies for volumes were stored on separated disk only for storing shadow copies.
After changing the scheduled volume shadow copies to be stored on same disk as data, the VM was successfully live backed up from the Hyper V host without saving state and without losing the VM's offered services during the backup.
