Common disaster recovery strategies

This section describes common disaster recovery strategies used with Nintex products.

The optimal strategy depends on your company's recovery objectives. For more information about disaster recovery strategies, see the following TechNet article: Choose a disaster recovery strategy for SharePoint 2013.

If your disaster recovery strategy is based on strategies supported by SharePoint and SQL Server, then it is supported by Nintex. Typically, we recommend the following strategies: 

• Secondary ("standby") data centers instead of local redundant systems and backups.

• Traditional mirroring when low-latency fiber connections are available.

• Log shipping with mirroring instead of traditional mirroring when time gaps are needed. The main benefit to log shipping is the delay, which gives you a time gap for recovery and guards against accidental deletions within the delay period. Typical delay periods might range from 15 minutes to four hours. When designing your disaster recovery solution, determine the optimal delay for your system.

• If SQL Server 2012 or later is used, then AlwaysOn availability groups are generally preferred.

For more information, see the following MSDN articles: Database Mirroring and Log Shipping (SQL Server) and AlwaysOn Availability Groups (SQL Server).

Example of log shipping with mirroring over two data centers (SharePoint farms) for a small- to mid-sized business with no dedicated line to the secondary data center.

The following disaster recovery strategies require Nintex-specific configuration:

• Log shipping with mirroring, in the case of failure or restore; see Nintex configuration for log shipping.

• Failover server setup; see Nintex configuration for setting up failover servers.

Disaster recovery strategies that use shared names or IP addresses for connectivity, such as clustering and AlwaysOn availability groups, generally don’t require any Nintex-specific configuration.