Looking for Nintex for SharePoint 2016 guidance? See the following link.
http://help.nintex.com/en-US/nintex2016/current/Default.htm#cshid=backuprestore

This article provides guidance on data management procedures for Nintex Workflow (2013 and 2010), specifically backup and restore functions that are compatible with SharePoint’s own framework and processes. The target audience are system administrators of SharePoint and Nintex Workflow. See also Database Design Guide: Nintex Workflow.

Supported Backup and Restore Methods

The following backup and restore methods are supported for Nintex Workflow 2013 and Nintex Workflow 2010.

• Restoring from the Recycle Bin; see Microsoft article: Manage the Recycle Bin of a SharePoint site collection.
  Note: You can restore subsites, lists, document libraries, and other SharePoint elements directly from the first and second stage recycle bins.
• Restoring subsites; see “Restoring a Site via Site Export/Import” below.
  Note: Avoid using stsadm commands; workflow history is not restored successfully if using stsadm commands to import and export sites and subsites.
• Individual Site Collection backup and restore; see Restoring Site Collections.
• DB Attach (restoring entire content databases): see Database Design Guide: Nintex Workflow.

Note: Promoting subsites to site collections is not supported as it can result in missing or corrupt content types or other issues.

Data Storage Overview

Nintex Workflow provides the ability to design SharePoint declarative workflows via a browser-based design surface.  Once a Nintex workflow is published, SharePoint treats the workflow no differently to workflows created by SharePoint designer, and as such, the SharePoint content database is responsible for storing and persisting data associated with a given workflow instance as it transitions through its lifecycle. Workflow data managed by SharePoint encompasses workflow history items, workflow tasks, workflow state management and, importantly, the workflow association and definition is also stored and managed by SharePoint. All of this aforementioned data is associated with a single SharePoint content database.

Ancillary to the data SharePoint maintains for a workflow, the Nintex Workflow content database stores additional workflow logging and tracking data to allow for more advanced workflow reporting. This database is also used to keep track of workflow action and task states in a way that can be reported on by Nintex Workflow. The Nintex Workflow configuration database stores settings such as which activities are allowed on which sites, workflow constants, workflow schedule definitions, message templates and the global settings found in Central Administration.

In a default installation, the Nintex Workflow configuration database also acts as the first content database, therefore the configuration database also contains the schema for a workflow content database.

Restoration Granularity

Nintex databases are not directly linked to the SharePoint content databases; however, all of the workflow tracking data for a particular site collection can be found in a single Nintex Workflow content database. You can set up SharePoint content database to Nintex Workflow database mappings pro-actively via SharePoint Central Administration to enable informed backup and restore decisions.  When backing up a SharePoint content database, the corresponding Nintex Workflow content should also be backed up at the same point in time. When restoring a SharePoint content database, the Nintex

Workflow content database backup from the same point in time should also be restored to ensure consistency between the workflow state (SharePoint database) and the logging/tracking data (Nintex Workflow database).

For guidance on planning database mapping and maintenance, see Database Design Guide: Nintex Workflow. In many cases we recommend mapping each Nintex Workflow content database to a SharePoint content database (1-to-1 mapping). For greater granularity, as with SharePoint, provision different site collections in different content databases (as required).

For instructions on how to implement a 1-to-1 mapping for an existing site collection already utilizing Nintex Workflow, see Splitting existing SharePoint and Nintex Content Databases‌.

Full Fidelity Backup and Recovery Process

The supported ‘full fidelity’ backup and restore method, of both SharePoint Workflow data and Nintex Workflow data, needs to be performed as SQL database backups using SQL server.

Backup

In an environment that has databases that are managed by DBAs, the strategy employed is based on the following:

• All Nintex Workflow databases are backed up by SQL Server. The backup interval that is set is based on the following:
  • The importance of the content or service.
  • The effect on performance that the backup has on the environment.

• All mapped SharePoint site collections are backed up using a strategy that maintains the referential integrity of SharePoint data. Specifically, all SharePoint object GUIDS must not be regenerated upon restoration. There are no restrictions on the tool/strategy employed for SharePoint database backups other than the aforementioned. Guidance on planning for SharePoint backups can be found here: http://technet.microsoft.com/en-us/library/cc261687.aspx#ChooseTools. Note: Mapped site collections are displayed on the Nintex Workflow Database Setup page in Central Administration.

Backup using a SQL maintenance plan. Ensure SharePoint content databases and Nintex Workflow databases are backed up together and that you have full transaction logs to enable restoration at any point in time.

Individual SharePoint Content Database & Nintex Workflow database restoration process

1. Stop the Web Application that is to be restored. This includes stopping the IIS site mapped to the web application and stopping the SharePoint Timer Service.
2. Restore the Nintex Workflow content database(s) mapped to the associated SharePoint content.
3. Restore SharePoint content database as per Microsoft’s guidance.
   • Ensure the Timer Service is stopped and the Web Application associated with the content database is also stopped before you attach the content database via SharePoint Management Shell.
4. Restart IIS and SharePoint Timer Service on all servers.

Full (catastrophic) DR high-level process

1. Restore SharePoint without attaching content databases.
2. Install Nintex Workflow 2013‌ or Nintex Workflow 2010
3. During configuration of Nintex Workflow, attach to an existing Nintex Workflow configuration database that has been restored on the SQL server.
4. Attach SharePoint content databases to your SharePoint farm.
5. Restart IIS and SharePoint timer services on all servers.

Site Collection Backup/ Restore Method

Restoring SharePoint site collections via the PowerShell backup/restore commands has several implications with respect to associated Nintex Workflow state and meta-data. Two scenarios are covered below, detailing an In-Place restore; a site collection is restored in the same location that it already exists in, and an Out-of-place restore; a site collection is restored to a different location within the same SharePoint Farm

In-Place Restore

An in-place restore is when the site collection orignally exported is restored over the original site, effectively restoring to a previous version.

• Workflows definitions
  The restore of a site collection using the Restore-SPSite command will bring across the definition and association data of all workflows within the site collection. Any Nintex Workflows, started after the restore process, will execute normally.
• Running Workflows
  When performing a Backup-SPSite / Restore-SPSite process, there is a limitation pertaining to running workflows continuing after a restore of a site collection. Once a site collection is restored, any workflows in a waiting state will error when they try to continue. The reason is that the workflow instance data references the ID of the site collection in which it was started. After restoring the site collection, the ID changes and when the instance data loads and uses the stored ID, it fails. Users will see the “Error Occurred” status.
• Current Workflow State
  State information is brought across for all current workflows, however any running workflows will ultimately proceed to an error state as mentioned above.
• Workflow History
  SharePoint’s workflow history is restored when utilizing a Backup-SPSite / Restore-SPSite process. Specifically, the standard Workflow History data that is maintained within the SharePoint database, as can be viewed by clicking on the dropdown menu of a SharePoint item and selecting ‘Workflows’, will be preserved when performing the Backup-SPSite / Restore-SPSite process. However, as you are restoring only the SharePoint data, the Nintex Workflow data existing within the Nintex Workflow database is not present, and as such the ‘View Workflow History’ link of a list item, which draws its data from the Nintex Workflow database, will be empty.
• Nintex Workflow History
  Nintex stores additional logging information in its own database and there is no option to restore this data on a per site collection basis. For workflow instances to restore correctly, entire database restores are the only option for SharePoint and Nintex workflows. Note: This will affect workflows in progress.  Newly started workflows, after the restore, will work fine.

Out-of-place Restore

An out-of-place restore is when the exported site collection is restored to a different location, thus making a copy of the site.

• Workflows definitions
  A restore of a site collection using the Restore-SPSite command will bring across the definition and association data of all Workflows within the site collection. Any Nintex Workflows that have references to data within the old location of the site collection will need to be republished from within the Nintex Workflow designer. For example, in the situation where a  Workflow contains a ‘Set a Variable’ action, that performs a ‘List Lookup’ on data within the given site collection, these references will still point to the old location of the source site collection – they are not remapped as part of the restore process. Therefore, Workflow designers will need to, as part of a post oOut-of-Place] restore, republish each workflow.
• Running Workflows
  Same outcome as In-Place site collection restore.
• Current Workflow State
  State information is brought across for all current workflows, however any running workflows will ultimately proceed to an error state as mentioned above.
• Workflow History
  Same outcome as In-Place site collection restore.
• Nintex Workflow History
  Same outcome as In-Place site collection restore.

Restoring a Site via Site Export/Import

Restoring SharePoint sites (team sites, also called webs) via the Export-SPWeb/Import-SPWeb commands has several implications with respect to associated Nintex Workflow state and meta-data. Two scenarios are covered below, detailing an In-Place Import; a Site or group of Sites is restored in the same location that they already exist in, and an Out-of-place Import; a Site or Group of Sites is restored to a different location within the same SharePoint Farm.

In-Place Import

• Workflows definitions
  A restore of a Site(s) using SharePoint’s Export-SPWeb command will bring across the definition and association data of all Workflows within the Site(s). There are two additional administrative steps that must be completed before and after the export/import steps, these are:

1. Run the command NWAdmin.exe -o PrepareSiteForExport -siteUrl urlToSiteToPrepare, before executing Export-SPWeb on your Site(s).
2. Run the command NWAdmin.exe -o FixSiteAfterImport -siteUrl urlToSiteThatWasImported, after executing Import-SPWeb on your Site(s).

Performing the above steps will ensure referential integrity of the Workflow to all SharePoint objects within the workflow definition. Specifically, the Import-SPWeb process generates new GUIDs for all SharePoint objects: Sites, Webs, Lists, ListItems. In order to remap the imported workflows to the newly generated GUIDs, we provide the preparesiteforexport fixsiteafterimport to work around this issue.

• Running Workflows
  Running workflows are not brought across when using the Export-SPWeb / Import-SPWeb process.
• Current Workflow State
  State information is not preserved in the imported site.
• Workflow History
  Workflow history is not preserved. This limitation is due entirely to the Export-SPWeb / Import-SPWeb process being incompatible within preserving referential integrity to existing workflow data within SharePoint.
• Nintex Workflow History
  Nintex Workflow history is not preserved

Out-of-place Import

• Workflows definitions
  Same outcome as In-Place import method, with the understanding that any Nintex Workflow that have references to data within the old location of the site collection will need to be republished from within the Nintex Workflow designer. For example, in the situation where a Workflow contains a 'Set Variable' action, that performs a List Lookup on data within the given site collection, these references will still point to the old location of the source site collection - they are not remapped as part of the restore process. Therefore, Workflow designers will need to, as part of a post fOut-of-Place] restore, republish each workflow.
• Running Workflows
  Running workflows are not brought across when using the Export-SPWeb / Import-SPWeb process.
• Current Workflow State
  State information is not preserved in the imported site.
• Workflow History
  Workflow history is not preserved. This limitation is due entirely to the Export-SPWeb / Import-SPWeb process being incompatible within preserving referential integrity to existing workflow data within SharePoint.
• Nintex Workflow History
  Nintex Workflow history is not preserved.

Map Out-of-Place Site to a New Nintex Database

When configuring the association of a SharePoint Content Database to a different Nintex Workflow Content Database, the effects in relation to site collections are:

• Any site collections created from now on will store their data in the new NW Content Database.
• Any existing site collections will continue to store their data in the previous NW Content Database.

Existing site collections continue to use the previously mapped NW Content Database by design, as any previous workflow data is not migrated across when re-configuring the database mapping.

Refer to Scenario 1 to move existing workflow data and set the existing site collection to use the new NW content database.

Refer to Scenario 2 if you don’t have any existing workflow data in the parent site collection that the (out-of-place) site is to be migrated into.

Scenario 1

In the situation where you require existing site collection workflow data to be moved to the new NW Content Database, and any new instances of workflows within the site collection to also utilize the new NW Content Database, you will need to run the NWAdmin –o moveData command to both move the existing workflow data, and to reconfigure this specific site collection against the new NW Content Database.

Refer to NWAdmin Operations - Nintex Workflow 2013‌ for further details on what you must do when running the moveData command.

After which, perform an IISReset to refresh any mapping records that are cached. At this point, you can perform your import of the site.

Scenario 2

If you are not concerned with the existing site collection workflow data, to associate an imported site with the new Nintex Workflow Content Database:

1. Reconfigure the Nintex Workflow database mapping in Central Admin, to associate the existing site collection with the new NW Content Database.
2. Restart IIS to force a refresh of cached mapping records.
3. Stop the SharePoint timer service on all SharePoint front-end servers.
4. Disable the Workflow Timer job (via Central Admin) for the necessary web application.
5. Import your site(s) to the destination Site Collection.
6. Re-Activate the Nintex Workflow site collection feature to set this existing Site Collection to use the new Nintex Workflow Content Database
7. Restart IIS to force a refresh of cached mapping records.
8. Start the SharePoint timer service on all SharePoint front-end servers.
9. Enable the Workflow Timer job (via Central Admin) for the necessary web application.

For subsequent replies to this post, please review the Word attachment.