Wednesday, June 18, 2014

Site collection backup/restore vs. site export/import

Site collection backup

PowerShell command to backup a site collection
Backup-SPSite -Identity "site collection url" -Path "backup file path"
More information for Backup-SPSite:

Site collection restore

PowerShell command to restore a site collection
Restore-SPSite -Identity "site collection url" -Path "backup file path"
More information for Restore-SPSite:

Restore results:

The results are the same when restoring on the same location or another location, in the same web application or another web application.
-          The restored site collection has new site ID (GUID).
-          All items versions and workflows are restored successfully.
-          Audit events are lost. This happens because of the new site ID (GUID). This can be fixed by updating Audit table in the content database. If the site collection is restored in the same location or another location that uses the same content database then rows in Audit table should be updated by writing the new Site ID in the rows that have the old Site ID. If the restore is done on another location that uses another content database then new rows must be created in the Audit table in the new content database by reading the old audit events from the Audit table in the old content database.

Site Export

PowerShell command to export SPWeb:
Export-SPWeb [-Identity] "site url or GUID" -Path "backup file path"
Important: Export-SPWeb does not export the running workflows.

Site import

Powershell command to import SPWeb:
Import-SPWeb [-Identity] "site url or GUID" -Path "backup file path"

Import in the same location

If there are event receivers running custom code in the lists it’s recommended to remove all of them before import to avoid any failure caused by the event receiver logic. Depending on the logic of the event receivers import may completely fail or the imported web may have wrong items version history and other problems. After import event receivers can be added back. For removing/adding event receivers with PowerShell check one of my older posts Add, Modify or Delete List Event Receivers with PowerShell

Import results:

-          Import operation does not import the workflows (as expected, because they don’t get exported with Export-SPWeb).
-          Import does not affect the currently running workflows but import of the document versions fails for those documents with running workflow.
-          Versions are correctly imported only for document with no workflows in running state when importing.
-          Audit events are not affected by the import, so all events are retained including those registered between export and import

Import in another sub site

The following must be done before importing the exported site:
-          Create new site using the same template and same language as the exported site
-          As explained above, removing event receiver is strongly recommended

Import results:

-          All running workflows are lost
-          All custom site properties and custom item properties are lost (properties in SPWeb.Properties and SPItem.Properties hashtables)
-          All workflow associations are lost
-          Document versions are imported successfully
-          Audit events are lost
-          Workflow tasks are lost


Database attach of a backed up content database is superior for custom SharePoint solutions that contain custom workflows, custom web and item properties, custom event receivers, version history etc. To avoid big content database and long backup times its better the custom solutions to be installed in a site collection that has its own content database instead of sharing one content database with other site collections. That way backup/restore space and time will stay in normal and manageable boundaries. In that case you can stick to database backup as the best backup/restore plan for highly customized and big SharePoint solution.
Site collection backup/restore is better than SPWeb export/import but not as trouble free as database backup/restore plan. The problems are caused by the new Site ID (GUID) generated. That causes lose of audit events, or more precisely additional work to correct the Audit table after the restore.
Site export/import is almost useless for custom solutions that contain custom workflows, event receivers, custom web and item properties, custom event receivers, version history etc. It has problems even if it’s used for simple sites that use only SharePoint out of the box functionality if it has lists with workflows and versioning enabled.


  1. @Kastuv : can you compare with metalogix tool also... in case if u have any idea on d tool

    1. The top 1 for us is that we don't need to pass the scripts to the server admins to run, we can just use regular credentials and run the process remotely.

      2ndly it's faster than PowerShell as you don't have to write convoluted scripts.

      It logically sequences migrations based on List dependencies e.g. if there are lookup columns you need to move the source ones first.
      Migrates permissions
      Doesn't affect ID,created/modified by/dates
      I believe it can migrate termset value too.

      We use it in Office 365... it would be a nightmare without it