Summary:
In this article we will learn about gradual evolution of Hyper-v Backup in Windows Server Operating System
Applies to Windows Sever Operating System evolution
Hyper-V uses VSS to backup and restore VMs. If the Backup integration services are installed in the guest OS, a VSS requester is installed that will allow VSS writers in the guest OS to participate in the backup of the VM.
Hyper-V uses one of two mechanisms to back up each VM:
1. Saved State: It is the default backup mechanism.
- VM is put into a saved state during the processing of the PrepareForSnapshot event,
- Snapshots are taken of the appropriate volumes,
- VM is returned to the previous state during the processing of the PostSnapshot event.
2. Child VM Snapshot:
This method 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).
The following procedure describes how to back up VMs:
1. 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
- All VSS events in the child VM occur during the host operating system processing of the PrepareForSnapshot event.
2. 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.
3. 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.
4. 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.
5. 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
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.
Hyper-V Backup doesn’t interrupt running virtual machines (anymore)
Hyper-V Backup doesn’t interrupt running virtual machines (anymore)Hyper-V has always provided the ability to backup all your virtual machines from the host operating system. In order to provide a consistent backup of the virtual machine – Hyper-V has traditionally employed two approach
1. If the guest operating system has the Hyper-V backup integration service installed and running: use VSS (for Windows) or file system freeze (for Linux) to create a data consistent backup of the running virtual machine.
2. If the guest operating system does not have the Hyper-V backup integration service installed or running: put the virtual machine into a saved state, and perform a backup of the saved virtual machine.
Disadvantage of VM putting into Saved state for backup:
- It takes a running virtual machine offline for the backup process
The good news is that this second approach has been drastically improved in Windows Server 2012 R2:
Now, rather putting the virtual machine into a saved state, we take a checkpoint of the virtual machine. This checkpoint is backed up, and deleted after the operation is complete.
The net result of this is that no matter what the guest operating system, and no matter what the state of the integration services inside the guest operating system, Hyper-V will never interrupt a running virtual machine as part of backing it up (anymore).
Improvements in Hyper-V Backup 2012 R2
Hyper-V has always provided the ability to backup all running virtual machines from the host operating system, without incurring any downtime for the virtual machines being backed up. To do this it utilizes the fantastic VSS (Volume Shadow Copy Services) functionality in Windows.
When a user wants to backup a Hyper-V server, the following process is followed for Windows Server 2008, 2008 R2 and 2012:
1. The backup application requests that Hyper-V backup all virtual machines
2. Hyper-V goes through each virtual machine and sends a request to the Hyper-V Backup integration service inside of the virtual machine
3. The Hyper-V Backup integration service inside of the virtual machine then asks the guest instance of VSS to create a data-consistent VSS snapshot inside of the virtual machine
4. Once all the virtual machines have confirmed that they have taken a VSS snapshot, Hyper-V tells the host instance of VSS that it can take a host VSS snapshot
5. Now, at this stage – some time has elapsed between steps 3 and 4. This means that the virtual machines were continuing to write data to their virtual hard disks, and that the virtual hard disks host VSS snapshot are not actually data consistent.
To handle this, Hyper-V then:
- Locates the copies of the virtual hard disks that are stored in the newly created host side VSS snapshot
- Mounts each of these virtual hard disks in the host environment
- Uses VSS to revert each virtual hard disks state to the VSS snapshot that was taken in step 3
- Dismounts each virtual hard disk
- Informs VSS that it is complete – and that it can return the files in the host VSS snapshot to the backup application
Disadvantage: It involves mounting a copy of every virtual hard disk on the system in the host environment.
Example: For a computer with 100 virtual machines – each with 2 virtual hard disks – that means 200 virtual hard disks are mounted and dismounted every time a backup is taken.
This will cause: Large registry files in the parent partition – that would slow down system boot over time.
To make the system more reliable, especially at scale, we have made a change to this process. In Windows 2012 R2 backing up Hyper-V now follows this process:
1. The backup application requests that Hyper-V backup all virtual machines
2. Hyper-V goes through each virtual machine and sends a request to the Hyper-V Backup integration service inside of the virtual machine
3. The Hyper-V Backup integration service inside of the virtual machine then asks the guest instance of VSS to create a data-consistent VSS snapshot inside of the virtual machine
4. Once all the virtual machines have confirmed that they have taken a VSS snapshot, Hyper-V tells the host instance of VSS that it can take a host VSS snapshot
5. Now, at this stage – some time has elapsed between steps 3 and 4. This means that the virtual machines were continuing to write data to their virtual hard disks, and that the virtual hard disks host VSS snapshot are not actually data consistent.
To handle this, Hyper-V then:
- Locates the copies of the virtual hard disks that are stored in the newly created host side VSS snapshot
- Connects each virtual hard disk copy to the still running virtual machine that it was copied from
- Sends a message to the Hyper-V Backup integration service inside the virtual machine that instructs it to revert the virtual hard disk copy to the VSS snapshot that was taken in step 3
- Disconnects each virtual hard disk
- Informs VSS that it is complete – and that it can return the files in the host VSS snapshot to the backup application
Here is action of reverting the virtual hard disk to the data consistent VSS snapshot now takes place inside the VM instead of in the host OS
Minor Drawback:
- In order for this method to work, we need to be able to hot add and remove virtual hard disks to and from the virtual machine. And It’s only supported on SCSI controller (not our IDE controller).
