Protecting Virtual Environments - Education …...Protecting Virtual Environments - 165 The...

Chapter 10

Protecting Virtual Environments

CommVault Concepts & Design Strategies: https://www.createspace.com/3726838

164 - Protecting Virtual Environments

As more datacenters move to virtualize their environments and the number of virtual machines and the physical

hosts they run on grows, a comprehensive protection strategy is required to ensure proper protection. This is a

complex problem as the number of virtual machines continues to increase and their backup windows continue to

shrink. The following chapter describes various strategies for protecting virtual environments using the

Simpana® Virtual Server Agent (VSA) and standard file system and application agents.

Note: This is a guide for planning and designing strategies for protecting virtual environments. This is not

a detailed engineering guide and CommVault STRONGLY recommends working with CommVault to

properly plan, implement, and optimize Simpana® for your virtual environment.

Simpana® Virtual Protection Methods

There are two primary methods CommVault software can use to protect virtual environments:

1. Virtual Server Agent (VSA)

2. iDataAgents installed within virtual machines

Which method is best to use depends on the virtual infrastructure, type of virtual machines being protected and

the data contained within the virtual machines. In most cases using the Virtual Server Agent will be the preferred

protection method. For specific virtual machines using an iDataAgent inside the VMs will be the preferred

method. In other cases using a combination of both the VSA and iDataAgents in the VMs could be used.


Protecting Virtual Environments - 165

The following table highlights basic capabilities and limitations for using the Virtual

Server Agent and iDataAgents.

Feature /

Capability

Virtual Server Agent

iDataAgent in VM

Overview

Provides disk level protection with granular

browse and recovery. For VMware backups

volume and file/folder protection is also

supported.

Backs up data using agent communication directly to

file system or application. This method for

protecting VMs operates just like a physical client in

a CommCell environment.

Recovery

performance of

virtual machine

Provides fast recovery performance by

recovering entire disk files.

Using full system restore or 1-Touch for VM

recovery. This process would be slower than

restoring virtual disks with VSA since it would be an

object level restore.

Recovery of virtual

disk volumes

Volume level restores only in VMware. For

Xen and Hyper-V file level browse and

recovery would be used to recover full

volumes.

Browse and restore or restore by job if volume was

defined as separate subclient.

Granular browse

capability

Granular browse is possible by indexing

virtual machines at time of backup. Indexing

VM backups is enabled by default.

Provides the same browse and recovery features as a

physical client. All agent capabilities are supported

when installed in VM.

Application

Protection

Only provides crash consistent protection of

application data. Scripts can be used to

quiesce application data prior to VSA backup

for application consistent protection.

Provides application consistent protection for

database and log files by directly communicating

with application to properly quiesce data.

Application

protection with

SnapProtect option

Provides application consistent snapshot and

backup protection for MS-SQL and Exchange.

Provides full integration with SnapProtect feature for

application consistent snapshot and backup

protection on all supported iDataAgents.



Crash Consistent and Application Consistent Protection

When choosing to use the Virtual Server Agent and/or iDataAgents inside of VMs it is important to consider what

is being protected. The state of the data at the time of backup is critical to be able to properly restore the data.

There are two possible states that data can be in at the time of backup, Crash Consistent or Application

Consistent.

Crash Consistent

Crash Consistent backups are based on point-in-time snapshot and backup operations of a virtual machine that

allows the VM to be restored to the point in which it was snapped. When the snapshot occurs all blocks on the

virtual disks are frozen for a consistent point-in-time view.

There are several issues when performing crash consistent snapshot and backup operations. The first issue is that

if an application is running on the virtual machine it is not aware the snapshot is being taken. VSA communicates

with the hosting hypervisor to initiate snapshots at the VM level and there is no communication with the

application. Any I/O processes being conducted by the application will continue without any knowledge that the

snap has been performed. This may cause issues if a VM hosting an application has high disk I/O activity at the

time the snap occurred.

The other issue is data integrity. Crash consistent means when a snap occurs, a logical view of the virtual disk

block structure is preserved for the backup operation. The crash consistent view would be the same as if you

turned the power off on an application server without properly shutting down the application. In this case,

maintenance may need to be performed on the application databases before they would be usable and there is the

possibility of data corruption. Crash consistent backups can work well for disk volumes containing file data but

this is not recommended for protecting application databases.

Crash Consistent backup performs a snapshot and backup of the disk at a point in time.

The application is not aware that this is being performed and data integrity is not

guaranteed.



Application Consistent

With Application Consistent protection, the application itself is aware that it is being snapped. This awareness

allows for the data to be protected and restored in a consistent and usable state. Application aware protection

works by communicating with the application to quiesce data or by using scripts to properly quiesce the data.

Application consistent protection is not critical for file data but is absolutely critical for application databases.

There are three methods to provide application consistent protection:

Simpana application iDataAgents – An iDataAgent installed in the VM will directly communicate

with application running in the VM. Prior to the snap operation the agent will communicate with the

application to properly quiesce databases. For large databases this is the preferred method for providing

application consistent point in time snap and backup operations. Using application agents in the VM also

provide database and log backup operations and a simplified restore method using the standard browse

and recovery options in the CommCell GUI.

Scripting database shutdowns – Using external scripts which can be inserted in the Pre/Post processes

of a subclient, application data can be placed in an offline state to allow for a consistent point-in-time

snap and backup operation. This will require the application to remain in the offline state for the entire

time of the snapshot operation. When the VM is recovered the application will have to be restarted after

the restore operation completes. This method is only recommended when Simpana agents are not

available for the application.

VSA and SnapProtect – For Microsoft SQL and Exchange virtual machines, application aware

protection can be performed using the VSA agent and Simpana SnapProtect™ feature. This concept

requires additional configurations and is covered in detail in the SnapProtect chapter.

Application Consistent backup performs a snapshot and backup of the application data

at a specified point in time. The application is aware that this is being performed and

will quiesce data.



Agent Based Protection

Agent based protection uses Simpana iDataAgents installed directly in the virtual machine. When an agent is

installed in the VM, it will appear in the CommCell console just like a regular client and the functionality will be

exactly the same as an agent installed on a physical host. The main advantage with this configuration is that all

the features available with Simpana agents can be used to protect data on the VM. For applications, using

iDataAgents provide complete application awareness of all data protection operations.

When using iDataAgents in VMs, data will be backed up through a Media Agent to protected storage. The Media

Agent can be locally installed on the virtual machine if the machine has direct access to storage or data can be

moved over the network to a dedicated Media Agent.

Agent based VM protection installs Simpana® agents directly in the VM. This allows

file systems and applications to be protected using all the features Simpana agents offer.



One issue when using iDataAgents in virtual machines is when the virtual machine needs to be restored. Since the

iDataAgent protects all data at the object level, the machine will need to be restored object by object. Compare

this method to using the VSA backup process which can restore the entire virtual machine at the disk level. When

protecting large databases which are backed up as single objects, iDataAgents can be a good solution. When

backing up file servers with large amounts of smaller objects, iDataAgents within the virtual machine would not

be a good solution.

With Simpana v9 Client Side Deduplication, data moved over the network is dramatically reduced once the first

full backup is completed. This provides an efficient method of backing up large amounts of data and is

recommended to improve backup performance when using agents inside of VMs. It‘s important to note that when

using client side deduplication in a virtual machine, all blocks will be hashed on the client. This processing will

be done using the hosting server‘s resources which may negatively impact performance when too many VMs are

being backed up concurrently. Carefully consider on which VMs you want to use iDataAgents and schedule

backup operations during off-peak hours when physical hosts have adequate resources to process and protect data.

File System iDataAgents

To protect an entire virtual machine or specific volumes on a VM, using the VSA is the preferred protection

method. If the VM only requires specific files or folders to be protected, or if specific data on the VM requires

special protection requirements such as scripting or filtering, a File System iDataAgent can be used.

In the following example a mission critical subclient has been defined to protect a small

amount of data on a virtual machine. The virtual machine is not required for protection

since a template can be used to recreate the VM in the event of full system failure.

Using this method on VMs with small amounts of data requiring protection can improve

overall performance by reducing the total amount of data that must be protected.

Granular Application Agents

Granular application agents provide the ability to protect objects within an application database providing

granular processing of application data. For example, Exchange data can be protected at the mailbox level by



using the Simpana Mailbox iDataAgent, Mailbox Archiving iDataAgent, or Compliance Archiving iDataAgent.

Each one of these agents provides object level protection that provides individual object recovery, content

indexing, or eDiscovery search capabilities. Data protected by these agents can also be independently managed by

subclients providing data lifecycle management capabilities that are not possible with the VSA agent.

Database Application Agents

Simpana database agents provide advanced protection features that would not be available when using VSA.

Separate protection of database and logs can be performed. Options to truncate logs or replay logs to a specific

point in time can be used to better manage database protection. Using database iDataAgents in virtual machines

provides application consistent database protection and is a preferred protection method.

The following diagram illustrates the use of agents in a virtual machine to provide

application consistent database and log backups. Using this method can allow for

shorter Recovery Point Objectives (RPOs) since log files can frequently be backed up

throughout the day. This level of granular protection is not possible when using the

VSA agent alone.

Virtual Server Agent (VSA)



The Simpana Virtual Server Agent (VSA) interacts with the hosting hypervisor to provide protection at the virtual

machine level. This means agents do not need to be installed directly on the virtual machines, although installing

restore-only iDataAgents will provide a simplified method for restoring data back to the VM. Simpana® software

currently supports VMware, Hyper-V, and Xen server with the Virtual Server Agent.

Depending on the hypervisor application being used and the virtual machine‘s operating system, different features

and capabilities will be available. The Simpana VSA interfaces with the hypervisor‘s APIs and provides

capabilities inherent to the application. As hypervisor capabilities improve, the Simpana VSA agent will be

enhanced to take advantage of new capabilities.

Backup Levels

Virtual machines are protected by VSA by invoking the hypervisor application to snap the VM. When the

snapshot is taken the VM can be backed up in a crash consistent point it time state. The VSA can backup

machines at the disk, volume, or file level depending on the hypervisor‘s capabilities.

The following table shows support at various backup levels:

Application Disk Level Volume Level File Level

VMware YES YES YES

Hyper-V YES NO NO

XEN Server YES NO NO

Disk Level

Disk level backups will protect all disks for a virtual machine and VM boot data. The entire VM can be recovered

and optionally automatically turned on after recovery. For VMware, disk volumes can also be independently

recovered. If Enable Granular Recovery is selected in Advanced Backup Options, files and folders can be

browsed and recovered.

Volume Level

Volume level backups allow you to select which virtual disks to backup. This is currently only supported with

VMware. This is best used when only specific data volumes need to be protected. System drives backed up at the

volume level will not be bootable with a direct restore of the volume. To select which volumes will be backed up,

use the subclient Filters tab to filter out volumes not to be backed up.

File Level

File level backups allow individual folders or files to be protected. Consider using this on virtual machines where

a base image can be retained and only small amounts of data changes on a regular basis. Use the Filter tab to

filter out all data that does not require protection. Use the Filter exceptions to define data that does require



protection. For example: Filter the C:\ drive and set an exception rule for C:\Users. This will only backup the

Users folder on the C drive.

When a file level backup is configured, the entire volume that contains the files or folders is snapped. During the

data movement process the VSA will filter out data that does not require protection. Because of this process, it

would be recommended to install a File System iDataAgent on the VM if only a small portion of a large volume

requires protection.

How VSA Works

VSA works by communicating with the hosting hypervisor to initiate software snapshots of virtual machines.

Once the VMs are snapped, VSA will back them up to protected storage.

The following steps are used to protect VMs in a virtual environment:

1. CommServe server communicates with VSA to initiate a data protection job.

2. VSA communicates with the hypervisor application to request software snapshots for virtual machines

defined in the subclient.

3. The hypervisor will quiesce the virtual machines and perform software snapshots of the VMs.

4. The virtual application will communicate back to VSA that the VMs have been quiesced.

5. VSA will back up the virtual machines to CommVault protected storage.

6. If configured the virtual machines will be indexed for granular browse and recovery of objects in the

virtual disks.

7. VSA will then communicate back to the hosting virtual application that the backup process has

completed.

8. The VMs snapshots will then be released.



The following diagram illustrates the VSA software snapshot and backup process in a

VMware environment using a VSA proxy server.

Hypervisor and VSA Architecture

Depending on the hypervisor application various methods can be used to deploy the VSA agent.

VMware & VSA

When protecting VMware environments different Transport Modes can be used to move VMs to protected

storage. There are three primary Transport Modes that can be used:

SAN Mode

Hot Add Mode

NBD (Network Based) Mode

Each of these modes has their advantages and disadvantages. Variables such as physical architecture, source data

location, ESX resources, network resources and VSA proximity to Media Agents and storage will all have an

effect on determining which mode is best to use. It is also recommended to consult with CommVault for design

guidance when deploying Simpana software in a VMware environment.



SAN Transport Mode can be used on a VSA proxy with direct access to snapshot VMs in the source storage

location. This mode can provide a major advantage regarding performance and load reduction on the ESX server.

Virtual machines will be backed up through the VSA and to the Media Agent. If the VSA is installed on a proxy

server configured as a Media Agent with direct access to storage, LAN-Free backups can be performed. This

eliminates data movement through the ESX server and if there is a LAN-Free path to storage, data traffic over the

network is eliminated.

The following diagram illustrates the ability to use a VSA proxy using SAN Transport

Mode when protecting VMware environments. This allows the backup process of virtual

machines to be conducted on the proxy server eliminating the load on the ESX servers.

If the VSA has direct access to protected storage installing a Media Agent on the proxy

will provide LAN-Free backups.

Hot Add Mode uses a virtual VSA in the VMware environment. This will require all data to be processed and

moved through the VM on the ESX server. Depending on the storage target the Media Agent can also be installed

on the virtual machine. Some disk storage and tape libraries in SAN environments cannot be zoned to virtual

machines. This configuration would require data to be moved from the virtual VSA to a physical Media Agent

during data protection jobs.

In certain environments with enough processing power on ESX hosts and a need to consolidate physical hardware

using a virtual VSA method could be used. By implementing this method with client side deduplication

bandwidth consumption will be greatly reduced after the initial protection of virtual machines. This method will

require all data blocks to be hashed and processes on the virtual VSA proxy which will require significant CPU

and memory resources. To reduce memory and disk requirements a dedicated LAN based Media Agent can be

used for the deduplication database.



The following diagram shows Hot Add Mode VSA proxy being installed as a VM. This

method will require all protection processing to be conducted on the virtual machines

placing the load on the ESX server.



NBD Network Mode will use a VSA proxy installed on a physical host. VSA will connect to VMware and

snapshots will be moved from the VMware environment over the network and to the VSA proxy. This method

will require adequate network resources and it is recommended to use a dedicated backup network when using the

NBD mode.

The following diagram illustrates the NBD Transport Mode using a physical VSA proxy

to move VM data over the network to protected storage.



Microsoft Hyper-V VSA

Microsoft Hyper-V allows the VSA to be installed directly on the hosting server. Data is processed and moved to

a Media Agent. If the Hyper-V server has direct access to protected storage, a Media Agent can be installed to

provide LAN-Free backups.

The following diagram shows the VSA being installed directly on the Hyper-V physical

server.



Xen Server VSA

The VSA agent is installed on a dedicated virtual machine hosted on the Xen server. Data is processed by the

VSA and moved to a Media Agent.

The following diagram shows the VSA installed on a virtual machines in the Xen

environment.



Hardware Snapshots with SnapProtect

The Simpana v9 SnapProtect feature provides integration with hardware vendors or Simpana‘s Continuous Data

Replicator (CDR) to conduct, manage, and backup snapshots. This technology can be used to snap VMs at the

data store level and back them up to protected storage.

The process for protecting virtual machines is similar to performing snapshots with the VSA agent directly

interfacing with the hosting hypervisor application. VSA will first quiesce the virtual machine and then the

SnapProtect feature will use vendor API‘s to perform a hardware snapshot of the data store. The data store will

then be mounted on an ESX proxy and all VMs registered. The VMs can then be backed up and indexes

generated for granular level recovery. The snapshots can also be maintained for live browse and recovery. The

backup copies can be used for longer term retention and granular browse and recovery.

The following diagram illustrates SnapProtect and VSA integration. VSA will

communicate with the hypervisor to quiesce VMs that will be protected. After the VMs

are in quiescent state the SnapProtect feature will initiate a hardware snapshot by

communicating with hardware through APIs. Once the snap process is complete the

ESX proxy will mount the snap and the VSA agent will backup VMs.



Using the VSA and SnapProtect agent provides a high availability, disaster recovery, and data recovery solution.

Specific configuration and hardware are required to implement this solution method. For more information on

SnapProtect configurations and VSA see the SnapProtect chapter.

Application Data on Raw Device Mapping (RDM) Volumes

When the VSA agent protects VMware virtual machines it can perform disk, volume, or file level software

snapshots of VMDK files. It will not protect any volumes using RDM. This can be used as an advantage when

designing solutions for protecting large databases. A VSA agent will be used to snap and backup the virtual disks

as VMDK files but will skip RDM volumes. An application agent can then be installed in the VM and subclients

can be configured to protect databases on RDM volumes. The application iDataAgent will provide

communication to provide consistent point-in-time backups of application data.

Configuring the Virtual Server Agent

Once the Virtual Server Agent is installed on the physical or virtual host, there are several components that need

to be configured:

Instances are used to connect to the virtual environment. Depending on the hypervisor application,

different instance options will be available.

Backup Sets are used to define how virtual machines will be discovered and managed. The available

options will be based on the hypervisor application being used.

Subclients are used to define which virtual machines will be protected and depending on the hypervisor

application different subclient settings will be available.

Instances

When the Virtual Serve Agent is initially installed, instances will have to be configured. The VSA can be

configured with different instances to manage multiple virtual environments through a single master VSA client.

Using a master VSA will provide greater flexibility and simplified administration in large virtual environments.

One or more instances can be configured for Hyper-V, Xen, or VMware. For VMware the instance can be

configured for VCenter or an ESX host. Multiple instances can be defined for each of the three hypervisors.



The following diagram shows three VSA instances. Two instances are for VMware

VCenter and the third is for Hyper-V.

Backup Set

The backup set is used to configure the discovery methods for virtual machines. For VMware it can also be used

to select vStorage or VCB for protection types depending on the version of VMware being used. By default the

protection mode will automatically be detected. This process will first attempt to use vStorage APIs and will fail

back to VCB if vStorage is not available.



Backup sets can be configured for VMware, Hyper-V and Xen. Depending on the

hypervisor defined in the instance specific options will be available in the backup set

properties.



Discovery Rules for VMware

For VMware discovery rules can be configured based on how virtual machines will be grouped when configuring

subclients. When a discovery rule is selected an Auto Discover tab will be enabled in the subclient to correspond

to the rule selected. For example, if the discovery rules are set to data store affinity, the Auto Discover tab will

allow the selection of specific data stores the subclient can use when discovering and protecting virtual machines.

Depending on the VMware infrastructure and methods used to protect VMs, proper configuration of discovery

rules and subclients will provide greater scalability and backup performance.

In the following example the SnapProtect feature is being used to mount data stores to

back up virtual machines. A subclient is used to define VMs from different data stores

requiring all data stores to be mounted prior to VM backup operations. This design can

have a negative impact on backup performance and may degrade performance in the

production environment.



This illustration shows multiple data stores, each defined in a separate subclient. When

a backup job runs for the subclient only one data store will require mounting.



Subclients

Subclients are used to define the virtual machines that will be protected. Virtual machines are defined within a

specific subclient by discovering virtual machines within the backup set. This is done in the Content tab by

selecting the Discover button. Virtual machines can be assigned to different subclients using the Subclient Name

drop down box. The virtual machines can also be set to Do not back up. Depending on the hypervisor

application, different methods can be used to configure subclient content for virtual machines.

The following diagram shows three subclients. The default subclient will discover and

manage any virtual machines not associated with any custom subclients. A mission

critical and an IT system subclient will be used to group and manage virtual machines.

Auto Discover for VMware

Based on the discovery rules in a VMware backup set, the Auto Discover tab will be used to determine the

source for virtual machine discovery. The Auto Discover tab can be defined with one or more sources for the

VMs. Sources such as data store affinity, ESX server affinity, or match host name by regular expressions, etc…

can be configured. Using auto discovery modes will allow VM groupings into different subclients to provide

better organization and scalability of VM protection. Depending on the VMware architecture specific modes are

recommended to provide the best overall performance. In large VMware environments CommVault professional

services should be involved to ensure proper configuration and scaling.



Data Readers

Data readers determine the number of concurrent VM backups that will run for a subclient. The default number of

readers is 1. Each virtual machine will back up as a single stream so increasing the data readers will allow

multiple VMs to be snapped and backed up concurrently. Consider disk performance, disk I/O and network

bandwidth before modifying this setting. Setting this number too high could result in poor backup performance

and may cause snapshots to fail.

The following example shows three subclients each set to use three data readers. If the

subclients are backed up at the same time, a total number of nine concurrent streams

will be used.



Use Proxy (VMware)

VMware VSA allows physical proxy servers to be used when backing up virtual machines. This provides for

greater scalability in larger virtual environments by using multiple VSA proxies to protect VMs. The subclient

option Use Proxy is used to assign a specific proxy to the subclient. This allows the CommVault administrator to

configure an entire VMware environment from a single spot when multiple VSA proxies are being used.

When a VSA agent is installed on a proxy, each proxy will appear in the CommCell console. By using a master

VSA, a single configuration point can be used to configure the entire virtual environment. This greatly simplifies

administration since a single backup set can be used on the master VSA preventing virtual machines from being

defined in multiple subclients. This is based on the CommVault coded rule that data is mutually exclusive to the

subclient in which it is defined within a backup set. If configurations were done on each VSA proxy individually

they would all contain their own backup sets which could result VMs being protected multiple time.

The following diagram shows three Media Agent / VSA proxies being used to protect

virtual machines. Three subclients are being used, each one directed to use a different

proxy.



Backup Type

For Hyper-V and Xen server all virtual machines are snapped and protected at the disk level. For VMware

protection can be provided at the disk, volume, or file level.

VMware backup type selection for disk, volume or file level can be set for each

subclient.

Consider the following before configuring this option:

Only disk level snapshots are bootable immediately after restore.

For volume level snapshots us the Filters tab to exclude volumes from backup.

File level snapshots will snap the entire volume but only back up selected files/folder. In this case it may

be preferred to use a file system agent in the virtual machine to back up just the required data.

Only virtual disk files will be protected with the VSA backup. Raw Device Mapping (RDM) volumes

will not be backed up.

Transport Mode for VMware

Depending on the location of the VSA a subclient allows specific transport modes to be selected. For a virtual

VSA the Hot Add mode will be used, for a physical VSA with SAN access to snapshots the SAN mode will be

used and for a network based VSA the NBD (network) mode will be used.



The following diagram illustrates the three primary transport modes that can be

configured for a subclient. Depending on access to storage Media Agent software can

also be installed on the VSA server.

SnapProtect Operations

When integrating the SnapProtect feature with supported hardware snapshot disk technologies, the VSA,

SnapProtect and supported hardware all integrate for virtual machine protection. Select the snap engine to be used

in the SnapProtect Operations tab.

Once the hardware snap has been taken it can be mounted on an ESX proxy and backed up to protected storage.

This method is used when performing application consistent backups of Exchange or SQL virtual machines. The

proxy is specified in the Proxy ESX Server configuration box.

The Application aware backup for granular recovery option can be enabled and the option to truncate exchange

logs can also be selected to provide full application awareness and log truncation for Exchange virtual servers.

For more information on snapshots in virtual environments see the SnapProtect Technology chapter.



Enable Granular Recovery During the backup of the virtual machines, indexes can be generated from disk metadata. This allows for granular

browse and recovery of objects within the virtual machine. The option Enable Granular Recovery in the

Advanced Backup options is used to determine if indexes will be generated. This setting is enabled by default.

CommVault recommends using the granular recovery option for all virtual machines. To provide in-place

recovery of objects into the virtual machine, a Restore Only iDataAgent can be installed on the virtual machine.

Enable Granular Recovery is used to generate indexes during backup operations of

virtual machines. This setting is enabled by default.



VSA Backup Performance

Before discussing methods for improving virtual machine backups it is important to note that CommVault can

only move data as fast as the physical environment will allow. The virtual architecture, network bandwidth, and

storage performance all play key roles in VM backup performance. Ensure that the environment is adequately

scaled to meet protection windows. Consult with CommVault prior to deploying Simpana software in a virtual

environment.

Consider the following key points as a basic starting point when addressing protection of a virtual

environment:

Does the VM require regular protection?

How long will the VM be needed for?

How often does data on the VM change?

Is the data on the VM static or dynamic?

Does the entire VM require protection or just specific data?

Should the VM be protected with VSA or agents installed in the VM?

Understanding Protection Needs

Before you start designing your virtual protection strategies you first need to know what it is your protecting and

what type of protection is needed. Details of each virtual machine should be documented. A strong Change

Management policy is essential, and though IT administrators may dread the enormous amount of documentation

they must create and maintain, this information can greatly affect your protection strategies.

To properly inventory your virtual environment, consider different virtual machines and the functions they

provide. Determine if servers are static or dynamic. Do they provide a unique service, or are there many instances

of the same system (such as domain controllers or web servers). Determine if they are production or test and

development systems. Documenting the different services these systems provide can later be used to determine

protection strategies.

Business Function

What purpose does the virtual machine serve? Does it serve an IT function such as a Domain Controller or is it a

business system such as a document server? If it‘s a business system, what business unit owns the machine? Is it a

production, test, or development server? What other servers is it dependent on?

This information will provide guidance on whether the entire VM requires protection using VSA or just specific

data on the machine requires protection.

Example 1: If a VM approximately 20GB in size only requires protection of a folder 500 MB in size, a file

system iDataAgent may be used to protect the data. If the VM was created from a template it could quickly be

recreated. In this case the 500 MB folder is the critical data that requires protection and not the entire VM.



Example 2: A business function is running on a VM that provides a service to a department within your

organization. The VM is static and no user data is stored in the VM. In this case using the VSA to snap and

backup the VM on a weekly or even monthly basis may provide adequate protection. Using a separate subclient

to define this VM and other VMs requiring the same protection can be used to set a separate schedule using

weekly or monthly intervals.

IT Function

For IT virtual machines consider its IT function. Is it a static box where data rarely changes? Is it a redundant box

for scaling or high availability where other virtual machines provide the same functionality? If other systems

depend on the virtual machine, how critical is it that this machine is available.

Test & Development

Very often when applications are being developed in house, virtual machines are requested for testing or

development. This results in requests for machines that may be used for a short time, and then never used again.

Keeping track of who requested the machine and how long they need it for is critical in determining whether the

machine actually requires protection.

CommVault Strategies for Improving VM Backups

In most cases using the Virtual Server Agent will provide the best backup and recovery performance. When

protecting applications running on virtual servers, application agents installed within the VM can provide better

backup and restore performance as well as application consistent protection of database and log files. The

following section covers several scenarios that can be used to optimize backup performance in a virtual

environment.

VSA Protection with Deduplication and DASH Full

When using Client Side Deduplication, once an initial full backup is completed only changed blocks will be

protected. During an incremental backup, all changed blocks are copied and deduplicated on the VSA server.

During a subsequent full backup the entire VM is snapped and backed up through the VSA. Most of the blocks

will already exist in storage so network bandwidth and storage requirements will be minimal. However, the entire

VM will have to be processed by the VSA. This will require each block for the VM being hashed and compared

in the deduplication database. A DASH-Full can be used to eliminate the snap and deduplication process on the

VSA.

A DASH-Full is actually a Read Optimized Synthetic Full backup. A traditional Synthetic Full would read

backup chunks, verify the chunk and write it back to storage in a new location. With deduplication, reading and

writing chunks is an unneeded step. Since the data blocks for the VM already exists in storage they would be

discarded during the Synthetic Full operation. A DASH-Full updates record information in the deduplication

database and generates a new index file to signify the start of a new cycle without actually reading the data. This

can significantly reduce backup times when compared to traditional full or synthetic full backups.



The following diagram illustrates using deduplication and DASH Full backups to

greatly reduce backup windows and data movement. Once the initial full backup is

done, only incremental backups will be run on production data, and DASH Full

backups will be used to consolidate cycles for retention and aging purposes. This

method provides the ability to protect large amounts of data in very short protection

windows.



DR Protection Using DASH Copy

A primary advantage of server virtualization is the hardware consolidation of data centers. This also makes

disaster recovery hot sites more practical. New features in Simpana 9 provide the key components to provide a

complete end to end DR solution. DASH-Copy provides the ability to selectively copy deduplicated data between

site locations which dramatically reduces bandwidth required to copy data to an alternate site. This operation is

more efficient than traditional site replication because only required data blocks at the DR site are copied. This is

done by configuring secondary copies and using subclient Associations to copy only relevant data to the DR site.

In addition to this functionality, separate retention can be configured for each site.

The following diagram shows that using deduplication and DASH copies can provide

for a sound disaster recovery solution. Once the initial full is copied to the off-site

location, only change blocks will be copied during the DASH copy operations.



Stagger Schedule Subclients

In large virtual environments, hundreds or even thousands of virtual machines may require protection. This can

make it impractical to meet backup windows. Spreading the backup windows for full and incremental backups

over a longer time period can help meet operation windows. To do this create multiple subclients and set different

schedules for each subclient to spread full and incremental backups throughout a backup cycle.

The following diagram shows seven subclients being used to stagger schedule backups

during a weekly cycle. A full backup will be conducted for each subclient based on the

different days of the week. Incremental backups will be conducted on the other days of

the week.

Saturday

Sunday

Monday

Tuesday

Wednesday

Thursday

Friday

SAT SUNFRIVSA

Agent

Subclients TUE WEDMON THU

FULL

FULL

FULL

FULL

FULL

FULL

FULL

INCINC INC INC

INCINCINCINCINCINCINC

INCINC

INCINCINC

INCINCINC INCINCINC

INCINCINCINCINC

INC INC INCINCINC

INCINC

INCINC

INCINC

INCINCINC INC

Schedule



Using Multiple VSA Proxies with VMware

In large VMware environments, several VSA proxies can be used to load balance virtual machine backups.

Installing VSA on multiple Media Agents will allow more virtual machines to be simultaneously backed up.

Careful planning is required based on disk performance to determine how many virtual machines can be snapped

and protected at any given time. With Simpana 9 all virtual machines and VSA proxies can be assigned from a

master VSA in the CommCell Console. This allows large environments using multiple proxies to be configured in

a single location. Each subclient can define its own virtual machines and a different proxy can be configured for

each subclient.

The following diagram shows three Media Agent / VSA proxies being used to protect

virtual machines. Three subclients are being used, each one directed to use a different

proxy.



Using an Application iDataAgent

Application agents in virtual machines can be used in certain cases to provide better backup and recovery

performance. An application iDataAgent can be used to provide database and log backups where a VSA agent

would backup the VM in its entirety.

To limit the amount of data transmitted over the network and storage requirements for duplicate blocks, client

side deduplication can be used. Using application agents within the VM will allow full database and log backups

to be conducted based on RPO and RTO requirements. A DASH-Copy can be used to copy deduplicated data to

an off-site location for disaster recovery purposes.

The following diagram shows the use of iDataAgents inside of virtual machines to

provide data protection. Although the VSA is a preferred method for protecting virtual

machines, using iDataAgent in special situations can provide better protection.


Protecting Virtual Environments - Education …...Protecting Virtual Environments - 165 The...

Documents

Transcript of Protecting Virtual Environments - Education …...Protecting Virtual Environments - 165 The...