Hi, Connect. I am working on a project for a high-profile client in New York, NY using on-premises Nintex Workflow 2013 Enterprise, Nintex Forms 2013 Enterprise, and SharePoint Server 2013 Enterprise. The client is hosting their production SharePoint 2013 farm on-premises. In the event of failure, they have a secondary, DR (disaster recovery) farm hosted in Microsoft Azure running on virtual machines. The DR farm is a hot spare farm, meaning it is online 24/7 and maintained just as rigorously as the production farm. In order to achieve automatic fail-over, the SharePoint content databases are replicated asynchronously from the AlwaysOn group on-prem to the AlwaysOn group in Microsoft Azure. In Azure, the SharePoint content databases are read-only. They only become writable in a fail-over scenario. My client would like to achieve the same level of fail-over with the Nintex content databases.
The main challenge here is to keep the Nintex content databases and SharePoint content databases paired correctly and to prevent data loss and data corruption during a fail-over to the DR farm in Microsoft Azure. To address this challenge I've compiled a list of questions for the community here to discuss regarding disaster recovery for Nintex Workflow with a hot spare SharePoint farm.
- Can a Nintex content database, when in read-only mode, be successfully attached to a SharePoint farm using NWAdmin -o AttachDatabase?
- How can one prime the Storage table in the Nintex Configuration database when the SharePoint sites are read-only and the Nintex Workflow site collection feature cannot be deactivated and re-activated?
- When the production farm fails, what services must be stopped to prevent Nintex Workflow from writing data into the production AlwaysOn database group?
- Should these services also be stopped in DR until a fail-over occurs?
- Will Nintex Workflow generate a large number of errors in the DR farm if the Nintex content databases are read-only at the SQL level?
