Administrator Guide

image level recovery, or add its .vmdk disk file back to the original (or surrogate) virtual machine's virtual
inventory to perform file level recovery.
Restore Data with VSS Consistency
If data is required to be restored with VSS consistency, take the following steps for each virtual machine
being recovered:
1. Register the virtual machine in inventory.
2. From VMware, Revert to Snapshot.
3. From VMware, Delete Snapshot.
Although the Expose action requires some manual steps, it is the fastest way to recover data at both
the file and image levels while maintaining storage efficiency and while preserving the data
progression history. Experienced users of vSphere and Dell storage should use the Expose action
whenever possible to ensure the fastest recovery and most efficient use of raw storage.
Restore Action for VMware
Instead of exposing the datastore for large scale or rapid image level recovery, the Restore action
automatically deletes the existing virtual machines being restored and then restores the virtual machines
individually by using a copy operation from a View volume back to its original location. The Restore
action is only supported by the VMware Virtual Machines backup extension and is fully automated.
Because Restore is a bulk copy operation, available blocks are written to as new according to the storage
profile applied to the volume. Using the Storage Center defaults, the virtual machines are copied into Tier
1 storage regardless of where the blocks existed previously. The main benefit of this method is that it
provides automated virtual machine recovery at the expense of storage efficiency and Recovery Time
Objective (RTO).
vSphere Site Recovery Manager
VMware Site Recovery Manager (SRM) provides an automated disaster recovery solution for vSphere
virtualized datacenters. When integrated with Dell Storage Center, Replays are used by SRM to register
and power on virtual machines during the recovery process at the remote site and as such Replays
effectively represent the Recovery Point Objective (RPO) for virtual machines.
NOTE: When creating Replay Manager job schedules, RPO and expiration should always be
considered.
SRM can leverage Replays created by Replay Manager, however, the following points should be
considered to ensure that the disaster recovery design meets expectations during testing or execution of
the recovery plan:
• Replays created by Replay Manager will contain vSphere snapshots. By default, when SRM recovers
these virtual machines, they will still be in a vSphere snapshot state.
• The application and data consistency through VSS is frozen in the read-only snapshot.
• Any data written after the snapshot occurred and before the volume Replay was created will not be
application or data consistent. Rather, the data will be crash consistent.
• If the application needs to be recovered with VSS consistency, revert to the previous vSphere
snapshot and then delete the vSphere snapshot using the vSphere Client. This must be done before
the virtual machine is powered on automatically by SRM or manually through human intervention.
• If application or data consistency is not required for disaster recovery purposes, the virtual machines
at the recovery site may be immediately powered on in a vSphere snapshot state. However, it is not
advisable to allow virtual machines to continue running for extended periods of time in a snapshot
state. The vSphere snapshots for each virtual machine should be committed and deleted as soon as
possible.
76