SharePoint 2013, 2016 and 2019 Architecture for a Failover Environment

There are two ways to set a failover SharePoint environment. This is also known as SharePoint disaster recovery plan. In case your farm goes down, you should have options to make it up in few seconds, minutes, hours or days depending on the approach which you select. There are three types of standby plans in SharePoint. The time and immediate effort to get a replacement farm up and running defines the standby type.

1. Cold standby. A secondary data center that can provide availability within hours or days.
2. Warm standby. A secondary data center that can provide availability within minutes or hours.
3. Hot standby. A secondary data center that can provide availability within seconds or minutes.

Here we are discussing the Hot standby plans. The first approach, I consider it Hot standby because it immediately shifts to the secondary node of SQL for the desired database in few seconds only without engagement of any team member i.e. SharePoint, SQL or Network guys. This is less expensive method of standby. All you need is another SQL server for high availability. This method is now replaced by Always On availability groups. However previously mirroring was the only effective method in my opinion. The draw back for this method is, this is just the failover for SQL database. If all of your servers (SharePoint + SQL) resides on the same data center and disaster happens, the chances of recovery is minimized. Also, if any layer in the farm, i.e. Web Servers or App Servers are down, there is no backup for those servers in the farm.

However, the second standby approach takes a bit more effort to build and maintain, but its very effective. It could also take a few more minutes and need some resources from SharePoint + other teams to bring SharePoint back online for end users. The end users will have a continues delivery of services without facing any downtime.

1. Set a failover DB server

2. Build a hot standby SharePoint Farm

Set a Failover DB Server

• Only one SharePoint farm.
• Require an additional DB server along with a witness sql server.
• It uses Database mirroring and only DB level backup exists in case of failure.
• If any WFE or APP server get down or offline, you'll need to build that server again or fix the problem which may effect the traffic and have a downtime of hours or days, depending on the problem.
• This approach can be used where you can buy time from client or users in setting up the farm.
• Can take from minutes to days to recover from any outage.

Ref: https://technet.microsoft.com/en-us/library/dd207314(v=office.14).aspx

Hot-Standby SharePoint Farm

• Using AlwaysOn SQL feature (Enterprise version only).
• Consists of two parallel SharePoint farms.
• Requires equal number of servers with same roles in secondary farm as in primary farm. (as best approach)
• All custom installations must be done on both farms.
• Farm level DB and file system backups exists in case of failure.
• Easy to switch on secondary farm in case of expected/unexpected outage.
• In case any server in primary farm get down or offline, users can be switched to secondary farm immediately by changing IP's in DNS(slow process) or in NLB(fast process).

Ref: http://blogs.msdn.com/b/sambetts/archive/2013/10/11/hot-standby-disaster-recovery-sharepoint-farms-basic-setup-amp-failover-high-availability-sharepoint.aspx