Microsoft.SharePoint.SPException: Schema version of backup 15.0.xxxx.xxxx does not match current schema version 15.0.yyyy.yyyy

A common error that you might face while doing site collection backups and restore is the following error:

Could not deserialize site from E:\SiteCollection1.bak . Microsoft.SharePoint.SPException: Schema version of backup 15.0.4641.1000 does not match current schema version 15.0.4719.1000     at Microsoft.SharePoint.SPSite.Restore(String filename, Boolean isADMode, Boolean& readOnlyMode, Boolean& hadWriteLock)

Note: You can capture this error in your ULS logs or use ULSViewer, when you run the Restore-SPSite command through SharePoint Management Console

Fix(s):

#1: CU Update– The best & recommended fix is to ensure that you match the SharePoint Configuration Database versions to match both the environments (Goto Central Admin –> System Settings –> Manage Servers in this Farm)

In the same page, double check that you do not see any “Upgrade Required” mentioned against any of those servers. If it is mentioned there, please ensure that you run the SP Config Wizard before you proceed.

Once things look good, and you have compared the versions, download the latest KB from Microsoft and install them to match the SharePoint Configuration Database Schema versions. Perform all server remediation & CU (Cumulative Updates) installations. Remember to run the Configuration Wizards for each CU.

#2: Using STSADM – This is a pretty interesting workaround. But sometimes I feel “Old is Gold”. Power up your SP Management Console and try to perform the restore operation using the good old STSADM command line. At times, when the new powershell commands fails, stsadm has always worked for me. [[Touchwood]]

stsadm –o restore –url “site url” -filename “backup filename“

#3: DB Restore – Content Database Backup and restore. You might want to check in Central Admin (View All Site Collections –> Select the Site Collection and check the Content DB on which it is installed on) about which all site collections will get affected if you restore a particular Content DB.

#4: Editing Backup File – This is one of those quick and untidy fixes you could possibly try. There are few caveats to keep in mind before you try this fix:

• Ensure that the backup file size is smaller (preferably less than 500MB), else you might need a good editor (Visual Studio 2013 would crash beyond 500MB)
• Keep note of the version number of the SharePoint Configuration Database Schema of the server to which you wish to restore the backup
• Ensure that there are no major version differences in between the environment version. You can analyze this by going through the release notes of the higher version and see if there are no DB schema changes. Security updates/minor patches should be fine. But if you see any major DB schema changes in the release notes, please avoid this fix.
• Success of this approach is not guaranteed. You may or may not crash the site collection that you will be restoring the backup to or may even corrupt the backup
• Please take a backup of the backup file

The fix is pretty straightforward. You can open the backup file in Visual Studio or any Disassembler softwares and change the version number mentioned in the beginning of the file to that of the SharePoint Configuration Database Schema of your restoring environment. Those who have cracked software’s in the golden days could use one of their handy tools to edit the file as well.

Save the file and then try out the “Restore-SPSite” command this time. If things look good, you might succeed in restoring the backup without the version mismatch error…:)

Note: If your file size is in the range of GBs, as in case of one of my backups (2GB), try to split the large file into small 100MB files using file splitting tools like  GSplit tool –> Then edit the First split file in Notepad++/Visual Studio –> Change the schema version number –> Reunite the files using combining tools like GUnite (comes with the GSplit tool itself) and then use the reunited backup file in the STSADM restore command. Use this approach only when you are in a state where Desperate times calls for desperate measures…:X

Once again! Use the Fix #4 with caution and only under extreme cases.