White Papers

Configuring replication
26 Dell EMC SC Series: VMware Site Recovery Manager Best Practices | 2007-M-BP-V
5.9 Using application- and data-consistent frozen snapshots with SRM
There are a number of methods available for creating a frozen snapshot (replay) on SC Series storage. Once
replicated, the snapshot may be used by SRM. While some methods of snapshot creation result in crash-
consistent data contained within the snapshot, other methods may be employed that result in application or
data consistency within the snapshot. For example, Replay Manager 7.x can be used with vSphere or the
vSphere Client plug-in to create a snapshot of a datastore, or the workflow feature can be used to quiesce file
systems (if available). Using either of these methods results in a vSphere snapshot with both parent and delta
disks frozen, and the snapshot being replicated to the destination site.
Two important facts to recognize are:
The VM is replicated to the destination site in a vSphere snapshot state and should be dealt with in
one way or another to prevent the VM from running continuously over a long time in a vSphere
snapshot state.
The application and data consistency are contained within the frozen parent virtual disk and crash-
consistent data is contained within the delta virtual disk.
When the SRM recovery plan workflow is carried out, SRM registers the VM into inventory at the destination
site and powers on the VM with no special attention given to the current snapshot state of the VM. This
means that SRM will power on the VM using the delta resulting in recovery from a crash-consistent state. In
order to recover the VM from the frozen parent disk with application and data consistency, the VM must be
reverted to the previous snapshot using the vSphere Snapshot Manager before it is powered on. Once this is
done, the snapshot can be deleted (closed) and the VM can be powered on. This process ensures the VM is
powered on from its frozen parent disk and the delta disk along with the crash-consistent data in it is
destroyed.
If manually carrying out the previous process on a large scale, this can quickly erode efforts made toward
meeting the recovery plan RTO and is not the best use of SRM. In such instances, a more efficient and
consistent solution would be to script the snapshot management process using PowerShell and have that
process carried out as a pre-power-on, or potentially a post-power-on, step for the VM. Custom recovery
tasks are discussed in section 5.10.