Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I am getting an error "Backup version is different" while restoring SiteCollections from one web application to another on the same SharePoint server farm. Following are the steps I was executing when I got the error

  1. Created a new web application in the same sharepoint farm (url: http://localhost:5000).
  2. Created a new SiteCollection and some test sites under the site collection (url: http://localhost:5000).
  3. Took a sitecollection backup using Backup-SPSite (url: http://localhost:5000)
  4. Executed Restore-SPSite command against an existing webapplication with no site collections. (url: http://localhost:3000)

    Restore-SPSite http://localhost:3000 -Path D:\Localhost_5000.bak -Force

  5. After executing Restore-SPSite I got an error stating that "Restore-SPSite : Your backup is from a different version of Microsoft SharePoint Foundation and cannot be restored to a server running the current version. The backup file should be restored to a server with version '4.1.6.0' or later."

One thing I noticied is that, if I restore the SiteCollection to the same url (eg: http://localhost:5000) no error is thrown and everything goes well.

After googling I came to see similar posts in SO, where the proposed solution was to verify the build version and make sure patches installed on the Source machine is available on destination machine as well. But in my case I am taking a backup and restoring it on the same machine under a different webapplication.

Please help me to resolve this.

share|improve this question
    
i am facing the same problem. Did anyone achived to resolve this problem? –  user4858 Sep 18 '11 at 21:14
1  
@Edin Did you also apply sp1 without running the config wizard? If so, can you run the config wizard? –  Tom Resing Sep 19 '11 at 19:25
    
I agree with @Mike and I'm going to merge these two questions since there are some good answers here. –  Kit Menke Apr 17 '12 at 19:45

6 Answers 6

up vote 3 down vote accepted

I got some help for you from twitter users @NaupliusTrevor and @toddklindt.

Trevor says that error message could be occurring because the original content database has an older schema than the current patch level of the new content database. This could occur because the patch didn't change the schema of old db's when it was applied but it will create new content db's with the new schema. When you created the new web app, you created a new content db.

Todd suggests using upgrade-spcontentdatabase, however, I think you'd need to apply it to the old content database before backing up which may not be possible in your case.

Another option may be to create a new farm at the patch level of the old content database.

share|improve this answer
    
Let me check out your suggestion. Thanks for that. –  AbrahamJP Sep 9 '11 at 9:12
    
@Abraham Hope it helps. Keep us updated! –  Tom Resing Sep 12 '11 at 19:26
1  
You are right. I took the backup after installing SP1 and at the same time I forgot to execute the SharePoint Config Wizard. Thanks for poining out that. –  AbrahamJP Sep 19 '11 at 5:15
    
Glad we were able to help. Thanks for reporting back on the results! –  Tom Resing Sep 19 '11 at 19:26

As the error suggests, the SharePoint server version that you are taking backup from does not match the SharePoint server version on which you are restoring.

  1. Check which of these server needs an upgrade. It can be either License upgrade from SharePoint Standard to Enterprise. You can verify the versions from Central Admin -> Manage servers on farm

  2. Run the SharePoint configuration wizard on the upgraded server and confirm that the version numbers are the same now. If yes, try restoring the backup using the above PowerShell command now.

  3. If it still does not work, you might have to upgrade the particular content db which is causing this problem. For that you should run the command upgrade-spcontentdatabase on that particular db and then try restoring it.

Also check my blog for the same issue and the solution provided.

share|improve this answer
    
deepu thx for your suggestions –  AbrahamJP Jun 1 '12 at 9:38

Try to use

export-spweb -identity http://host/site -path file.cmp -force
import-spweb -identity http://host/newsite -path file.cmp

Before import-spweb comand invoking you should create a new site collection in different data base as http://host/site.

you can use this comand

New-SPSite http://host/newsite -OwnerAlias userName -ContentDatabase dbName
share|improve this answer
    
Can be that done at Top Site Collection level? Also export and import are these PowerShell commands or stsadmin? Thank you –  Eugene Apr 17 '12 at 14:18
    
I think that it can be applyed for top site collection level. It is the powershell comands. One thing more - the new created site should has the same template as site that is imported. –  Alexander Apr 17 '12 at 14:20
    
I tried the way you suggested. Here is the error: Import-SPWeb: A duplicate field name .... was found –  Eugene Apr 17 '12 at 14:53

I tried a spbackup from a Non-sp1 farm on a SP1 June CU farm, and it did not work (different URL on the web app, but same managed path and same site collection).

I then created the same URL, managed path, and site collection, edited my hosts file on staging to accept the production URL, and no luck again.

The issue I believe is that Non-SP1 backups do not work on SP1 farms. (Even though the error says "...be restored to a server with version ...4762 or later", but my farm with SP1 is ...6105.

I am using MSDN media on staging, maybe thats an issue? I wouldnt think so but you never know...

Good luck. Best bet is to always use web application database backups, restore to temp web application, attach, then backup-spsite from the farm, then restore-spsite on the farm to the desired web app and site collection.

share|improve this answer

I'm not sure if this would work or not, but I wonder if you first should try creating a blank site collection in the root of the 3000 web application, and then use the -Force switch (heh, inadvertent geek humor there) with Restore-SPSite to see if you can get it to overwrite the new blank site with your backed up site collection.

Just something to try, I'm not sure why that would be the issue but at the same time it wouldn't surprise me...

John

share|improve this answer
    
+1 for "use the force"! Always a good answer! ;-) –  Tom Resing Sep 8 '11 at 15:44

I've seen this error before is situations where you have an existing web application with no site collections. As I recall, the way I got around this was to create a new site collection (blank template), then force a restore over the newly created one. HTH

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.