Your network contains a server named Server1 that runs Windows Server 2012.
Server1 has the Hyper-V server role installed.
Server1 hosts four virtual machines named VM1, VM2,VM3, and VM4.
Server1 is configured as shown in the following table.
You plan to schedule a complete backup of Server1 by using Windows Server Backup.
You need to ensure that the state of VM1 is saved before the backup starts.
What should you configure?
A.
NUMA topology
B.
Resource control
C.
Resource metering
D.
Virtual Machine Chimney
E.
The VLAN ID
F.
Processor Compatibility
G.
The startup order
H.
Automatic Start Action
I.
Integration Services
J.
Port mirroring
K.
Single-root I/O visualization
Explanation:
http://www.altaro.com/hyper-v/vss-crash-consistent-vs-application-consistent-vss-backups-post-2-of-2/
Backup Operations in Hyper-V
No VSS Writer Available?
In some cases, you need an application-consistent backup but there is no VSS writer available. One example of
this is MySQL. Hyper-V backups of virtual machines containing MySQL will always result in either a crash-consistent or an image-level backup. For MySQL, thelatter is probably acceptable as MySQL doesnt
perpetually expand the log file. However, if youreusing MySQL within a VSS-aware VM, then a Hyper-V-based
backup tool is going to take a crash-consistent backup. MySQL (like any other database system) isnt always
recoverable from a crash-consistent backup; even when recovery is possible, it may be painful. MySQL is just
one example; any number of line-of-business applications could tell a similar tale. In the case of MySQL, one
solution is to find a guest-level backup application that is MySQL-aware and can back it up properly. For
applications for which no backup application has a plug-in, you may need to have pre- and post-backup scripts
that stop services or close applications. If brief downtime is acceptable, you can disable the Backup item
in Hyper-V Integration Services, thereby forcing Hyper-V to save the state of the VM during backup.
This technique results in an image-level backup andcan be used on any application that doesnt have aVSS
writer.
Backing Up the Virtual Machines
Hyper-V uses one of two mechanisms to back up each VM. The default backup mechanism is called the “Saved State” method, where the VM is put into a saved state during the processing of the PrepareForSnapshot event, snapshots are taken of the appropriate volumes, and the VM is returned to the previous state during the processing of the PostSnapshot event.
The other backup mechanism is called the “Child VM Snapshot” method, which uses VSS inside the child VM to participate in the backup. For the “Child VM Snapshot” method to be supported, all of the following conditions must be met:
Backup (volume snapshot) (!)Integration Service(!) is installed and running in the child VM. The service name is “Hyper-V Volume Shadow Copy Requestor”.
Windows 2000: Backup Integration Service is not supported.
The child VM must be in the running state.
The Snapshot File Location for the VM is set to be the same volume in the host operating system as the VHD files for the VM.
All volumes in the child VM are basic disks and there are no dynamic disks.
All disks in the child VM must use a file system that supports snapshots (for example, NTFS).
In general, the process for backing up VMs is the same as described in Overview of Processing a Backup Under VSS. The unique behavior happens when the Hyper-V VSS writer (part of the “Hyper-V Virtual Machine Management” service) processes the PrepareForSnapshot event. If the backup was done using the “Child VM Snapshot” method, there is additional processing done but it is not visible to the child VM.
The following procedure describes how to back up VMs.
Dd405549.wedge(en-us,VS.85).gifTo back up virtual machines
For each VM in the writer metadata, if the “Saved State” method is used, the VM is put into a saved state. For VMs using the “Child VM Snapshot” method, the Hyper-V Volume Shadow Copy Requestor Service in the child VM processes the backup as detailed in Overview of Processing a Backup Under VSS. All VSS events in the child VM occur during the host operating system processing of the PrepareForSnapshot event.
After all VMs have either been put in the saved state or had snapshots taken, the Hyper-V VSS writer returns from the PrepareForSnapshot event. No processing is done by the Hyper-V VSS writer during the Freeze and Thaw events.
When the Hyper-V VSS writer processes the PostSnapshot event, VMs that were backed up using the “Saved State” method and were put into a saved state by the Hyper-V VSS writer are returned to the state they were in before the backup started. For the VMs that were backed up using the “Child VM Snapshot” method, the host image of the VHD files that had the snapshots taken are rolled back to the snapshot taken during the processing of the PrepareForSnapshot event. This processing is done independently of the VSS writers in the child VMs so the snapshots taken must be auto-recoverable. (VSS_VOLSNAP_ATTR_NO_AUTORECOVERY is not set in the context.)
Partial backups are not supported. If any VM fails to create a snapshot, no VMs will be backed up.
Note Pass-through and iSCSI disks are not visible to the host operating system and therefore not backed up by the Hyper-V VSS writer. Backups of these volumes must be done entirely within the VM.
Also look at:
http://blogs.msdn.com/b/taylorb/archive/2008/08/20/backing-up-hyper-v-virtual-machines-using-windows-server-backup.aspx
You can perform an online backup with no downtime on a running virtual machine when all of the following conditions are met:
Integration services are installed and the backup integration service has not been disabled.
All disks being used by the virtual machine are configured within the guest operating system as NTFS-formatted basic disks. Virtual machines that use storage on which the physical partitions have been formatted as dynamic disks or the FAT32 file system prevent an online backup from being performed. This is not the same as dynamically expanding virtual hard disks, which are fully supported by backup and restore operations.
Volume Shadow Copy Service must be enabled on all volumes used by the virtual machine with a specific configuration. Each volume must also serve as the storage location for shadow copies of the volume. For example, the shadow copy storage for volume C: must be located on C:.
If an online backup cannot be performed, then an offline backup is taken. This type of backup results in some degree of downtime. A variety of factors can affect the time required to take an offline backup. If the virtual machine is running or paused, it is put into a saved state as part of the offline backup process. After the backup is completed, the virtual machine is returned to its existing state.
Thats good information.
Thanks B-Art