Reflects the current release of Nintex for SharePoint 2016. For your version, please access assistance through the Help button in the product.
This article provides guidance on data management procedures for Nintex Workflow, specifically backup and restore functions that are compatible with SharePoint framework and processes. The target audience is system administrators for SharePoint and Nintex Workflow. See also Design databases.
The following backup and restore methods are supported for Nintex Workflow.
Restoring from the Recycle Bin; see the following Microsoft article.
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.
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.
Note: Promoting subsites to site collections is not supported as it can result in missing or corrupt content types or other issues.
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 from 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 that 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.
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 proactively via 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 Design databases. 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 Split databases.
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.
In an environment that has databases that are managed by DBAs, the strategy employed is based on the following:
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 listed on the View database mappings page accessed from Central Administration. For more information, see View database mappings.
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.
Restore SharePoint content database per Microsoft 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.
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 in which a site collection is restored in the same location that it already exists in and an Out-of-place restore in which a site collection is restored to a different location within the same SharePoint farm.
An in-place restore is when the site collection originally exported is restored over the original site, effectively restoring to a previous version.
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.
An out-of-place restore is when the exported site collection is restored to a different location, thus making a copy of the site.
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 in which a Site or group of Sites is restored in the same location that they already exist in and an Out-of-place Import in which a Site or Group of Sites is restored to a different location within the same SharePoint farm.
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, list items. In order to remap the imported workflows to the newly generated GUIDs, we provide the preparesiteforexport fixsiteafterimport to work around this issue.
When configuring the association of a SharePoint content database to a different Nintex Workflow content database, the effects in relation to site collections are:
Existing site collections continue to use the previously mapped Nintex Workflow 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 Nintex Workflow 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.
In the situation where you require existing site collection workflow data to be moved to the new Nintex Workflow content database, and any new instances of workflows within the site collection to also utilize the new Nintex Workflow 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 Nintex Workflow content database. For more information on MoveData, see NWAdmin Guide.
After which, perform an IISReset to refresh any mapping records that are cached. At this point, you can perform your import of the site.
If you are not concerned with the existing site collection workflow data, to associate an imported site with the new Nintex Workflow content database: