Backup workflow for SnapManager for HYPER-V

SMHV

Windows 2008 R2 HYPER-V

SMHV [SnapManager for HYPER-V] leverages NetApp Data ONTAP Snapshot technology to

create fast and space-efficient backups of SMHV datasets and their associated VMs. These backups offer point-in-time images, or copies, of the VMs and are stored locally on the same storage platform on which the VMs physically reside. In addition to the Snapshot copy stored locally, SMHV also provides an option to update an existing SnapMirror relationship upon the completion of a backup. This document focuses only on the 'Backup workflow'. If you need information on SMHV Install/Admin Guide or Best Practices Guide, please refer to the links provided at the end of this document; else go to netapp support site or simply google. What is workflow - Workflow is sometimes described as a series of tasks that produce an outcome. In the context of NetApp SMHV, this document defines workflow as a sequence of actions or tasks that work together to accomplish successful backup job.

ashwinwriter@gmail.com April, 2014

There are two basic methods you can use to perform a backup. You can:

Perform a backup from the server running Hyper-V: This is the recommend method to perform a full server backup because it captures more data than the other method. If the backup application is compatible with Hyper-V and the Hyper-V VSS writer, you can perform a full server backup that helps protect all of the data required to fully restore the server, except the virtual networks. The data included in such a backup includes the configuration of virtual machines, snapshots associated with the virtual machines, and virtual hard disks used by the virtual machines. As a result, using this method can make it easier to recover the server if you need to, because you do not have to recreate virtual machines or reinstall Hyper-V. However, virtual networks are not included in a full server backup. You will need to reconfigure the virtual networking by recreating the virtual networks and then reattaching the virtual network adapters in each virtual machine to the appropriate virtual network. As part of your backup planning, make sure you document the configuration and all relevant settings of your virtual network if you want to be able to recreate it.

Perform a backup from within the guest operating system of a virtual machine:

Use this method when you need to back up data from storage that is not supported by the Hyper-V VSS writer. When you use this method, you run a backup application from the guest operating system of the virtual machine [with backup agent inside the VM]. If you need to use this method, you should use it in addition to a full server backup and not as an alternative to a full server backup. Perform a backup from within the guest operating system before you perform a full backup of the server running Hyper-V. For more information about storage considerations, see the following section.

This document covers workflow for SMHV in three levels:

High level workflow

Low level workflow

RAW workflow

high level Backup workflow for SMHV WINDOWS 2008 R2 HYPER-V

1. The NetApp SMHV service [VSS requestor] on the HYPER-V host in coordination with the Microsoft Hyper-V VSS starts a backup.

2. The NetApp SMHV service on the Hyper-V host sends a request to the HYPER-V VSS on the host OS to freeze the guest OS.

3. HYPER-V VSS on the host OS sends a request to the Hyper-V writer to freeze the guest OS.

4. The Hyper-V writer passes the freeze request to VSS on the guest OS through the

Hyper-V 'BIS' [Backup Integration Services].

HANDY TIP: Like Backup Softwares [SMHV, Veeam, Altaro, Symantec etc] are called Volume Shadow Copy 'Requestor' on the HYPER-V Host [called Parent Partition], similarly the backup integration service IC is considered Volume Shadow Copy ‘Requestor’ inside the guest operating system [called Child Partition].

5. VSS on the guest OS sends a request to the VSS application writer to freeze the application.

6. The VSS application writer freezes the application and flushes data from the guest OS

memory.

7. HYPER-V VSS on the host OS sends a request to the NetApp VSS Hardware Provider to

create a snapshot.

8. The NetApp storage system creates a snapshot.

9. At the completion of the local backup, SMHV updates an existing SnapMirror relationship on the volume if the SnapMirror option was selected.

Low level Backup workflow for SMHV WINDOWS 2008 R2 HYPER-V

Customized flowchart Steps numbered in the flowchart are explained in the next page.

Note: The complete workflow shown above does not exist in NetApp SMHV documentation, though part of it does exist. I have put together this workflow with the help of flow chart and documentation from other backup vendors [specifically – courtesy: ‘Veeam.com’]. I am hoping it’s correct and in line with what happens in background during auto-recovery. [As all backup vendors (requestors) for HYPER-V environment implements standard Microsoft VSS framework to perform HYPER-V backups]

Low level Backup workflow in steps

1. SMHV interacts with the Hyper-V host VSS Service and requests backup of specific VMs. 2. The VSS Writer on the Hyper-V host passes the request to the Hyper-V Integration Components (HV-IC) installed inside the VM guest OS. 3. The HV-IC, in its turn, acts as a VSS Requestor for the VSS framework inside the VM — it communicates with the VSS framework installed in the VM guest OS and requests backup of VSS-aware applications running inside this VM. 4. The VSS Writers within the VSS-aware applications inside the guest OS are instructed to get the application data to a state suitable for backup. 5. After the applications are quiesced, the VSS inside the VM takes an internal snapshot within the VM using a VSS software provider in the VM guest OS. 6. After the internal snapshot is taken, the VM returns from the read-only state to the read-write state and operations inside the VM are resumed. The created snapshot is passed to the HV-IC. 7. The HV-IC notifies the hypervisor that the VM is ready for backup. 8. The Hyper-V host VSS Hardware provider takes a snapshot of a volume on which the VM is located (external snapshot). To make sure the VM data is consistent at the moment of backup, Hyper-V VSS Writer performs additional processing inside the created external snapshot – this process is also known as auto-recovery.

a. SnapDrive takes the first snapshot of the LUN where the VM resides.

b. It mounts the LUN inside the snapshot to add AUTORECOVERY information (mounts as CLONE).

c. The original LUN is renamed as exclude_{GUID}, and the CLONE is renamed as the

original LUN.

d. SnapDrive then takes the second snapshot of the CLONE LUN, and the clone is destroyed. The LUN is renamed to its original name from exclude_{GUID}.

9.Upon completion of the local backup, SMHV updates an existing SnapMirror relationship on the volume if the SnapMirror option was selected

RAW workflow

[As recorded on the HYPER-V Host – In Windows Application Event log]

1. SnapManager for Hyper-V backup is now started

Dataset Name = Virtual-Machines

Backup id = 6ad83514-21a0-4a99-a774-8bf6e38c281e

Backup Type = Application consistent

2. ONTAP VSS hardware provider service has started. [Note: The Data ONTAP VSS Hardware Provider ships as part of and is installed with NetApp SnapDrive for Windows, which is licensed per storage controller, or per physical Windows Server.]

3. Data ONTAP VSS hardware provider is loaded.

4. Data ONTAP VSS hardware provider is adding a source lun [VendorId=NETAPP,

ProductId=LUN, SerialNo=dnlPWZfVCoVK] to SnapshotSetId {4d6e1978-1b45-4176-81d6-94ee3d4a5be4}.

5. SnapDrive is ready to create Snapshot copy ({4d6e1978-1b45-4176-81d6-

94ee3d4a5be4}) of LUN(s).

6. Snapshot ({4d6e1978-1b45-4176-81d6-94ee3d4a5be4}) of LUN(s) on storage system (Filer05) volume (vol_clvsh01_csv03|) was successfully created. [As per step 8a in the Low level workflow]

7. Data ONTAP VSS hardware provider has successfully completed CommitSnapshots for

SnapshotSetId {4d6e1978-1b45-4176-81d6-94ee3d4a5be4} in 203 milliseconds.

8. GetTargetLunInfo succeeded.

Storage System Name = Filer05

lunPath = /vol/vol_clvsh01_csv03/clvsh01_csv03.lun

Snapshot copy Name = {4d6e1978-1b45-4176-81d6-94ee3d4a5be4}

9. CreateTargetLun succeeded.

Storage System Name = Filer05

lunPath = /vol/vol_clvsh01_csv03/clvsh01_csv03.lun

Snapshot copy Name = {4d6e1978-1b45-4176-81d6-94ee3d4a5be4}

10. Data ONTAP VSS hardware provider has successfully mapped a lun [VendorId=NETAPP, ProductId=LUN, SerialNo=7S-zp$Bb5jSb].

11. Revert operation for volume \\?\Volume{2cd0fffa-f006-11e0-a76b-002655db9b10}\ has

begun. Volume is being reverted to the shadow copy with id {927d2780-ce23-4990-90ac-3df404041dbc}.

Operation:

Revert a Shadow Copy

Context:

Execution Context: Coordinator

12. SnapDrive is ready to create Snapshot copy ({4d6e1978-1b45-4176-81d6-94ee3d4a5be4}_backup) of LUN(s).

13. Snapshot ({4d6e1978-1b45-4176-81d6-94ee3d4a5be4}_backup) of LUN(s) on storage

system (Filer05) volume (vol_clvsh01_csv03|) was successfully created. [As per step 8d in the Low level workflow]

14. DeleteTargetLun succeeded.

Storage System Name = Filer05

lunPath = /vol/vol_clvsh01_csv03/{8b0053c1-8cec-4cc6-8400-3220eaa8ecc3}.rws

15. Data ONTAP VSS hardware provider has successfully unmapped and deleted a lun [VendorId=NETAPP, ProductId=LUN, SerialNo=7S-zp$Bb5jSb].

16. The Snapshot copy ({4d6e1978-1b45-4176-81d6-94ee3d4a5be4}_backup) of the LUN

was renamed to (Virtual-Machines_clvsh01_CNVSH05_03-21-2014_22.00.00_backup).

LUN Name = clvsh01_csv03.lun

Storage Path = /vol/vol_clvsh01_csv03

Protocol Type =

Storage System Name = Filer05

17. SnapManager for Hyper-V backup operation completed successfully

Backup of the Dataset Name: Virtual-Machines

Backup id: 6ad83514-21a0-4a99-a774-8bf6e38c281e succeeded

18. The Snapshot copy (@snapmir@{91F05093-39B1-421E-8BF7-8C3A0526F253}) of the LUN (C:\ClusterStorage\Volume3\) on storage system (Filer05) volume (vol_clvsh01_csv03) was deleted

19. SnapDrive is ready to create Snapshot copy (@snapmir@{0C5AB7A3-182E-455C-919E-

E787EBDFD589}) of LUN(s).

20. Snapshot (@snapmir@{0C5AB7A3-182E-455C-919E-E787EBDFD589}) of LUN(s) on storage system (Filer05) volume (vol_clvsh01_csv03) was successfully created.

21. A SnapMirror update request from source (Filer05:vol_clvsh01_csv03) to destination

(filer06:vol_clvsh01_csv03) was successfully sent.

22. The VSS service is shutting down due to idle timeout.

23. Data ONTAP VSS hardware provider is unloaded.

24. Data ONTAP VSS hardware provider service has stopped.

25. SnapDrive is ready to create Snapshot copy (smhv_snapinfo_clvsh01_03-21-2014_22.00.00.1.24) of LUN(s).

26. Snapshot (smhv_snapinfo_clvsh01_03-21-2014_22.00.00.1.24) of LUN(s) on storage

system (Filer05) volume (vol_clvsh01_snapinfo) was successfully created.

27. The Snapshot copy (smhv_snapinfo_clvsh01_12-10-2013_22.00.00.398.18) of the LUN (S) on storage system (Filer05) volume (vol_clvsh01_snapinfo) was deleted

28. The Snapshot copy (@snapmir@{66C85B3D-4B9B-42A9-BAB2-B6C5784FB0A0}) of the

LUN (\\?\Volume{32776c92-5309-4361-8d99-cdf419374bef}\) on storage system (Filer05) volume (vol_clvsh01_snapinfo) was deleted

29. SnapDrive is ready to create Snapshot copy (@snapmir@{8D8B23C3-6577-4D13-8D19-

5DC0A7DED8C6}) of LUN(s).

30. Snapshot (@snapmir@{8D8B23C3-6577-4D13-8D19-5DC0A7DED8C6}) of LUN(s) on storage system (Filer05) volume (vol_clvsh01_snapinfo) was successfully created.

31. A SnapMirror update request from source (Filer05:vol_clvsh01_snapinfo) to destination (filer06:vol_clvsh01_snapinfo) was successfully sent.

Note: In the workflow described above, Filer05 is the production NetApp FAS/filer & Filer06 is the replication DR partner.

DRAWBACK in WINOWS 2008 R2 HYPER-V

The same process continues for Host2, Host 3 & so on depending upon the number of hosts in the cluster hosting the VMs, and the backup is then complete from the VSS requestor's perspective. This makes the Hyper-V backup complex for CSV. Performance is big issue since multiple VSS initializations/backup complete are done on each node in the cluster. This type of solution is hard to scale as the number of nodes and VMs in a cluster increases like in WS2012.

Good News

Microsoft has re-architected Cluster Shared Volume and has introduced 'Distributed CSV

Application consistent backup' feature in WINDOWS 2012 to address this problem. Watch this video to get detailed information on this 're-born' architecture. Cluster Shared Volumes Reborn in Windows Server 2012: Deep Dive http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/WSV430

FAQ

Why autorecovery is required? In short, auto-recovery is required b'cos virtual machine and storage system snapshots may not be in a consistent state due to a time lag between the two [child VM snapshot & Storage system snapshot] snapshots.

What is auto-recovery? Auto-recovery is a process in which 'shadow copy' created by the 'VSS Hardware provider' is temporarily made available as a read-write volume so that VSS and one or more applications can alter the contents of the shadow copy before the shadow copy is finished. After VSS and the applications [SMHV] make their alterations, the shadow copy is made read-only. This phase is called Auto-recovery, and it is used to undo any file-system or application transactions on the shadow copy volume that were not completed before the shadow copy was created.

Why does HYPER-V host does not support backing up pass-through & iSCSI disk in the child partitioned VM?

It is b'cos the 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.

Major benefits of CSV over traditional cluster disk:

CSV can fail over quickly without requiring a change in drive ownership The failover will not require a dismount or remount of the CSV Volume It helps simplify management Scale-out File Server can use an CSV CSV supports Bitlocker CSV supports Storage spaces CSV supports backup CSV supports Anti-Virus

How CSV disks are viewed in the HYPER-V Host?

Disks in CSV are identified with a path name. Each path appears to be on the system drive of the node as a numbered volume under the \ClusterStorage folder. This path is the same when viewed from any node in the cluster. You can rename the volumes if needed. To use CSV, your nodes must meet the following requirements:

Drive letter of system disk. On all nodes, the drive letter for the system disk must be the same.

Authentication protocol. The NTLM protocol must be enabled on all nodes. This is enabled by default.

Which are the Conditions when SMHV will backup virtual machines using 'save-state':

Virtual machines that do not have Integration Services installed will be put in a saved state while the VSS snapshot is created.

Virtual machines that are running operating systems that do not support VSS, such as

Microsoft Windows 2000 or Windows XP, will be put in a saved state while the VSS snapshot is created.

Virtual machines that contain dynamic disks (not dynamically expanding) must be

backed up offline.

How many Virtual Machines can be placed on the single CSV volume?

There are no limitations for the number of virtual machines that can be supported on a single CSV volume. However, you should consider the number of virtual machines that you plan to have in the cluster and the workload (I/O operations per second) for each virtual machine. Consider the following examples:

One organization is deploying virtual machines that will support a virtual desktop infrastructure (VDI), which is a relatively light workload. The cluster uses high-performance storage. The cluster administrator, after consulting with the storage vendor, decides to place a relatively large number of virtual machines per CSV volume.

Another organization is deploying a large number of virtual machines that will support

a heavily used database application, which is a heavier workload. The cluster uses lower-performing storage. The cluster administrator, after consulting with the storage vendor, decides to place a relatively small number of virtual machines per CSV volume.

Is there a recommendation for creating VMs on CSV volume?

There is no hard & fast recommendation but, follow arrangement is recommended. System files, including a page file, in a VHD file on one CSV Data files in a VHD file on another CSV

What is VSS?

Volume Shadow Copy Service (VSS) is a feature of Microsoft Windows Server that coordinates dataservers, backup applications, and storage management software to support the creation and management of consistent backups. VSS coordinates Snapshot copy-based backup and restore operations and includes these components: VSS Requestor: The VSS requestor is a backup application, such as SnapManager for Hyper-V or NTBackup. It initiates VSS backup and restore operations. The requestor also specifies Snapshot copy attributes for backups it initiates. VSS Writer: The VSS writer owns and manages the data to be captured in the Snapshot copy. Microsoft Hyper-V VSS Writer is an example of a VSS writer. VSS provider: The VSS provider is responsible for creating and managing the Snapshot copy. A provider can be either a hardware provider or a software provider:

What is a hardware provider? A hardware provider integrates storage array-specific Snapshot copy and cloning functionality into the VSS framework. Note: To ensure that the Data ONTAP VSS Hardware Provider works properly, do not use the VSS software provider on Data ONTAP LUNs. If you use the VSS software provider to create Snapshot copies on a Data ONTAP LUN, you cannot delete that LUN by using the VSS Hardware Provider.

Why hardware provider is called hardware? A provider that manages shadow copies at the hardware level by working in conjunction with a hardware storage adapter or controller.

Why software provider is called software? A provider that intercepts I/O requests at the software level between the file system and the volume manager.

What is freeze during shadow copy creation? Freeze is a period of time during the shadow copy creation process when all writers have flushed their writes to the volumes and are not initiating additional writes.

What is the purpose of hardware provider? The Data ONTAP VSS Hardware Provider integrates the SnapDrive service and storage systems running Data ONTAP into the VSS framework. This is required for VMs running on SANstorage.

Do I need to download and the install hardware provider separately [NetApp Specific]?

No! The Data ONTAP VSS Hardware Provider is installed automatically as part of the SnapDrive software installation.

How do I find out, if NetApp VSS Hardware provider installed? On the HYPER-V host, where you have installed 'snapdrive', go to command prompt: type –

c:\>vssadmin list providers

The output should be similar to the following:

Provider name: ‘Data ONTAP VSS Hardware Provider’

Provider type: Hardware

Provider ID: {ddd3d232-a96f-4ac5-8f7b-250fd91fd102}

Version: 6.4.1.xxxx

Is there a time limit for commiting a snapshot by provider in the VSS framework?

VSS framework requires that the provider commit a Snapshot copy within 10 seconds. If this time limit is exceeded, the Data ONTAP VSS Hardware Provider logs Event ID 4364. This limit could be exceeded due to a transient problem.

What are the different types of VSS Hardware providers? Tested hardware VSS providers table is provided in this link. http://blogs.technet.com/b/dpm/archive/2010/02/05/tested-hardware-vss-provider-table.aspx

How to choose a backup vendor for HYPER-V? When looking for backup software, make sure it states it supports Cluster Shared Volumes; such as System Centre Data Protection Manager 2010, NetApp, Veeam & Altaro. Also, to ensure the best performance backup, if you have hardware that supports Volume Shadow Copy Service (VSS), make sure you have the VSS hardware provider installed on all nodes in the cluster.

In SMHV [SnapManager for HYPER-V], what is application-consistent backup? Application-consistent backup jobs are thorough, reliable, and resource intensive. They are performed in coordination with Microsoft Volume Shadow CopyService (VSS) to ensure that each application running on the VM is quiesced before making a Snapshot copy. This backup method guarantees application data consistency.

In SMHV [SnapManager for HYPER-V], what is Crash-consistent backup? Crash-consistent backup jobs are quick Snapshot copies of all the LUNs used by VMs involved in a dataset. The resulting backup copies are similar to the data captures of VMs that crash or are otherwise abruptly powered off. Crashconsistent backup jobs provide a quick way to capture data, but the VMs must be present to be restored from a crash-consistent backup. Crash-consistent backup jobs are not intended to replace application-consistent backup jobs. A crash-consistent backup job makes only one Snapshot copy, always. It does not provide VSS integration.

Cluster shared volume

CSV is a feature of failover clustering that was introduced in Windows Server 2008 R2. CSV allows you to store multiple virtual machines running on multiple hosts in a cluster on a single storage volume. A CSV is a shared single disk that contains an NTFS volume. Multiple virtual machines can be stored on a CSV, and the CSV can be accessed by multiple Hyper-V host servers installed on failover cluster nodes. You can have multiple CSVs in a Hyper-V cluster. Typically, all of the virtual hard disks (VHDs) of virtual machines in the cluster are stored on a common CSV, so that any node in the cluster can access the VHDs. Note: CSV isn't referenced by a drive letter; it's a redirect point from %SystemPartition%\ClusterStorage\VolumeX As 'C: \' is used as the system drive most of the time, it basically translates to C:\ClusterStorage\VolumeX TIP: When creating a dataset, select all VMs that reside on a particular Data ONTAP LUN. This enables you to get all backups in one Snapshot copy and to reduce the space consumption on the storage system. It is preferable to add VMs running on the same CSV in the same dataset. Deploying Cluster Shared Volumes (CSV) in Windows Server 2008 R2 Failover Clustering: http://blogs.msdn.com/b/clustering/archive/2009/02/19/9433146.aspx

Typical CSV diagram

CSV [Introduced in Windows 2008R2] Vs Physical disk resource [Used in Windows 2008]

http://blogs.msdn.com/b/clustering/archive/2009/03/02/9453288.aspx

What is Direct and Redirect I/O

Each Hyper-V host has a direct path (direct I/O) to the CSV storage Logical Unit Number (LUN). However, in Windows Server 2008 R2 there are a couple of limitations: For some actions, such as backup, snapshot, de-frag [any low-level fileystem task] the CSV coordinator takes control of the volume and uses redirected instead of direct I/O. With redirection, storage operations are no longer through a host’s direct SAN connection, but are instead routed through the CSV coordinator. This has a direct impact on performance. CSV backup is serialized, so that only one virtual machine on a CSV is backed up at a time, but this is only true if you are using VSS software provider. When using a hardware VSS backup the volume only stays in redirected mode for a short period, i.e. during snapshot. When a backup is initiated on a CSV volume, the volume is placed in Redirected Access mode. The type of backup being executed determines how long a CSV volume stays in redirected mode. If a software backup is being executed, the CSV volume remains in redirected mode until the backup completes. If hardware snapshots are being used as part of the backup process, the amount of time a CSV volume stays in redirected mode will be very short. In Windows Server 2012, these limitations were removed: I/ORedirection is no longer used.

USEFUL LINKS

Overview of Processing a Backup under VSS http://msdn.microsoft.com/en-us/library/windows/desktop/aa384589(v=vs.85).aspx Volume Shadow Copy Service http://technet.microsoft.com/en-us/library/ee923636(v=ws.10).aspx Cluster Shared Volumes in a Failover Cluster http://technet.microsoft.com/en-us/library/jj612868.aspx Cluster Shared Volume (CSV) Inside Out [Windows 2012] http://blogs.msdn.com/b/clustering/archive/2013/12/02/10473247.aspx What's New in Failover Clustering in Windows Server 2012 http://technet.microsoft.com/en-us/library/hh831414.aspx SMHV: Virtual Machine backups take a long time to complete Microsoft has released a hotfix to correct this issue and allow the Hyper-V Backup Integration Services to utilize the native software provider for VSS. http://support.microsoft.com/kb/975354 Note: This hotfix is also included in Windows 2008 R2 Service Pack 1 TR-4234: NetApp SnapManager 2.0 for Hyper-V on Data ONTAP Operating in 7-Mode Best Practices Guide https://fieldportal.netapp.com/Core/DownloadDoc.aspxdocumentID=107024&contentID=169444 NetApp Storage Best Practices for Microsoft Virtualization and NetApp SnapManagerfor HyperV http://www.netapp.com/us/system/pdf-reader.aspx?m=tr-3702.pdf&cc=us Cluster Shared Volumes http://en.wikipedia.org/wiki/Cluster_Shared_Volumes John Savill, Introduction to Cluster Shared Volumes http://windowsitpro.com/windows-server-2008/q-i-am-using-cluster-shared-volumes-my-windows-2008-r2-hyper-v-environment-how-s Unable to access ClusterStorage folder on a passive node in a server 2008 R2 cluster: http://support.microsoft.com/kb/2008795 MIGRATING VMWARE TO HYPER-V https://gilgrossblog.wordpress.com/2014/02/19/migrating-vmware-to-hyper-v/

Good News on Veeam & NetApp collaboration [April, 2014]: Veeam Software is collaborating with NetApp to create a new data protection solution for the modern data centre to enable always-on business. [I am assuming this will allow Veeam to use NetApp VSS Hardware Provider for storage snapshot]. This integration, according to the company, will bring together the low RPO enabled by NetApp Snapshot, which lets enterprise IT back up the production environment to other storage options every 15 minutes with no impact on performance, and the low recovery time objective (RTO) capability enabled by Veeam Backup & Replication, whose Explorer for Storage Snapshots provides quick and convenient item-level recovery from NetApp Snapshot, SnapMirror and SnapVault. For more info, go to this link: http://go.veeam.com/v8-netapp Courtesy: Veeam Backup & Replication for HYPER-V http://helpcenter.veeam.com/backup/70/hyperv/backup_process.html Courtesy: NetApp SnapManager for HYPER-V Courtesy: Microsoft Courtesy: http://en.wikipedia.org/ ashwinwriter@gmail.com April, 2014