VMware vSphere Data Protection (VDP) VDP is a robust, simple-to-deploy, disk-based backup and

recovery solution. VDP is fully integrated with VMware vCenter Server and the VMware vSphere Web
Client. VDP enables centralized and efficient management of backup jobs while storing backups in
deduplicated destination storage.

Q: What happens if rollback doesn't work?

If a rollback fails, then deployment of a new VDP appliance is required. Migrating configuration and
backup data from one appliance to another is not supported in VDP 5.1, this functionality was added in
VDP 5.5.

Backup

Q: If I create a backup job during the backup window, will it start backing up
immediately?
No. The backup jobs are scanned at the start of the backup window. If the job does not exist at
this time, it will not run. It will be scheduled to automatically start at the next backup window.
However, you can manually start a backup job during the backup window.

Q: Can I schedule backup jobs to run at different times?

In VDP 5.1.x, there is only one backup window per VDP appliance. The backup jobs are run
during this backup window. It is not possible to create separate backup windows for each backup
job. When creating a backup job, it is possible to define how often the backup runs. For example,
daily, weekly, or monthly.
In VDP 5.5, it is possible to define a scheduled time per job. For more information, see the
Specifying the Backup Schedule section of the vSphere Data Protection 5.5 Administration
Guide.

Q: How many backups can run in parallel?

Each VDP appliance can simultaneously back up a maximum of eight virtual machines.

Q: My backups are taking too long, what can I do?

If the requirement is only to protect the data, the administrator can select only the virtual
machine disk containing the data, which helps minimize backup capacity consumption. For more
details, see the Backup section in the vSphere Data Protection Overview guide.

Restore

Q: Am I able to do a file-level restore (FLR) of my Linux virtual machines?

The file-level restore is web-based, so a supported web browser is required. At the time of
writing, a command-line FLR is not available.
Q: Are there any prerequisites to use the FLR?
A web browser is required to connect to the VDP appliance. VMware Tools must also be
running within the virtual machine where the file-level restore is occurring.

Q: Am I able to restore a backed-up virtual machine's virtual disk to different datastores?

It is possible to restore a virtual machine to a datastore other than the original. However, all files
that make up the restored virtual machine are restored to the same datastore.

Q: Can I perform a Restore Rehearsal, as I used to do in VDR?

Yes, restore rehearsal functionality is available in the VDP 5.1.10. For more information, see
the vSphere Data Protection 5.1.10 Release Notes.

Challenges to Using VMware Clusters With Shared Storage

In a traditional failover cluster, two or more physical servers (cluster nodes) are connected to a
shared storage system. The application runs on one server, and in the event of a failure,
clustering software, such as WSFC, moves the application operation to the standby server. It is
possible to do this with virtual machines (VMs) in a vSphere environment, but this requires a
special configuration for the storage that can limit the ability to use important features in vSphere
such as vMotion and VM Cloning.

A typical WSFC cluster in vSphere utilizes a storage configuration technique known as raw
device mapping to connect VMs directly to the storage area network (SAN). Raw device
mapping makes a physical storage device or subsystem appear to the guest operating system as if
it were a virtual disk file in a VMware Virtual Machine File System (VMFS) volume. Such
mapping enables the use of specialized SAN SCSI commands needed to support HA clustering,
making virtualized storage access seamless to the operating system, the clustering software, and
the applications.

The problem is a failover cluster that uses raw device mapping complicates or prevents the use of
several important VMware features that employ virtual machine disk (VMDK) files. For
example, raw device mapping prevents the use of VMware snapshots, which then prevents the
use of every feature that requires snapshots, such as Virtual Consolidated Backups (VCBs).

Raw device mapping also complicates VM mobility, which creates impediments to using the
features that make server virtualization so beneficial, including converting VMs into templates to
simplify deployment and using vMotion to optimize performance by migrating VMs dynamically
among hosts. These restrictions associated with the use of raw device mapping can undermine
the potential gains that most IT departments hope to achieve with vSphere.
Challenges Using SQL Servers Failover Clustering

SQL Server provides two of its own options for clustering: AlwaysOn Availability Groups and
AlwaysOn Failover Clustering. The former offers enterprise-class HA but also requires the more
expensive Enterprise Edition licensing. Similar robust HA protection is available for other data-
bases, such as Exchange Server Database Availability Groups and Oracle Active Data Guard. But
these premium HA solutions also come with a premium price that can make them prohibitively
expensive for many database applications. AlwaysOn Availability Groups, similar to many other
database protection techniques, protect only data stored within the actual database. Files outside
the SQL database are not protected. In contrast, AlwaysOn Failover Clustering, used in
conjunction with storage mirroring technologies, protects all application data.

The Failover Clustering feature in SQL Server Standard Edition works with Microsofts WSFC
to provide automatic and seamless failover and failback on a fully redundant configuration.
Should any server (or virtual machine) fail for whatever reason, another takes over using an up-
to-date version of the data. Seamless failover/ failback also enables software updates and patches
to be installed with minimal application downtime.

However, assuring immediate and seam- less failover requires that each instance of the
application has access to the same data. That is typically accomplished by using a single dataset
in a shared storage (SAN) configuration (which also introduces the risk of a single point of
failure).

The problem is WSFC and other failover clustering solutions require some form of shared
storage, and fully redundant, cluster-aware shared storage (e.g., SANs) can be quite expensive.
The requirement for shared storage also means being unable to provide disaster recovery across
data centers. This gives DB administrators two basic options: Use the more expensive AlwaysOn
Availability Groups available only in the SQL Server Enterprise Edition, or add cost-effective
SANless clustering software to provide real-time, guest-based block level replication that is
compatible with WSFC.

Overcoming the Challenges With Cluster-Aware Shared Nothing Storage

The popularity of VMware and SQL Server, combined with challenges involved using raw
device mapping and the high cost of Enterprise Edition, has given rise to third-party solutions
purpose-built for providing high availability and high performance more cost-effectively. Indeed,
such software-based data replication and synchronization solutions designed for the high
availability and disaster recovery needs of business-critical applications have been available
since the 1990s.
 A multi-site high-availability configuration is the only way to protect applications from
outages that affect an entire data center.

The best of these solutions use efficient, real-time replication to synchronize data across local
storage between each of the VMs in the cluster. The synchronized storage is presented to WSFC
as if it were a shared disk.

Efficient guest-based replication makes it possible to create a shared-nothing, hardware-agnostic

storage cluster in a vSphere environment without the need foror limitations ofraw device
mapping. As shown in the diagram, different VMDKs are attached to different VMs in a multi-
site N-node cluster using each VMs independent storage. Some of these solutions also make it
possible to implement LAN/ WAN-optimized block-level replication in either a synchronous or
asynchronous manner. In effect, these solutions are capable of creating a RAID 1 mirror across
the network, automatically changing the direction of the data replication (source and tar- get) as
needed after failover and failback.

These shared-nothing (SANless) clusters provide a cost-effective way to create high-availability

vSphere clusters without the need for raw device mapping or the limitations that raw device
mapping imposes. SANless clustering software is hardware-agnostic; any storage device or
subsystem is presented to the Windows operating system as a block-level device, and appears in
Windows Disk Management as a drive letter for use by any application. Most data replication
software also integrates with WSFC to enable administrators to configure high-availability
storage clusters using this familiar Windows feature, while avoiding the use of shared storage as
a potential single point of failure. Once configured, the software automatically synchronizes the
local storage in two or more servers (in one or more data centers), making them appear to WSFC
as a local or shared storage device.

In addition to high availability, most SLAs also have a requirement for high performance. And
here, too, data replication software is capable of delivering superior results, especially for highly
transactional applications such as SQL Server that require very high I/O operations per second.
Part of the performance advantage derives from being hardware-agnostic, which facilitates the
use of direct-attached storage, optionally with solid state drives, that is far faster than network-
attached storage or a SAN.

Performance is enhanced ever further by the way replication software integrates with the
Windows file system. As writes occur on the primary server, the driver, which sits immediately
below NTFS, writes one copy of the block to the local VMDK and another copy simultaneously
across the network to the VMDK on the remote secondary server. The throughput performance
achieved can be truly impressive. Testing has shown that data replication software is able to
deliver SQL Server transactional throughput far higher than with AlwaysOn Availability Group
replication and nearly as high as storage configurations not protected with any data replication or
mirroring.

Data replication software approaches can have other advantages as well. For example, those that
use block-level replication technology that is fully integrated with WSFC are able to protect the
entire SQL Server instance, including the database, logons, and SQL agent jobsall in an
integrated fashion. Contrast this approach with AlwaysOn Availability Groups, which failover
only user-defined databases, and require IT staff to manage every cluster node separately and
manually.

High availability and high performance without the high cost of SQL Server Enterprise Edition
and without the limitations imposed by raw device mappingits why data replication software
has a role to play in virtually every virtualized data center.