SharePoint Disaster Recovery

Question

I'm working on a Disaster recovery strategy for one of my clients. There are various recommended approaches like cold, warm and hot standby. I'm trying to setup a DR strategy that is similar to Hot Standby (http://technet.microsoft.com/en-us/library/ff628971(v=office.14).aspx#Section3) but it is slightly different based on the current environment of my client.

At present we have a SharePoint and database server. The SharePoint server has all the WFE and Application services running on it and DNS server is configured to the SharePoint IP address. Incase of disaster to SharePoint server (not the database server) the portal will not be available. To overcome this scenario and to bring the portal up and running in few minutes I want to have another SharePoint Server that is joined to this farm that has all the WFE, Application services, Central Administration Site and customisation on it. So when the main server is down I need to just change the IP address in DNS and the portal will be up and running once the DNS changes are propogated to computers.

Just for the sake of argument we can assume that the Database server will never crash.

Question 1: Is this a recommended approach and what are the issues with this approach?

Question 2: My client said he wanted to have a NLB and add both the servers to it so even if one fails the other will continue to work in Active-Active manner. What are the issues with this approach?

Thanks, Kannan

Answer 1

Firstly id say assuming sql wont fail is a bad starting point, while it is less likely to have issues than sharepoint, it does still happen, and the results are just as bad (if not worse) for the end user. If the company can stretch to include a 2 member sql cluster, id highly recommend it.

1: I wouldn't call this a "Best Practice" approach, but it is viable. Things to be aware of include: Some things simply can't be run on more than one server (user profile sync service) while this wont matter for short outages, any prolonged outage would see an impact. You need to ensure any file level customizations are kept in line across servers, as an example, in our environment we override the default actions for document downloads in the DOCICON.xml file. In order to keep these in sync across servers, I deploy the changes with a farm solution.

2: For the published site i would highly recommend this even without considering DR. Be aware though, that in my experience getting the central admin site to work fully on multiple boxes behind NLB, is a painful experience. Otherwise this is recommended and shouldn't cause you any significant problems. Also with this setup, you wont need to change the DNS, as it should be pointing to the NLB, instead if the NLB supports it, you can have it health check the servers, and route traffic accordingly.

Regards