Share via

Disaster Recovery for SharePoint 2010

  • Article

What is Disaster Recovery:

Disaster recovery is a approach which consists of the precautions/steps taken so that the effects of a disaster will be minimized and the organization will be able to quickly resume back. When one of the web application, site collection or a Web Front End goes down this does not mean it is a disaster recovery situation. DR approach Is used when the entire farm goes down. Approaches/models varies between different organization depending on cost, customizations, Recovery time, Recovery Point, size of data and other factors.

Scenario:

You have a SharePoint 2010 Farm which is running some business processes. You want to be prepared for replicate of the SP farm for disaster recovery scenarios so in case of any Disaster you can bring your farm back to online in minimum data loss, least failover time and also cost effective.
Model used here is Hot Stand By it has minimum Recovery Time to bring the farm online.
Hot StandBy Sharepoint 2010 Disaster Recovery can be done by different ways :- Log Shipping, Mirroring.
In this article I have configured the DR using the log shipping (more preferred).

Log Shipping in DR:

1. Log Shipping performs three Task to perform the operation : Backup Transactional Logs, Copy these logs to secondary Server and Restore the log backup to the database.
2. Each task creates a Job, all the jobs run in regular interval scheduled.
3. The primary server instance runs the backup job to backup the transaction log on the primary database and then it places the log backup in the primary log backup file location.
4. The secondary server instance runs its job to copy the primary log-backup file to its own local destination folder.
5. Now secondary server run its own restore job to restore the log backup from destination folder to secondary database

 Points to Note:-

  • Log Shipped Databases can be attached to web application while they are log shipping.
  • Multiple Secondary Database can be configured in log shipping database.
  • Log shipping Database can be queried if it is in standby Mode.
  • This is a Low Cost solution.

 Limitations:

  • Chances of some amount of data loss is always.
  • By default, the failover process for log shipping is manual. You can create scripts to automate failover.
  • Database must use the full or bulk-logged only to configure log shipping database.
  • Database account need to have control on the shared path.
  • Bit more complex the mirroring.

  

Before you Start:

 In the example we are considering that both Farm(Production and DR) are part of same Domain.

 Preparing the farm 

Step 1.

 Before you start installing and configuring the new sharepoint farm make sure all the new DR Servers configuration are same like==> OS version, Security patches and Hot Fixes as of Production Servers.  

Step 2.

 

 Install and configure a new sharepoint server 2010 farm, keep the same version of Service Pack and CU for SharePoint and SQL.

 Check SharePoint Build version: Launch Central Administration | System Settings | Servers in Farm | Check Build Version Example: “14.0.6029”

 Check SQL Server version: Run this query on SQL Management Studio:  'Select @@version' 

Step3.

Plan for service accounts (Farm admin, Setup accounts, Application pool accounts and others.) 

Step4.

Primary SQL Server has to write transactions to a network path\ backup folder , so make sure SQL Prod account has read and write access to this network share. 

 

 SharePoint supports Log Shipping for following Databases:

 Config DB and Admin Content DB are not supported to be log shipped. You should create a new Configuration Database in DR farm (Same Configuration Database cannot be shared or used in two different farms) 

Databases Type

 

Supports Log Shipping

  ( Yes/No)

Config Database

No

Admin Content Database (Central Administration Site)

No

State Service Database

No

Content Databases

Yes

Managed Metadata Service

Yes

Web Analytics Reporting and Staging Database

Yes

Secure Store Database

Yes

Search Service Application Databases (Databases: Crawl, Property, Search Administration)

No

Project Server Database

Yes

User profile Service Application Databases (Profile/ Syn/Social)

No

Business Data Connectivity database

No

  

Step by step configuration of DR. (Configuring the log shipping)

Step1.

Login to the SQL management Studio and right click on the content database -> Properties -> Transaction Log Shipping->

https://msdn.microsoft.com/en-us/library/ms190640.aspx  (use the following link for configuring the basic steps log shipping) 

Step 2

Database State:

Under ‘Restore Transactional Log’ Select the Standby Mode as below in settings of log shipping configuration.

 

 No Recovery:

   If you are selecting the ‘No Recovery Mode’ the database will be in Restoring mode and it cannot be attached to the web application from Sharepoint. 

------------OR------------  

Standby Mode:  

If you select the ‘Standby Mode’ database can be attached with the web application and you can browse the site collection. But you cannot make any changes or upload files. Only few options will be available. Also you can run select queries from the SQL during the standby mode.  

 SharePoint UI will also not show some operations like, Edit Page, Create Item etc. 

 

Step 4.

 Create all the web application with the same name, url and database name as in production and attach the content database (if standby mode is selected). 

Step5.

 Create and configure the service applications which you are using in your production and which cannot be log shipped like User profile Service app, Search service and others.

  

Steps to failover:

 Changes Need to be done when you failover from Production SharePoint 2010 to SharePoint 2010 DR Farm. 

 Step 1.

 Disable the log shipping for all the databases on which you configured log shipping. Uncheck the below option from Transaction Log Shipping.  

 Login to the SQL management studio -> Select the database -> Right click Properties-> Transaction Log Shipping =>

 

  And this will disable the job on the primary Server. 

Step 2

 Copy and restore the latest T-log backups to make sure all is in sync on DR side by running the copy and restore jobs on DR server.

 Example: Last copy ran at 1:00 PM and SQL crashed at 1:10. This means that the transactions between 1:00 to 1:10 are not shipped to Log shipped databases.  

Step 3.

 Run the following SQL query on master database to bring the database available and online.     

  "RESTORE DATABASE <database_name> WITH RECOVERY"

  One the DB is in online mode, its Icon should look like below 

Step 4.  

 Detach and attach all the content database from sharepoint central administration. (in case if any new site collections /sub sites are created in the web application) Or Run the script to refresh the site map table in the config database.

 Dismount-SPContentDatabase "<ContentdBName>"

 Mount-SPContentDatabase "MyDatabase" -DatabaseServer "MyServer" -WebApplication https://sitename

 Repeat this for all content databases.

 Why? We know that out configuration database was not log shipped, so any new site collection that is created in Prod web application will not be added in DR Config Database automatically. When content database is detached and reattached, all its site collections are registered in Site Map table of Config DB.

Step 5.

   Install the WSP solutions which you have installed on production farm and make other manual changes as done in production sharepoint farm like AAM settings, IIS bindings, Web.config changes. 

Step 6.

   Associate the service applications with web application and configure the remaining settings needed for the service applications.

Step 7.    

  Test the result on the DR SP farm and then change the DNS entry from the production farm to the new DR farm. 

 

Some Common Queries:

Q1: Is The performance of the sharepoint primary server will effect during the log shipping?
A1: Yes, You might also face performance issue if the system takes to ship log consistently more then time that is required to create new logs. It is better to backup and copy many small transaction logs compared to large transaction logs.

Q2: In the event of an unplanned failover, some data loss is possible ?
A2: Yes, depending on the frequency of log shipping and the time of failure. It is possible to lose data from the last log shipping interval before a failure.

Q3: Is log shipping method feasible with more than 10 number of databases?
A3: This is subjective to hardware, network throughput and resources available on servers. SQL Performance Counters can be used to find the optimized level for your environment.

Q4: How can we verify what solutions custom/3rd party web parts are in the environment in new farm after DR ?
A4: stsadm -o enumsolutions will give you details on what all solutions are deployed in the farm. OR check CA solutions page.

Q5: Can we crawl the content before the failover on the DR Farm?
A5: No we cannot crawl the content before the failover. It is recommended to crawl the content after the failover.

Q6: Do we need to disable the timer jobs on the failover (secondary) farm?
A6: Yes, we should always disable the timer job on the failover on secondary farm.

Q7: Do we need to plan for the SSL certificates on IIS websites on DR Server?
A7: Yes, if web apps are hosted on SSL then certs should be applied to DR farm IIS Sites respectively.