Couple of Approaches that you could try:
1: Run SharePoint Config Wizard on both the servers
There could be server patches installed, SharePoint services installed, SQL patches installed, pending restarts or any other factor that you might want to rule out initially. Then perform a backup and restore operation. This is an easy one to cross off the list (quite often overlooked).
2: Match Environment Patch Levels
The best & recommended fix is to ensure that you match the SharePoint Configuration Database versions and/or Cumulative Updates/Patch levels to match both the environments- the environment from where you took the backup might be at a different patch level than the environment you are going to restore the patch to. (Goto Central Admin –> System Settings –> Manage Servers in this Farm and verify if there is any pending action. Keep not of the version to verify any version mismatches between environments)
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.
3: 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 commandlets fails, stsadm has worked for me.
stsadm –o restore –url "site url" -filename "backup filename"
4: Content DB Restore
Try a Content Database Backup and restore. Before doing this 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. You do not want to lose any other Site Collections that shares the same Content DB.
5: Editing Backup File
(Not Recommended - But works like a Charm)
This is one of those quick and untidy fixes you could possibly try. To start, open the backup file (file you got from the Backup-SPSite command) in Notepad++. (or any other text editor; avoid Notepad though). It might look funny with special characters, but ignore all those for now.
If the file size is too large to open in Notepad++ (>100MB), you can use any standard File Splitter Program to split the file into multiple smaller files of say 10 MB. I have had success with FFSJ
When you edit the file (if you have split the files, open the first split file) in Notepad++ and look for version number that looks something like 15.0.XXXX.XXXX. It should appear somewhere in the beginning lines.
DO NOT MODIFY ANYTHING ELSE. Interestingly, this is the version number that the Restore-SPSite Commandlet checks initially. And if it sees the server version different from the backup version, it just throws the error
Now to know which version number to put there, all you have to do is open your ULS logs (15\Logs{latestlogfile}) and search for a text "schema version". You should see a message similar to this:
Could not deserialize site from E:\SiteCollection1.bak .
Microsoft.SharePoint.SPException: Schema version of backup
15.0.YYYY.YYYY does not match current schema version 15.0.XXXX.XXXX at Microsoft.SharePoint.SPSite.Restore(String filename, Boolean
isADMode, Boolean& readOnlyMode, Boolean& hadWriteLock)
If you are unable to find the above message in the logs, then the issue would be probably something else and there is little/no chance to get this option to work
If you succeed in finding the error message, pick the version number it was expecting from the above ULS error message and update the VERSION NUMBER ONLY in the backup file you were editing in Notepad++. Save it. If you had split the files using a file splitter tool, merge the files back into a single backup file.
Now run the restore command with the new backup file and see if it works.
Restore-SPSite -Identity {{SiteCollectionURL}} -Path "E:\SiteCollection1-New.bak" -Force
These are just a few of the options (not an exhaustive list, but hopefully a good start) that you could try.
I have had greater probability of success with option #1 & #5. Option #2 is something that should be done in the long run.
You could read a bit more on this from my post here as well.
