Best practises for disaster recovery sharepoint farm in sharepoint 2016

Question

Is Stretch SharePoint farm support for DR high availability in SharePoint 2016 or create separate SharePoint farm in disaster recovery?

IF below prerequisites met as per Microsoft, after creating stretch farm there are any issues to farm functionality what are the pros and cons.

There is a highly consistent intra-farm latency of <1 ms one way, 99.9% of the time over a period of ten minutes. (Intra-farm latency is commonly defined as the latency between the front-end web servers and the database servers.) The bandwidth speed must be at least 1 gigabit per second.

Answer 1

Yes, you have to create a separate Disaster Recovery farm even if you have a Stretched Farm. The stretched farm is used to provide high availability, but not for disaster recovery. These are two different topics.

In short, stretched farms increase availability for endpoint & network failure for a single SharePoint farm. Disaster Recovery (DR) farms on the other hand are an independent copy of the primary farm to take over in-case something bad happens on the primary site that impacts users at all. The fact the DR site isn’t the same farm as the primary means any breaks in the primary site shouldn’t impact the DR site by design, all being well.

Stretched-farms are for high-availability but disaster-recovery farms are, well, about disaster-recovery which isn’t exactly the same thing even if the desired result is the same – to keep SharePoint users happily using SharePoint even with fatal failures in the SharePoint farm.

Reference: Stretched SharePoint Farms vs. Disaster Recovery SharePoint Farms