Why Site Recovery Manager Dominates Our DR Discussions

By Christian Lappin, Senior Sales Engineer, TierPoint

I often discuss how too much virtualization creates risk in your environment. Virtualization, however, can also play a vital role in your ability to recover from a data disaster. In fact, virtual machine (VM) management has become one of the key elements in a disaster recovery (DR) solution. Done successfully, you get improved recovery speeds, a more effective testing environment, and many other benefits that maximize your infrastructure’s availability.

To manage VMs for DR, many of our customers use a site recovery manager (SRM) from vendors including VMware and Zerto. SRMs allow you to easily manage all of your Virtual Infrastructure (VI) recovery in the event of a disaster. In hybrid cloud environments, SRM manages the synchronization of your Virtual Center data (guest VM configurations) between the primary and backup site. SRM is also important because it provides role-based access control, audit trails and the ability to export your recovery plan.

SRM dominates a lot of our conversations today because it increasingly integrates with more software and hardware, making it more powerful while providing more flexibility to customers who have different requirements. The other reason it comes up is because customers want to discuss whether they want to manage SRM themselves or outsource that responsibility. Companies like TierPoint can manage customers’ SRM either in a cloud environment or a colocation scenario. To make that decision businesses have to weigh the time and staffing requirements as well as costs. Part of your decision process for selecting a cloud provider or other managed service provider (MSP) needs to include a discussion about operating SRM.

SRM Requirements
SRM, by itself, will not protect you from every disaster challenge. You need to be virtualized already, or at least the workloads you want to protect need to be. Licensing can be complicated when you have to account for both SRM and your VMs.

To make SRM work, you will need a few other things too. These include:

  • A Virtual Center license or similar at both the primary (protected) and recovery sites
  • An ESX Server license or similar at both sites
  • A database for SRM data at both sites
  • Disk space / buffer for replication in addition to space for needed utility machines to get this all working

It used to be that you needed the same brand of hardware to replicate between sites. SRM is storage vendor-neutral now. Users love this because it drives down complexity and potentially costs. It also makes it easier to exchange data between clouds and your data center. Similarly, SRM does not care what kind of storage it replicates to, whether it is NFS, or iSCSI, etc. From a DR plan design perspective, the storage vendor you use is no longer a concern.

Failing Back
SRM also helps you do something that is often overlooked as part of a DR plan: failing back. Say your primary production data center is flooded. When the data center goes down, there is automatic failover to a backup site. What happens when your primary location is ready to come back online? SRM can also help you restore the primary site and let the backup site return to being a backup. Your DR plan is not complete without a plan to enable fail back.

SRM is only one of the layers of a DR plan, but it really showcases the power of virtualization, which is funny since I am always talking about how virtualization creates risk. It is important though that anyone creating a DR plan factor the role SRM can play in it.