vStorage APIs for Data Protection (VADP) introduces several benefits over the
VMware Consolidated Backup (VCB) method of protecting virtual machines.
There
are several requirements that must be met for VADP to function correctly. This
document covers those requirements for both the Virtual Server
iDataAgent and
VMware infrastructure.
The three methods utilized by VADP to transport backup data are defined here.
SAN – Data is read directly from the storage where virtual machines
reside. This is also referred to as LAN-free since no data is transferred
over the network. The LUN(s) containing the virtual machine disks must be
visible to the Virtual Server iDataAgent server to support SAN mode backups.
SAN mode is supported when utilizing fiber and iSCSI storage.
Hot-Add – The Virtual Server iDataAgent
is installed on a virtual machine residing on an ESX Server. Hot-Add mode
can achieve close to SAN mode performance if SAN is not available. The term
Hot-Add refers to the way the backups are completed. In Hot-Add the data
volumes containing the virtual machines to be included in the backup are
automatically mounted to the virtual machine.
NBD & NBDSSL - NBD (network block device) & NBDSSL (encrypted NBD)
transmit data over the ESX Servers' TCP/IP connection. This can be the
production network or a dedicated backup network.
Refer to the
Configuring Transport Modes topic for additional information and
instructions on configuring transport modes.
The vCenter server and all ESX Servers should be at vSphere 5.0, 5.1, 4.1 or 4.0
update 2 if possible. Should update 2 on 4.0 not be available, then a common
user must be created on the vCenter server and all ESX Servers to avoid vmx file
download issues.
VMware ESX Server Level - ESX(i) servers must be at version 4 or above.
Disk Types - Independent disks and Physical RDM’s are not supported.
Virtual RDM’s are supported.
Prior to performing any backup or restore operations ensure the port
requirements listed below are met.
Virtual Center
Ports for web service (default: 443) and TCP/IP (default: 902) must be
opened. Should vCenter be configured to use non-default ports these must be
opened.
ESX Server
Ports for web service (default: 443) and TCP/IP (default: 902) must be
opened for the vStorage APIs for Data Protection.
Change Block Tracking (CBT) must be enabled to support VADP backup. The
Virtual Server iDataAgent agent will automatically check and enable CBT at the
time of backup. Virtual Server iDataAgent may not be able to enable CBT for
cloned and migrated virtual machines. CBT can be checked by following the steps documented in
the following VMware article: http://kb.vmware.com/kb/1020128
A dedicated account can be used for performing backups on vCenter/ESX Server. The
predefined VCB backup role can be copied and modified to perform VADP Backups.
This role will require several additional permissions which are listed below.
This account only needs to be created in the event that a restricted account is
desired.
Restores are typically performed using the admin/root account. However a
dedicated account can be created for this purpose. This account requires
additional permissions over the account used for backups.
The Virtual Server iDataAgent can be installed in several ways to suit
environmental needs and resources. Additionally, VADP installations now
include VDDK (Virtual Disk Development Kit); no separate installation of this
package is required.
The following sections describe frequently used deployment scenarios:
In this configuration, the Virtual Server iDataAgent and MediaAgent are
installed on a a physical server for SAN only backups with no data transferred
over the LAN. A pure physical implementation will often provide the best
performance and requires physical hardware with visibility into the storage
network.
When to Use
Data Stores are configured on FC or iSCSI SAN (No NFS).
Able to provide Physical Windows server with SAN access to Data Store
LUNs
Direct tape copies are required or physical MAs required for secondary
operations.
When NOT to Use
SAN access to Data Store LUNs from outside ESX Server environment is not
possible.
In this configuration, the Virtual Server iDataAgent and MediaAgent are both
installed in Hot-Add mode. The backup destination is typically network based (CIFS/NFS)
or another vmfs datastore and tape out options are very limited. Shared storage
is required for HotAdd mode backups of virtual machines living on other ESX
Server hosts.
When to Use
All virtual environment where physical servers are not preferred.
Data Stores are configured on NFS.
Each MA can write directly to a mount point presented to the virtual
machine
Able to segregate backup and production traffic on the network.
When NOT to Use
Direct backup to tape is required. Backup traffic cannot be segregated
from production traffic.
In this configuration, the Virtual Server iDataAgent is installed in hot-add
mode while the MediaAgent is installed on a physical computer. Data is therefore
transferred over the LAN to the physical MediaAgent. This model also allows for
the use of a centralized and Linux MAs. Shared storage is required for Hot-Add
mode backups of virtual machines living on other ESX Server hosts.
When to Use
Direct backup to tape or SILO to cloud is required.
Segregation of backup and production data is possible.
Physical MA is required for other protection tasks and secondary
operations.
When NOT to Use
Segregation of backup and production data is not possible.
SAN based DataStores on FC or iSCSI are in use. (use all physical
configuration)
In most environments, the initial configuration of the Virtual Server
iDataAgent will include configuring
backups of the vCenter. The following sections provide details specific to configurations in VADP
environments.
During
backups, the Virtual Server
iDataAgent creates a snapshot of
the virtual machine data directly from the datastore. The snapshot is then
moved directly to the storage media without requiring any dedicated disk
cache on the proxy server. In the case of incremental backups, Change
Block Tracking (CBT) helps quickly identify the data blocks on the virtual
machine that have changed since the last backup.
Similarly, during restores, virtual machines are restored directly to the
appropriate ESX Server and datastore without the need for staging on the proxy
server with VMware Converter. This capability provides for much faster restores.
You can also perform backup operations from an environment wherein both
technologies exist. To accomplish this, simply ensure the following components
are installed on the proxy computer:
VMware Consolidated Backup (VCB)
vSphere VADP
the Virtual Server
iDataAgent
Once these components are prepared, backups will leverage between VCB and
vSphere as appropriate.
The vStorage API can be used to restore backups performed with VCB. The
backup data will first be staged to the proxy and then vStorage will perform the
restore.
Regular backups should be performed on the default subclient. This will
ensure new virtual machines are discovered on a regular basis along with the
backup operation.
Creating one virtual machine per subclient is not recommended. This
creates issues around scheduling and becomes unmanageable in larger
environments.
Typically only the default Subclient will be used in most deployments
except in the following cases:
Multiple Agents are deployed in the environment and the ‘Master’
model will be in use. (See the
Master Agent Configurations section.)
Multiple Storage Policies are required for different virtual
machines.
Rule-based discovery is in use and different subclients will be used
to target a particular affinity.
When multiple Virtual Server iDataAgents are in use a single Agent can be
configured to control and coordinate the activities of all other proxies. This
Agent is referred to as the Master Agent and all subclients are created on this
client while the actual backup operations are offloaded to other proxies. This
will allow all activities to be coordinated from a single interface and reduces
the possibility of double backups and/or missed guest machines.
Create the subclients on the Master Virtual Server iDataAgent. These can be
automatically populated by leveraging one of the automatic discovery
options or manually configured.
On the General tab of each subclient properties page select the
‘Use Proxy’ dropdown box and select the desired Virtual Server
iDataAgent. Leaving the box
blank will default to the proxy the subclient is being created on.
Although the Virtual Server iDataAgent agent needs to be installed on all of the
proxies, you should only configure 1 instance on the “master Virtual
Server iDataAgent”
server. The other proxy machines do not need to have an instance
created.
A container level restore restores the entire virtual machine disk. Refer to
Getting Started -
VMware Restore for the steps required to perform this restore
following your first full backup.
Files and folders can also be restored from a virtual machine backup. The
Advanced - VMware
Restore topic includes information on the different restore types
available.
Using the Virtual Server iDataAgent in HotAdd mode Configurations
While deploying the Virtual Server iDataAgent, install the software on a
datastore with the largest VMFS block size. This is necessary to ensure that
the Virtual Server iDataAgent can mount and back up virtual machines
residing on all datastores.
Helper virtual machines are not required for Hot-Add Virtual Server
iDataAgent servers utilizing VADP.
Upgrading the Virtual Server iDataAgent from Version 8.0.0
VDDK 1.2 is installed to the Base folder with the Virtual Server iDataAgent.
Software version 8.0 Virtual Server iDataAgent machines that were upgraded to v9
will need to have the Virtual Disk Development Kit registry key that was
manually created during the installation of VDDK 1.1 deleted. Failure to do so
will result in the VDDK 1.1 to still be utilized or fail if it has been
uninstalled. (VDDK 1.1 does not support HotAdd mode on ESX 4.1)
Using vStorage API
The vStorage API can be used to restore backups performed with VCB. The
backup data will first be staged to the proxy then vStorage will perform the
restore.
Backups performed using the vStorage API cannot be restored through the
VMware converter. Converter does not understand the format of vStorage.
Change Block Tracking
When Change Block Tracking is unavailable backups will revert to CRC to
determine changed blocks. Since the Virtual Server iDataAgent needs to read the
entire virtual machine disk, CRC incremental backups may take almost as long as
full backups. However, the amount of data transferred and stored by an
incremental backup is limited to the changed blocks within the virtual disk.
Correcting CBT on the problematic virtual machine is recommended as quickly as
possible to take full advantage of VADP based incremental backups. Tools are
available to check the correct installation of the VDDK and for verifying and
correcting CBT issues. Contact your Software Provider for information on these
tools.
Supported vCenter Converter Version
VMware vCenter Converter Standalone 4.3 no longer supports VCB sources
for restores. Version 4.0.1 must be used.
Fault Tolerant VM’s are not supported for snapshot operations and cannot
be backed up.
The SnapProtect™ backup enables you to create a point-in-time snapshot of the
data to be used for various data protection operations.
SnapProtect backup works in conjunction with software and hardware snapshot
engines to provide snapshot functionality for data protection operations. A
dedicated ESX Server can be used for selective copy to tier 2 storage. This
completely removes any utilization on the ESX Server farm. Granular Recovery can be
performed at this stage for individual file and folder recovery.
A dedicated account can be used for performing backups on vCenter/ESX Server. The
predefined VCB backup role can be copied and modified to perform VADP Backups.
This role will require several additional permissions which are listed below.
This account only needs to be created in the event that a restricted account is
desired.
Restores are typically performed using the admin/root account. However a
dedicated account can be created for this purpose. This account requires
additional permissions over the account used for backups.
Ensure that the array information is entered in the same format that is
presented to the ESX server. (for example – should storage be presented
by IP to the ESX servers it must also be entered by IP in Array
Management)
A container level restore restores the entire virtual machine disk. Refer to
Getting Started -
VMware Restore for the steps required to perform this restore
following your first full backup.
Files and folders can also be restored from a virtual machine backup. The
Advanced - VMware
Restore topic includes information on the different restore types
available.
It is recommended that the Virtual Server iDataAgent
and MediaAgent be installed on a physical computer in environments leveraging fiber channel storage (required for HDS).
Storage for iSCSI and NFS must be entered in array management in the
same format that it is presented to the ESX servers. (i.e. should storage be
connected by IP on the ESX it must entered by IP in Array Management.)
When leveraging NFS storage an entry for each IP used will need to be
entered into the array management. Entering only a single IP for a
management interface is not sufficient.
The Virtual Server iDataAgent proxy
must have access to the
storage network. If you have an isolated network, an additional network
connection must be added to the proxy.
SnapProtect will perform a full backup. When switching to or from a
SnapProtect
backup will cause the next backup to be a full backup.
