Backup and restore databases

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.

Supported backup and restore methods

The following backup and restore methods are supported for 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 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.

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 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.

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 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.

Individual SharePoint content database and 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 databases that are mapped to the associated SharePoint content.

  3. 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.

  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.
  3. During configuration of Nintex Workflow, attach to an existing Nintex Workflow configuration database that has been restored on 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 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.

In-place restore

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

  • Workflow 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: The SharePoint 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 for 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.

  • Workflow 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 the action Set a Variable configured to perform 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 [Out-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 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.

In-place import

  • Workflow definitions: A restore of a sites using the SharePoint Export-SPWeb command will bring across the definition and association data of all workflows within the sites. The following additional administrative steps must be completed before and after the export/import steps:
    1. Run the command NWAdmin.exe -o PrepareSiteForExport -siteUrl urlToSiteToPrepare, before executing Export-SPWeb on your sites.
    2. Run the command NWAdmin.exe -o FixSiteAfterImport -siteUrl urlToSiteThatWasImported, after executing Import-SPWeb on your sites.

    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.

  • 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: 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: Not preserved.

Out-of-place Import

  • Workflow definitions: Same outcome as In-Place import method, with the understanding that any Nintex workflow that has references to data within the old location of the site collection will need to be republished from within the Nintex Workflow. For example, in the situation where a workflow contains the action Set Variable configured to perform 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 [Out-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: 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: 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 Nintex Workflow content database.
  • Any existing site collections will continue to store their data in the previous Nintex Workflow content database.

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.

Scenario 1

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.

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 Administration, to associate the existing site collection with the new Nintex Workflow 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 Administration) for the necessary web application.
  5. Import your sites 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 Administration) for the necessary web application.