data protection technologies for microsoft private … · physical storage when the virtual hard...

DATA PROTECTION TECHNOLOGIES FOR MICROSOFT PRIVATE CLOUD

Anupam ChakrabortyPrincipal Software [email protected]

Sunil YadavConsultant Software [email protected]

Soumen Acharya Senior Software [email protected]

Tushar Dethe Senior Software EngineerEMC [email protected]

mailto:[email protected]




2015 EMC Proven Professional Knowledge Sharing 2

Table of Contents

Challenges in Protecting Private Cloud ...................................................................................... 3

What to backup for each virtual machine? .................................................................................. 5

Virtual Hard Disk .................................................................................................................... 5

Incremental backups & Synthetic full restore of Virtual Machines ............................................... 8

Synthetic full restore ..............................................................................................................10

Application consistency of Hyper-V host level backup ...............................................................11

Virtual Machine Backup .........................................................................................................11

Virtual Machine Restore ........................................................................................................13

Granular Level Restore (File Level Restore) ..........................................................................14

Hyper-V High Availability Virtual Machines on Cluster Shared Volumes ...................................14

Hype-V CSV Backup from a Single Node of a Cluster ...........................................................15

Using backup proxy for Hyper-V CSV configuration...............................................................17

Trouble Shooting Backup Failures ............................................................................................18

Partial Writer Backup .............................................................................................................18

Logs to check for backup failure ............................................................................................18

Microsoft Private Cloud Data Protection using Networker Module for Microsoft ........................20

Conclusion ................................................................................................................................21

Appendix ...................................................................................................................................23

Disclaimer: The views, processes or methodologies published in this article are those of the

authors. They do not necessarily reflect EMC Corporation’s views, processes or methodologies.


Challenges in Protecting Private Cloud

Many organizations are building private cloud for better customization, utilization of resources,

control over data, and security. Though private cloud is inside an organization, it still satisfies

the characteristics of Cloud Computing – scalability and elasticity. Clouds are built with 3 main

resources namely, compute, storage, and network. For Microsoft, private cloud Hyper-V Servers

are mainly used for computation.

Scalability and high availability of Hyper-V Virtual Machines (VMs) are achieved by creating

Hyper-V Clusters on Cluster Shared Volume (CSV) or Scale-Out File Servers. But high

availability doesn’t eliminate the necessity of backup. As well, it doesn’t protect from deleting

data by mistake nor does it eliminate the need for regulatory compliance.

The scalability aspect of Hyper-V cluster has created challenges on existing backup

applications. The backup should complete in less time to meet the restore point objective (RPO)

even though the Hyper-V Cluster is scaled up from hundred to thousand machines. This article

describes the technology available to control your backup time in a scale-out environment.

Incremental backup is an aspect of data protection which is mandatory for accelerating your

backup speed, minimizing of network bandwidth, and reducing the backup window. Incremental

backup tracks the data changed since the last backup and sends the changed data over IP

network to the backup storage. In Hyper-V, incremental backup can be enabled for each virtual

machine via Hyper-V WMI API.

Incremental backups are good to reduce backup time but it increases restore time objective

(RTO). During restore, the Backup Administrator needs to restore a full backup and then needs

to apply a number of incremental backups to restore at the desired point in time. This process

can become time consuming. In this situation, how do we improve RTO? The RTO is improved

by synthesizing VMs in the backend. The synthesize process recreates a full VM from its

incremental backups and last full or synthetic-full backup. This article explains how the

synthesized backup can be created by merging differencing hard disk containing incremental

data to the parent hard disk.

In production environment, virtual machines (VMs) running application servers (SQL,

SharePoint, or Exchange) and Hypervisor server (Hyper-V Server: hosting those virtual

machines) may be loaded enough to handle the backup operation. A long running backup may

impact the performance of business critical applications. How do we improve backup


performance in such situations? Can the backup operation be offloaded to a non-loaded

machine? Yes, it is possible. This article will describe the technology behind backup proxies.

This proxy node architecture is also scalable and multiple proxy nodes can be configured in a

cluster. These proxy nodes process VM backups in parallel when working to protect a large

scale environment in a short backup window. This architecture opens a new paradigm in data

protection to become an integral part of cloud backup and restores strategies.

The administrator has backed up the virtual machine. What is the guarantee that the backup is

consistent for the application running inside the virtual machines? This article describes how the

VSS writer inside the VMs takes part in the Volume Shadow Copy (VSS) snapshot process for

the virtual machines. This guarantees consistent backup for the application running inside virtual

machines. For example, an administrator can restore a SQL database or Exchange database

from the VM backup.

In a scalable environment, the number of VMs will keep growing. As the number of VMs grows,

if an error occurs during creation of snapshot of a single VM, the entire backup fails. The

snapshot of a virtual machine can fail for many reasons. For example, the VM hard disk is full or

VSS writer inside the VM has gone to a bad state. It is extremely difficult to troubleshoot the

problematic VMs and maintain the RPO for good VMs. This article describes how the partial

writer feature of Volume Shadow Copy Service helps to back up the healthy VMs and provides

diagnostic information for the bad VMs. Your Hyper-V Admins can use this information and fix

the issues themselves.

This article describes how EMC Networker® Module for Microsoft (NMM), a leading enterprise

backup and recovery software, solves the above problems. Configuration of backup for high

available cluster environments is a tedious process. Using NMM it is easy to configure backup

using a wizard that takes a few inputs from the user to validate the Hyper-V cluster environment

and configure backup. The cluster-aware backup of NMM protects your private cloud completely

and enables you to perform restore of a complete virtual machine application data inside the

VM. NetWorker integrated with Data Domain® (DD) ensures the optimal storage utilization.

Let us start with understanding the internals of VMs and what needs to be backed up to protect

a VM hosted in a Microsoft Private Cloud.


What to back up for each virtual machine

In this section we will describe the components of a VM. Following are the components of each VM1:

Configuration XML

Chain of virtual hard disks

Saved State file

Memory .bin file

List of Snapshots, each of which contains:

Configuration XML

Saved State file

.avhd files

File type File extension Description

Virtual Hard Disk

files

.VHD (WS 2008 R2 &

earlier)

.VHDX (WS 2012 & later)

VMs created on Hyper-V uses the

Microsoft Virtual Hard Disk (VHDX)

specification to store virtual hard disks

for VMs. A VM can have one or more

virtual hard disks.

VM configuration .XML Hyper-V uses a VM configuration file in

XML format to store VM settings (for

example, CPU, memory, VHDs).

VM Running State

files

.BIN

.VSV

Hyper-V stores VM running state

(memory) files.

Virtual Hard Disk

Differencing files

.AVHD (WS 2008 R2 &

earlier)

.AVHDX (WS 2012 & later)

A VM snapshot creates one differencing

VHD file per VM VHD.

VM Configuration

Snapshot(s)

.XML A VM snapshot creates a copy of the

current VM configuration and saves it to

enable rollback.

Table 1: Components of a Virtual Machine (VM)

Virtual Hard Disk

In the previous section, we learned that Virtual Hard Disks (VHDs) are used as the hard disks

for virtual machines (VMs). A VHD is a large container file that simulates a hard disk image. We

will discuss different types of VHDs and particularly differencing VHD (AVHD) as they are

necessary for Hyper-V incremental backup and creating Synthetic full backups. There are three

types of Virtual Hard Disk files.


1. Fixed Sized VHD - In fixed sized VHD, the space to store the file is allocated on the

physical storage when the virtual hard disk is created. For example, if you create a virtual

hard disk that is 2 GB in size, the system will create a host file approximately 2 GB in size.

2. Dynamically Expanding VHD - A dynamically expanding VHD at any given time is as large

as the actual data stored in it. Dynamically expanding VHDs are useful because they do not

require all the storage needed to contain the maximum size of the disk to be reserved up

front2. As more data is written, the file dynamically increases in size. For example, the size

of a file backing a virtual hard disk of 2 GB is initially around 2 megabytes (MB) on the host

file system. As data is written to this image, it grows to a maximum size of 2 GB.

3. Differencing VHD - A differencing disk is a virtual hard disk (VHD) that stores changes

made to another VHD or to the guest operating system. The differencing disk stores all

changes that would otherwise be made to the parent disk if the differencing disk was not

being used3.

A differencing VHD must be associated with a parent VHD. The parent VHD can be a fixed

sized, dynamically expanding or differencing VHD. In Hyper-V, differencing VHDs are also

created automatically whenever snapshots are taken of a virtual machine. A differencing hard

disk is merged with its parent hard disk when a user deletes a virtual machine snapshot.


Figure 1: Parent-child relationships of differencing VHDs3

In Figure1, a Virtual Machine “W2K12” has a virtual hard disk “W2K12base.vhdx”. A snapshot of

the VM was taken before applying Service Pack 1. So a differencing VHD, “W2K12SP1.avhdx”

is created to store the changes made for installing Service Pack 1.


Following are some PowerShell Cmdlets for performing various tasks with VHD:

PowerShell Cmdlets Description

New-VHD Creates one or more new virtual hard disks.

Get-VHD Gets the virtual hard disk object associated with a virtual hard

disk.

Set-VHD Sets the ParentPath or PhysicalSectorSizeBytes properties of a

virtual hard disk.

Mount-VHD Mounts one or more virtual hard disks.

Dismount-VHD Dismounts a virtual hard disk.

Convert-VHD Converts the format, version type, and block size of a virtual hard

disk file.

Optimize-VHD Optimizes the allocation of space used by virtual hard disk files,

except for fixed virtual hard disks.

Resize-VHD Resizes a virtual hard disk. This cmdlet lets you shrink or expand

the size of a virtual hard disk.

Merge-VHD Merges virtual hard disks. The Merge-VHD cmdlet merges virtual

hard disks in a differencing virtual hard disk chain. The merge is

from a specified source child disk to a specified destination child

disk. Merge is an offline operation; the virtual hard disk chain

must not be attached when merge is initiated.

Test-VHD Tests a virtual hard disk for any problems that would make it

unusable.

Table 2: PowerShell Cmdlets for performing various tasks with VHD12

We have described differencing VHD and merging a child VHD with its parent VHD in the above

section. These two concepts are used in Hyper-V incremental backup and creating synthetic full

backup from incremental backups.

Incremental backups and Synthetic full restore of Virtual Machines

Windows Server 2012 and later supports incremental backup of a virtual machine. To enable

incremental backup of a VM, Windows Server 2012 and later have introduced a new property,

‘IncrementalBackupEnabled’ of the ‘Msvm_VirtualSystemSettingData’ data type in WMI v2.


Setting this property to ‘true’ enables incremental backup of the Virtual Machines. Hyper-V uses

a special type of checkpoints called recovery snapshots to track the differences between

backups4. Recovery snapshot is similar to regular virtual machine snapshot but they are

managed directly by Hyper-V Virtual Machine Manager.

To enable change tracking, the VM must be enabled for incremental backup using WMI API.

Full backup must be performed after incremental backup is first enabled. So the first full backup

copies complete VHD hierarchy, configuration XML, and leave a differential VHD around. The

next backup just backs up the differential virtual hard disk. Thus during each incremental

backup, only the differences (differencing virtual hard disk) is backed up. The virtual machines

configuration xml files which are very small in size are backed up every time. Thus, Hyper-V

incremental backup reduces backup time, network bandwidth, and disk space. This reduces the

backup window and helps to maintain RPO in a scaled out environment.

In Figure 2, during an incremental backup a VM will have two levels recovery snapshots. The

earlier recovery snapshot is merged into the base virtual hard disk at the end of the backup

process and one new recovery snapshot tracks the changes in the VM after the backup process

started5 . For example, Virtual Machine is enabled for incremental backup on Sunday. The first

backup on Sunday backs up the complete VHD hierarchy. Incremental backup of Monday and

Tuesday backs up only the differencing VHDs. The differencing VHDs backed up in each

incremental backup is merged with its previous backups to create Synthetic Full backup. On

Friday, restore from Synthetic Full backup of the VM was performed to get back the state of the

VM as it was in Tuesday.


Figure 2: Incremental backup of a VM with 1 VHD and shows 3 days of backup (Sunday, Monday & Tuesday)

followed by Synthetic full restore on Friday5.

Synthetic full restore

Incremental backups are good to reduce backup time but it has a cost attached with it. During

restore, the Backup Administrator needs to restore a full backup and then needs to apply a

number of incremental backups to restore at the desired point in time. This increases restore

time objective (RTO) which can be controlled by synthesizing VM from incremental backups.

The differencing VHDs backed up during an incremental backup are merged with the VHDs

from previous backups to create a synthetic full backup of the virtual machine. The restore from

a synthetic-full VM reduces the time of restoring a chain of incremental backups during disaster

restore. Thus Synthetic full restore improves RTO.


Application consistency of Hyper-V host level backup

Backup administrator often protects complete VM and installs backup application inside VM to

protect applications like SQL, Exchange, or SharePoint running inside the VM. This two-fold

data protection increases data traffic on Local Area Network (LAN), takes twice the amount of

backup storage, and consumes more CPU and I/O cycles from Hyper-V Server. In this section,

we have described why backup of a VM is sufficient and how it protects the applications running

inside the VM.

Volume Shadow Copy Service (VSS) facilitates backup operation for Windows OS. It co-

ordinates with backup Application (VSS Requestor), Applications to be backed up (Hyper-V \

SQL \ Exchange \ SharePoint, etc.) and storage to create application consistent shadow copies

for backup. Hyper-V VSS writer is used to create application-consistent backup of the VMs.

Suppose a SQL server is running inside your VM and you have copied the VM’s hard disk file

(VHD file) when the SQL Server was in the middle of a transaction. It is not guaranteed that the

SQL server will be in a consistent state after you restore the VM from the copied VHD. On the

other hand, if the backup is taken involving VSS framework, restore from this backup works.

This is because Hyper-V VSS writer allows SQL server to quiesce the data and put it in a point

in time before backup, such that restore from it works.

There are following cases where we recommend to backup applications inside the VM:

1) If a VM is configured with Pass-through disk or iSCSI disk that are not included in Hyper-

V back up, it is recommended to run backup application inside VM.

2) Backup agents inside VMs are capable to perform intelligent backups for clustered

application. For example, to back up only the passive copy of SQL Databases (SQL

DBs) on an Always-On Availability Group, administrator must configure backup inside

the VM.

Virtual Machine Backup

In Hyper-V host level backup, backup application talks to VSS and uses Hyper-V VSS writer on

the Hyper-V Server. Hyper-V VSS writer on Hyper-V Server talks to Hyper-V VSS integration

component (Hyper-V IC) inside the VM. Hyper-V IC inside the VM works like a backup

application and talks to VSS and VSS writer of the applications running inside the VM. The

following sequence diagram explains the mechanism of application consistent backup of VMs1.


Figure 3: Hyper-V VSS Writer communicates with Hyper-V VSS IC (requestor) inside VMs to quiesce

application inside VMs for application consistent backup1

Figure 4: Sequence diagram for application consistent backup of VMs1


The flow of calls to create a snapshot of a virtual machine:

1) To back up a VM, the backup application (VSS Requestor) calls into VSS to

DoSnapshotSet(). The backup application requests VSS to create consistent point-in-time of

the storage.

2) VSS call each of the registered writers and asked them to PrepareForSnapshot() including

the Hyper-V VSS writer.

3) Hyper-V VSS writers talks over its private channel to Virtual Machines Hyper-V VSS IC (that

is the guest requestor).

4) Hyper-V VSS IC also call the DoSnapshotSet() to the VSS framework inside the virtual

machine.

5) VSS call the PrepareForSnapshot() for all applications running inside the VM.

6) Applications quiesce themselves and returns control backup to VSS inside VM.

7) Inside VM the VSS takes snapshot using volsnap (system provider).

8) Control is returned to VSS which then notifies writer that VM quiesce is completed.

9) These steps are done for all the virtual machines selected for backup.

10) When VSS completes processing for all VMs, it create a snapshot on the physical machine.

VSS returns control to the backup App.

11) At this point, backup app copies the data from the snapshot created on the physical

machine.

Virtual Machine Restore

A virtual machine can be restored from the backup using VSS framework. Hyper-V VSS writer is

invoked with pre-restore call with metadata that includes a list of VMs going to be restored.

Hyper-V VSS writer looks at the metadata and checks if a VM already exists and deletes the

configuration XML and VHD files. Backup application then restores the files and fixes the

Access Control Lists (ACLs) to restore the files with right ACLs and then call post restore on

Hyper-V VSS writer. In post-restore step, Hyper-V VSS writer checks if all the files have

restored and then registers the Virtual Machines. If the VM has been restored to an alternate

location, for example, a different machine or different location on the same machine, it ensures

that all the paths are aligned, all the AVHDs are pointing to right parents, and fixes the network

configuration1.


Granular Level Restore (File Level Restore)

In restore scenarios it is often required to retrieve a single file from the backup. In such

situations restoring an entire virtual machine is an overhead. Granular restore enables a user to

recover individual files or directories from the VM backup. A user can mount the backed up VHD

and then can explore the mount point from Windows Explorer. At this point, the user is actually

exploring data from backed up Virtual Hard Disk (VHD)4. You can drag and drop a file or folder

to another location. At that point, only the data you selected for copying is recovered. Thus, from

a VM backup a user can recover a complete VM or individual files within that VMs.

Hyper-V High Availability Virtual Machines on Cluster Shared Volumes

High Availability is one of the primary criteria for cloud infrastructure. Microsoft introduced

Cluster Shared Volumes (CSV) for Hyper-V High Availability Virtual Machines (VM). Microsoft

improved CSV for performance and backup\restore scenarios in Windows Server 2012 (WS

2012). In this section we will describe why CSV is essential for configuring High Available VMs

on Microsoft Private Cloud.

CSV is a clustered File System that provides simultaneous read-write access to all applications

running on all nodes of a cluster to a shared storage. Before introduction of CSV, an application

should have its own dedicated LUN and the LUN needs to failover with the application. With

CSV, the application can failover independent the LUN ownership.

Without CSV, a failover cluster only allows a given cluster disk (LUN) to be accessed by one

node at a time. Given this constraint, each Hyper-V virtual machine in the failover cluster

requires its own set of LUNs in order to be migrated or fail over independently of other virtual

machines. In this type of deployment, the number of LUNs increases with the addition of each

virtual machine, which makes management of LUNs and clustered virtual machines more

complex6.

In contrast, on a failover cluster that uses CSV, multiple virtual machines that are distributed

across multiple cluster nodes can all access their Virtual Hard Disk (VHD) files at the same time,

even if the VHD files are on a single disk (LUN) in the storage. The clustered virtual machines

can all fail over independently of one another6.


Figure-5: Hyper-V CSV Configuration: VM1, VM2, VM3 are active on different nodes of a Hyper-V cluster and

their files (Config XML, VHD, snapshots) are present on the same CSV volume.

CSV provides a simultaneous read write access to the shared LUN from all cluster nodes.

Virtual machine can run on any node and still write to a volume mounted on one of the cluster

nodes (coordinator node). Metadata synchronization for the I/O is done on the CSV coordinator

node and metadata changes from all the cluster nodes for a particular CSV volume are routed

to the coordinator node. Metadata operations are very light weight operations. Metadata

changes occur in the scenarios like VM creation\deletion, VM power on\off, VM mobility (live

migration), snapshot creation, extending a dynamic VHD, and renaming a VHD. Metadata

updates are small operations that happen infrequently for VMs.

Hype-V CSV Backup from a Single Node of a Cluster

New architecture of CSV provides a backup infrastructure that delivers distributed application

consistent backup for cluster shared volume.


Figure 6: Distributed application consistent backup of VMs in a cluster using new CSV writer and CSV

provider components7

CSV in WS 2012 and later supports distributed application consistent backup of VMs in a cluster

using new CSV writer and CSV provider components. In WS 2012, requestor can take a single

application consistent snapshot of all VMs running over multiple Hyper-V cluster nodes. VSS is

only initialized on the backup requesting node. Backup requesting node can be any node in the

cluster. VSS snapshots are created only on the backup requesting node7.

This arch diagram shows how the different components interact in WS 2012 to create an

application-consistent backup across a cluster. In this example, cluster has two nodes

“clusternode1” and “clusternode2”. VM1 and VM2 running on “clusternode1”; VM2 and VM3

running on “clusternode2”. All of them are running on same CSV volume. Backup is initiated by

a requestor from “clusternode1”. Backup requestor on clusternode1 talks to the VSS service to

gather the metadata and find out the files owned by VMs. In WS 2012, Hyper-V writer on the

local node reports all the VMs running on the local node. CSV writer on the local node serves

the metadata information of the VMs running on partner nodes using the Hyper-V writers

running on the partner nodes. For example, if we have a distributer 4-node cluster, from one

node we can talk to writers on the partner nodes and get the metadata of all VMs in the cluster7.


CSV provider synchronizes the backup mechanism between local node and partner node. It co-

ordinates with Hyper-V VSS writer in partner node to quiesce and thaw the VMs running on the

partner nodes and making sure VMs are in consistent state to take backup. The Hyper-V VSS

writer on the local node quiesces and thaws the local VMs for backup. Thus, from one node the

backup application can take the backup of all VMs running on the cluster using CSV writer and

CSV provider7.

Using backup proxy for Hyper-V CSV configuration

We have seen in the previous section that in a Hyper-V CSV environment snapshot can be

created for all VMs in a CSV and backup can be taken from any node of the cluster. This

functionality of CSV has enabled backup proxy architecture. This proxy node architecture is also

scalable and multiple proxy nodes can be configured in a cluster to process VM backups in

parallel when working to protect a large scale environment in a short backup window. This

architecture opens a new paradigm in data protection. This becomes an integral part of cloud

backup and restores strategies.

Figure 7: Proxy backup architecture for high performance, impact free protection

VSS snapshot will always be created on the node which currently owns the cluster Physical

Disk resource associated with the CSV volume. If the backup is performed locally on the

coordinator node, the data access will be local and backup performance may be improved. This


can be achieved by either initiating the backup application on the coordinator node or by moving

the Physical Disk resource locally to the node before initiating the backup. CSV ownership can

be moved seamlessly with no downtime. If you have maintenance window requirements that

require shortening the overall backup time, you may wish to optimize the performance of

backups when using software snapshots in one of the above ways8.

The other advantage of Proxy-based backup is that the CPU cost for backup is accounted on

the backup proxy; there is no extra CPU usage for the production server. There is no extra I/O

that production server needs to handle when the backup is going on. In Hyper-V proxy-based

backup, the production server is not impacted at all due to backup.

Troubleshooting Backup Failures

As the number of virtual machines grows it is extremely important to quickly troubleshoot the

cause of backup failure to maintain restore point objective (RPO). A whole backup can fail if an

error occurred during creation of snapshot of a single virtual machine. The snapshot of a virtual

machine can fails for many reasons. For instance, the hard disk inside the VM is full or VSS

writer inside VM goes to bad state. In this section, we will describe how to troubleshoot in case

of backup failure in your Microsoft private cloud environment.

Partial Writer Backup

Windows Server 2008 R2 Hyper-V VSS Writer and above provide support for partial backup

failure. Even if snapshot creation fails for some VMs, the backup can continue for other VMs.

Hyper-V VSS Writer reports the VMs which failed to back up. Suppose you are backing up 20

VMs and after successfully backup of 11 VMs the 12th VM fails to back up; the backup

application will continue backing up 13th VM onwards. The backup application will report 12th VM

failed to back up. In the following section we will see how to troubleshoot backup failure from

different logs.

Logs to check for backup failure

If Hyper-V backup fails, the backup administrator should check the Hyper-V VMMS log to figure

out which VM has failed. Hyper-V VMMS log is found at Event Viewer -> Applications and

Services Logs -> Microsoft -> Windows -> Hyper-V-VMMS->Admin. Hyper-V VMMS log also

states the reason of backup failure10. Following are two examples of troubleshooting backup

failure.


In the first example, backup failed as the creation of shadow copy inside VM was unsuccessful.

When we logged inside the VM we found that there is no space in its system drive. The

administrator of the VM freed some space in the system drive and the next backup completed

successfully.

In the second example, backup failed for VM as a pass-through disk was attached to the VM.

We have discussed in section “Virtual Machine Backup” that snapshot can’t be taken for a pass-

through disk and in this case backup application should be installed inside the VM.

Figure 8: Backup of VM “TestVM1” failed as creation of Shadow copy inside the VM fails


Figure 9: Backup of VM “PassThroughVM” failed as a pass-through disk was connected to it

Microsoft Private Cloud Data Protection using Networker Module for Microsoft

Figure 10: NetWorker Module for Microsoft (NMM) protecting a large Microsoft Private Cloud Deployment11


EMC NetWorker backup and recovery software centralizes, automates, and accelerates data

backup and recovery. NetWorker delivers industry-leading performance and a wide range of

data protection options to safeguard critical business data.11

Following are Key features of the NetWorker Module for Microsoft in protecting MS private

cloud:

Centralized management

Protection for Hyper-V CSV and SMB 3.0 environments

Incremental backup and Synthetic full restore of VMs

Multi-Proxy backup for high performance, impact-free protection

Automated protection of newly created VMs

OS and application-consistent protection

No requirements for backup agents inside guest VM

Reporting VMs for which snapshot creation fails

New Virtualization Management via SCVMM

Microsoft Private Cloud protection offering disaster and granular file recoveries

Granular Level Recovery (GLR) for VM files recoveries in minutes

Integrated with Industry-leading data deduplication storage (Data Domain)

Tenant UI for FLR (web-based restore)

Conclusion

We have discussed the backup technologies available to reduce backup window in a scale out

Microsoft Private Cloud environment. A VM stores its hard disk in the Hyper-V Server using

VHD format. A special type of VHD, called differencing VHD, is associated with its parent VHD

and stores all changes made to the parent VHD. Hyper-V uses differencing VHD to track

changes between two backups. Incremental backup can be enabled for each VM using WMI

API. After the incremental backup is enabled, a differencing VHD tracks the changes from last

back. In each incremental backup the differencing VHD is only backed, accelerating backup

speed and optimizing network bandwidth. The differencing VHD is merged with the VHDs from

previous backups to create a synthetic-full VM in the backend. The restore from a synthetic-full

VM reduces the time of restoring a chain of incremental backups during disaster restore.


We have seen that the Hyper-V VSS writer quiesces applications running inside VMs to take an

application-consistent backup of VMs. User can perform a complete VM restore, restore of an

application, and simply restore a file or directory from the VM backup.

Microsoft introduced Cluster Shared Volume which is a Cluster File System to support high

availability and scalability in cloud environments. Multiple virtual machines that are distributed

across multiple cluster nodes can all access their Virtual Hard Disk (VHD) files present on the

same CSV. In the new CSV architecture in Windows Server 2012 and later, snapshot of the

CSV volume can be created from any node in the cluster. This functionality of CSV has enabled

backup proxy architecture where a node in the Cluster is dedicated for backup operation. This

proxy node architecture is also scalable and multiple proxy nodes can be configured in a cluster

to process VM backups in parallel when working to protect a large scale environment in a short

backup window.

As the number of virtual machines grows it is extremely important to quickly troubleshoot the

cause of backup failure to maintain restore point objective (RPO). If snapshot creation fails for

some VMs, the Hyper-V VSS Writer reports those VMs and continues to backup other VMs.

Hyper-V VMMS log is found at Event Viewer -> Applications and Services Logs -> Microsoft ->

Windows -> Hyper-V-VMMS->Admin shows the reason of snapshot failure for VMs.

Finally, we discussed the features of NetWorker Module for Microsoft (NMM) that implements

the above technologies to protect Microsoft Private Cloud environments.


Appendix

1. Hyper-V Backup Deep Dive: A Look under the Hood by Soumya Das Bhaumik.

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2010/VIR322

2. Virtual Hard Disk (VHD) Architecture explained by Ranjana1.

http://blogs.technet.com/b/ranjanajain/archive/2010/03/23/virtual-hard-disk-vhd-

architecture-explained.aspx

3. Using differencing disks. http://technet.microsoft.com/en-

us/library/cc720381%28v=ws.10%29.aspx

4. Building a Backup Strategy for Your Private Cloud by Taylor Brown.

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B319

5. Disaster Recovery in the Cloud with Hyper-V Backup and Replica by Andrew McMurray.

http://channel9.msdn.com/Series/Hybrid-Cloud-Workloads-High-Availability-and-

Disaster-Recovery/Mod2

6. Understanding Cluster Shared Volumes in a Failover Cluster:

http://technet.microsoft.com/en-us/library/dd759255.aspx

7. Cluster Shared Volumes Reborn in Windows Server 2012: Deep Dive by Amitabh

Tamhane & Vineeth Karinta.

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/WSV430

8. Optimizing CSV Backup Performance by Elden Christensen.

http://blogs.msdn.com/b/clustering/archive/2013/05/06/10416507.aspx

9. Hyper-V over SMB: Remote File Storage Support in Windows Server 2012 Hyper-V by

Didier Van Hoye. http://technet.microsoft.com/en-in/video/hyper-v-over-smb-remote-file-

storage-support-in-windows-server-2012-hyper-v.aspx

10. Adventures with Hyper-V and Backup by Benjamin Armstrong.

http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/02/22/adventures-with-hyper-v-

and-backup.aspx

11. Backup And Recovery For Microsoft-Based Private Clouds Leveraging The EMC Data

Protection Suite. https://www.emc.com/collateral/white-papers/h12654-backup-and-

recovery-for-microsoft-private-clouds-leveraging-dps-wp.pdf

12. Hyper-V Cmdlets in Windows PowerShell: https://technet.microsoft.com/en-

us/library/hh848559.aspx

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2010/VIR322

http://blogs.technet.com/b/ranjanajain/archive/2010/03/23/virtual-hard-disk-vhd-architecture-explained.aspx

http://blogs.technet.com/b/ranjanajain/archive/2010/03/23/virtual-hard-disk-vhd-architecture-explained.aspx

http://technet.microsoft.com/en-us/library/cc720381%28v=ws.10%29.aspx

http://technet.microsoft.com/en-us/library/cc720381%28v=ws.10%29.aspx

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B319

http://channel9.msdn.com/Series/Hybrid-Cloud-Workloads-High-Availability-and-Disaster-Recovery/Mod2

http://channel9.msdn.com/Series/Hybrid-Cloud-Workloads-High-Availability-and-Disaster-Recovery/Mod2

http://technet.microsoft.com/en-us/library/dd759255.aspx

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/WSV430

http://blogs.msdn.com/b/clustering/archive/2013/05/06/10416507.aspx

http://technet.microsoft.com/en-in/video/hyper-v-over-smb-remote-file-storage-support-in-windows-server-2012-hyper-v.aspx

http://technet.microsoft.com/en-in/video/hyper-v-over-smb-remote-file-storage-support-in-windows-server-2012-hyper-v.aspx

http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/02/22/adventures-with-hyper-v-and-backup.aspx

http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/02/22/adventures-with-hyper-v-and-backup.aspx

https://www.emc.com/collateral/white-papers/h12654-backup-and-recovery-for-microsoft-private-clouds-leveraging-dps-wp.pdf

https://www.emc.com/collateral/white-papers/h12654-backup-and-recovery-for-microsoft-private-clouds-leveraging-dps-wp.pdf

https://technet.microsoft.com/en-us/library/hh848559.aspx

https://technet.microsoft.com/en-us/library/hh848559.aspx


EMC believes the information in this publication is accurate as of its publication date. The

information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION

MAKES NO RESPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO

THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an

applicable software license.

data protection technologies for microsoft private … · physical storage when the virtual hard...

Documents