I don't have instant 'failover' per se, but I do have a setup using SharePoint Foundation that is basically pretty easy to setup and use. Plus it doesn't really cost anything.

One of the great new improvements in SharePoint 2010 is native support for SQL mirroring and automatic failover. In SharePoint 2007 you had to use some complicated SQL aliases to provide failover support. SharePoint 2010 has built in support for database mirrors, and allows you to define a failover SQL server for any databases you have mirrored. SQL Server Alias for SharePoint Servers in a FARM We are trying to create a SQL Alias as given on this link SQL ALias We have 2 SQL Servers, one is the main server and other is the Mirror. The DBA alter these servers at any time. Although SharePoint 2010 makes use of the Failover Partner keyword in its connection strings, SharePoint itself doesn’t appear to know whether or not SQL Server has failed-over for any given database. This post explores this topic in more depth and provides a PowerShell script to dump a farm’s mirroring configuration.

Basically the setup is to create a secondary SharePoint site on another server. I have a test or utility server for that purpose. Setup the second site as if you were going to migrate from one server to another. I have this How-to for this purpose: http://community.spiceworks.com/how_to/show/35831-migrate-from-sharepoint-3-0-2007-to-sharepoint-2010

Once that is setup, I use a stsadm command to backup from the production site three times a day using a scheduled task. You can roll your own PowerShell if you'd rather use that. The files are saved to the test/utility server. Then on that server I again use stsadm to restore the first backup. I do have scripts for the other two backups if necessary.

If site goes down hard, I can get people to switch to other site and continue on. After fix, reverse everything back to the production site.

The characteristic of an environment which have separate failover farm should be followed: You should maintain a separate configuration database and the SharePoint Central Administration website content database. Do all customizations must be located on both farms. The operating system, SQL. The operating system, SQL Server, and SharePoint Server software updates must be used for both farms, for maintaining a consistent configuration in both farms. You can copy content databases of SharePoint Server to the failover farm by applying asynchronous mirroring, asynchronous commit on an availability group replica, or log-shipping.

Sounds complicated, but this literally takes minutes after properly setup.

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:

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

Database Log Shipping

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.

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.

Cached

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:

Azure Active Directory: Synchronize On-premises Directories And Enable Single Sign-on

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)

Azure Resource Group: Container That Holds Related Resources For An Azure Solution

Start an Incremental Crawl process on Search Server.

Microsoft SharePoint High Availability

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