While SQL Server is not one of my core competencies, I have worked with clients to protect their business critical applications in a VMware environment that utilizes SRM for DR. These options rely on either Native SQL protection schemes or VMware options like SRM or vSphere Replication. There are, of course, many 3rd party options, as well, depending on the storage array in use, which I won’t go into here. While there are usually good, better, and best options, the idea I’d like to get across here is that there are many ways to protect SQL Server. They can all be used at the same time even. I’ve had clients that had so many SQL Servers, this is essentially what they did – they had to pick and choose how to protect each based on their relative importance.
SQL Server 2012 AlwaysOn Availability Groups
For the most critical SQL Servers, the image below shows the high-level view of what my clients have used with success. For server failures at the Primary Data Center, there are multiple SQL Servers. AAGs can use both an Active-Active model and an Active-Passive model with regard to where the active database resides. Continuing with the Primary Site, Node 1 can host both an Active and a Passive database. Node 2 can host an Active and Passive database, as well, working with Node 1 to perform synchronous replication. Through asynchronous replication, both databases can be replicated to the DR site, where only Passive copies reside. In the event Site A completely fails, Node 3 can be brought online.