We have really struggled with our Disaster Recovery processes for our SharePoint farm. I would appreciate any input on improving our current processes. Here is the technology that we're currently using in hope of accomplishing what Microsoft calls a "warm-standby" farm for DR.
- We have two datacenters. A primary and a secondary.
- Our SharePoint databases are leveraging SQL Always On groups and asynchronously replicating from our primary datacenter to our secondary datacenter. The Always On groups are utilizing a Windows Cluster.
- Our SharePoint WFE and APP servers are virtualized and use SAN storage. The LUN that contains the WFE and APP server data is replicated from our primary data center to our secondary data center.
With that said, our plan in the event of a DR situation would be something like this ...
1) Create VM's at DR for the WFE and APP servers. Attach the replicated LUN. 2) Boot the VM's without a network connection. 3) Assign networking information to VM's...Ip addresses and subnetting. 4) Restart VM's with network connection. 5) Run script to make the database at DR the primary database.
I realize this a very simple overview of the process, but I am concerned about a couple of things here. Does Microsoft support this LUN replication for the WFE and APP servers? My understanding is that if your using some sort of VM replication of snapshot technology your config database must be taken into consideration at all times because it is very easy to break your whole farm by incorrectly restoring a VM 'snapshot' and/or restoring the config database. Would it not be easier and more reliable to build new app and wfe servers at DR in the event of a DR situation and then attach the config database that is being asynchronously replicated to DR by SQL Always On?
Any information in general on how we can achieve a 'warm-standby' with the technology mentioned above would be excellent. We are aiming for a 4hr RPO and a 48 hour RTO.