Configure Disaster Recovery Farm with SharePoint 2010

  • Article

If you haven't read and still looking for the information on DR farm configuration with MOSS 2007 then you can refer the TechNet article. In this post i have explained how to configure the DR farm with SharePoint 2010 and what are the improvements we have in SharePoint 2010 as compared to MOSS 2007.

You can configure SharePoint 2010 DR farm using SQL Log shipping or SQL database mirroring for SharePoint databases. Before i start SharePoint 2010 DR farm configuration, I want to give an overview of SQL database mirroring, SQL log shipping and what can be used. In this post i am going explain followings.

  1. Overview to SQL Database mirroring
  2. Overview to SQL Log shipping
  3. What can be used for SharePoint 2010 DR Farm configuration
  4. SharePoint 2010 DR Farm configuration using SQL Database mirroring
  5. SharePoint 2010 DR Farm configuration Using SQL Log Shipping
  6. Comparison
  7. Changes required when you failover

Overview to SQL Database Mirroring:

Database mirroring feature is available in SQL 205 and SQL 2008. Its a solution to provide database high availability and its configured per-database basis. You can only configure the database mirroring for the databases that use the full recovery model. You cannot configure the database mirroring for the System Databases (master, msdb, tempdb & model).

In database mirroring there will be 2 copies of a single database residing on 2 different SQL instance. One SQL server instance act as Primary server and holds the active databases. All the clients or applications connect to this database server. Other SQL Server instance act as Secondary server or mirror server which holds the hot or warm databases. Once the database mirroring has been configured and databases are synchronized state, failover can be performed without a loss of data. While you configure the SQL database mirroring you can also configure the Witness server. This is going to another SQL instance which would be monitoring the primary SQL server instance. If primary SQL Service fails then witness server will automatically failover the databases from primary SQL server instance to Secondary SQL server instance.

There are 2 operating modes for configuring Database mirroring:

  • Asynchronous: This doesn't need the Witness Instance, that means there is no automatic failover. Once the Database server is not available administrator to stop the database mirroring session manually.
  • Synchronous: You can configure this with witness server (optional). If you configure with witness server then you get the advantage of automatic failover feature. However, automatic failover requires both the databases to synchronized.

Lets look at the advantages and disadvantages of database mirroring.

  • Database Mirroring Advantages:
    • Easy setup and maintenance
    • Real-time synchronization of transaction log
    • Automated failover (in High Availability Mode, Witness Server Instance required)
    • Fast & easy Failover
    • Using connection strings you can make your application mirroring aware or using SQL alias.
  • Database Mirroring limitations:
    • Database mirroring is configured per database not per SQL server Instance.
    • Mirror database always in recovery mode and this database can’t be used for any purpose or database queries.
    • Database mirroring can only configured for one database to another database. There can’t be more secondary server.
    • Database mirroring can’t be configured for once database once than once.
Note:- Database mirroring can be configured for the databases having Full Recovery Model. Database mirroring can not be configured for the databases which is using Simple Recovery Model.

Overview to SQL log Shipping:

SQL log shipping allows to backup the transaction logs from primary SQL Server instance in regular interval to one or multiple secondary SQL Server instance. Transaction log backup are restored to all the Secondary SQL Server instances individually. SQL Log Shipping consist of 3 operations:

  • Backup transaction log from the primary server
  • Copy the transaction log backup to the secondary server or secondary servers
  • Restore the transaction log backup to the secondary server instance

Above 3 operation will create 3 jobs on SQL Servers. Backup Job will be only available on Primary SQL Server instance. However, Secondary SQL Server instance contains the Copy job and Restore job. All these job executes in regular interval and you can define the time. SQL agent service has to be on running for log shipping.

  • Log Shipping Advantages:
    • Flexibility to backup, copy and restore the transaction logs.
    • Due to scheduled jobs database corruption can be avoided.
    • Multiple secondary databases can be configured
    • Secondary databases are in read-only and standby mode and can queried if required.
    • Log shipping allows multiple standby databases
    • Log Shipping disadvantages:
  • Log Shipping Disadvantages:
    • No option for automatic failover
    • Minimum time to synchronize is a min. which can be configured. 
    • For failover need to execute SQL Query. not simple as database mirroring.
Note:- Transaction Log Shipping can be configured for the databases having Full Recovery Model. It can not be configured for the databases which is using Simple Recovery Model.

What can be used for SharePoint 2010 DR Farm Configuration:

For SharePoint 2010 Disaster Recovery Farm configuration you can use both. However, if you use Database mirroring then databases on Secondary SQL Server or Databases on Secondary Datacenter will be on restoration mode which you cant attach to the web application. I would always recommend to use SQL log shipping for SharePoint 2010 DR Farm configuration. Again, SQL database mirroring is mostly used for HA and SQL log shipping is used for DR. On this post i will be explaining DR farm configuration with both and compare at the end so you can choose what's best for you.

SharePoint 2010 DR Farm Configuration using database mirroring:

To configure the DR Farm using Database mirroring, you need to start a fresh installation of SharePoint 2010 on Secondary Datacenter. You should have below:

  • Install and Configure SharePoint 2010 Farm in Secondary datacenter in same AD Forest using Primary SharePoint farm Service accounts
  • Install the customizations which are present on primary farm
  • Create all the web applications which are present on primary farm
  • Create all the Service applications
  • Detach the content databases from the web applications and delete the content databases
  • Configure the mirroring only for content databases from Primary SQL server to Secondary SQL server. By Default all the content databases uses Full Recovery Model. If you have changed the Recovery Model for to simple for any content databases, it will not allow you to configure database mirroring unless you change the recovery model back to full recovery model.
  • Create database mirroring without the Witness server for all the SharePoint Content Databases only. No witness server required as database mirroring would be used for High Availability and auto-failover is not required

To configure Database mirroring using SQL management Studio you can follow the MSDN Article.

Note:-

  • Do not configure database mirroring with Witness Server.
  • Database status on Primary SQL server would be “(Principal, Synchronized)” . It might take a while to reach that status.
  • Database status on Secondary SQL server would be “(Mirror, Synchronized / Restoring..)”
  • As soon as the database mirroring has been configured transfer the SQL logins from Primary SQL Server to Secondary SQL Server following Support Article. If you feel following support article is difficult then you need to create the logins manually, assign them appropriate roles. If you don’t transfer the SQL logins then after fail over you will not be able to connect to SQL databases and you will be receiving errors on SharePoint servers.
  • On Secondary SQL Server, you cant change the database status from SQL management Studio. To change the status of the database you need to execute the below SQL query:
 ALTER DATABASE ContentDatabaseName SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

 SharePoint 2010 DR Farm Configuration using database log shipping:

To configure the DR Farm using database log shipping, you need to start a fresh installation of SharePoint 2010 on Secondary Datacenter. You should have below:

  • Install and Configure SharePoint 2010 Farm in Secondary datacenter in same AD Forest using Primary SharePoint farm Service accounts
  • Install the customizations which are present on primary farm
  • Create all the web applications which are present on primary farm
  • Create all the Service applications
  • Detach the content databases from the web applications and delete the content databases
  • Create the log shipping for the content databases only. By Default all the content databases uses Full Recovery Model.If you have changed the Recovery Model for to simple for any content databases, it will not allow you to configure database mirroring unless you change the recovery model back to full recovery model.

To configure Database log shipping using SQL management Studio you can follow the MSDN Article.

Note:-

  • Database status on the Secondary Server would be “Stand by / Read-only”.
  • As soon as the database log shipping has been configured transfer the SQL logins from Primary SQL Server to Secondary SQL Server following Support Article. If you feel following support article is difficult then you need to create the logins manually, assign them appropriate roles.
  • On Secondary SQL Server, you cant change the database status from SQL management Studio. To change the status of the database you need to execute the below SQL query:

      RESTORE DATABASE contentdbname WITH RECOVERY

Comparison of using SQL database mirroring or Log Shipping for SharePoint DR farm.

Database Mirroring:

  • In database mirroring Real time transaction log shipping to secondary SQL Server. Incase of primary SQL server failure latest information will be available on Secondary SQL Server.
  • As Database on Secondary SQL Server would be “Mirror, Synchronized / Restoring” We will not be able to attach the databases to web application on DR farm. Incase of Failover we will need to make the databases active and attach the databases to web applications.
  • After failover when we attach the content database to the web application, it will automatically refresh the site map on Configuration database.
  • As we cant attach the databases to the web applications, Search Service Application wont be able to crawl the content. After Fail-over you need to crawl the content.
  • When failover happens we need to run SQL script to make the all content databases writeable.

Database Log Shipping

  • In Log shipping transaction log backup, copy and restore happens on scheduled time (Minimum time 1Min). Incase of fail-over from primary SQL Server to Secondary SQL Server we might loose some data if that's not restored on SQL Secondary SQL Server or manually restore the transaction log backup to Secondary SQL Server database.
  • As Database on Secondary SQL Server would be “Stand by/ Read-only” It will allow you to attach the databases to web application on DR farm and we can crawl the content using Search Service Application.
  • As the databases are attached to the web application we can run a script to refresh the Site Map on Configuration database.
  • As we cant attach the databases to the web applications, Search Service Application wont be able to crawl the content. After Fail-over you need to crawl the content.
  • When failover happens we need to run SQL script to make the all content databases writeable.

Changes required when you failover from Primary SharePoint 2010 to SharePoint 2010 DR Farm.

If you are using SQL database mirroring:

  • On the DNS Server make the changes so that all the request can be reached to DR Farm SharePoint 2010 WFEs.
  • Run the SQL Query to make the database active. (ALTER DATABASE ContentDatabaseName SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS)
  • Attach content databases to the web applications.
  • Start a full Crawl process on Search Server.

If you are using SQL database log shipping:

  • On the DNS Server make the changes so that all the request can be reached to DR Farm SharePoint 2010 WFEs.

  • Restore all the pending transaction logs backup to database.

  • Run the SQL Query to make the database active. (RESTORE DATABASE contentdbname WITH RECOVERY )

  • Start an Incremental Crawl process on Search Server.

    After knowing both the options, now you can choose between database mirroring and Database log shipping for DR farm configuration.