White Papers

Additional resources
19 Dell EMC SC Series: Disaster Recovery for Microsoft SQL Server Using VMware Site Recovery Manager | CML1018
using the latest frozen snapshot. Consider the following before using the active snapshot with asynchronous
replication:
• Writes are queued up to be replicated in write order. However, if replication gets behind, it can
consolidate multiple writes to the same logical block address (LBA) so that only the latest version of
the LBA is sent. This type of write consolidation can prevent the successful recovery of SQL Server
databases. The risk of this type of recovery problem is low when there is sufficient bandwidth
between data centers to prevent replication from falling behind. To eliminate this risk, recover from a
frozen snapshot.
• Since each volume is replicated independently, it is likely that the active snapshots of the transaction
log and data volumes will be at different points in time at the target site. While the SQL Server crash
recovery mechanism is very good, there is a risk that the database recovery will fail if the data and
transaction log volumes are too far out of sync with each other. Recovering from frozen snapshots will
help minimize this risk. However, when using frozen snapshots, there is a slight risk that the latest
frozen snapshots on a given set of volumes won't be from the same point in time. This risk is low if
there is sufficient bandwidth between sites. This risk can be eliminated by placing all database files
for a given database on the same volume. Be sure to consider the implications of putting all database
files on the same volume.
4.4.2 Recovery from the latest frozen snapshot
For volumes replicated asynchronously, using the latest frozen snapshot is the recommended recovery
method. In particular, this method is ideal for database volumes when combined with application consistent
snapshots created by Replay Manager. The recovery procedure will vary based on how the snapshot was
created.
Since each volume is replicated independently, there is a risk that the latest frozen snapshots for a given set
of replicated volumes will not be from the same point in time, even if snapshots are taken at the same time on
the source volumes. This risk is low if there is sufficient bandwidth between sites. This risk can be eliminated
by placing all database files for a given database on the same volume. Be sure to consider the implications of
putting all database files on the same volume.
4.4.2.1 Using snapshots created by the VMware backup extensions in Replay Manager
When recovering from snapshots created by the VMware backup extensions, the virtual machine will need to
be rolled back to the VMware snapshot created by Replay Manager.
For manual recovery, configure the recovery plan for the virtual machine to leave the virtual machine powered
off. After SRM recovery is complete, use the vSphere Snapshot Manager to revert the virtual machine back to
the snapshot created by Replay Manager. Once that has been done, power the virtual machine on.
For automated recovery, configure the recovery plan to power the virtual machine on. Create a recovery step
to run the following PowerShell cmdlets before the virtual machine is powered on:
# Assign Variables
$vCenterDnsName = "<vCenter DNS Name>"
$VmName = "<Virtual Machine Name>"
# Load PowerCLI
Add-PSSnapin VMware.VimAutomation.Core