Wednesday, August 6, 2008

An Unhelpful STSADM -o Restore Error

Uh, What Version Should It Be?

The other day I was helping a gentleman from IT troubleshoot this particularly odd error:

Your backup is from a different version of Windows SharePoint Services and cannot be restored to a server running the current version. The backup file should be restored to a server with version '1178817357.0.120615.0' or later.

I thought this was a little weird since the only error I'd seen similar to this had to do when you try to do a backup/restore from a newer version of SharePoint (say 12.0.6219 [SP1]) to an older version of SharePoint (say 12.0.4518 [RTM]). Even then though the error gives you a real version of SharePoint, I can't say I've ever heard of version 1178817357.0.120615.0 (although the last 7 digits seem suspicious).

It's also of note that the source server was running 12.0.4518 and the destination server was running 12.0.6219 so there wasn't an incompatibility with SharePoint versions.

As it turns out we just weren't using the commands correctly. The IT Worker who had taken the backup (of a sub site) had run an STSADM -o export:

stsadm -o export -url http://RootSite/SubSite -filename c:\path

The IT Worker (another person) who was trying to restore the sub site was trying to use the STSADM -o restore:

stsadm -o restore -url http://RootSite/SubSite -filename c:\path

These two commands of course don't go together which is why we were getting the error. Using an stsadm -o import migrated the site as expected. It's also a good practice to have a subsite already created at the destination URL before you import. It also occurred to me that given a .bak file it's kind of hard to tell if it was created using an stsadm export or a backup.

A quick reminder:

STSADM -o backup/restore are for site collections.

STSADM -o export/import are for sub sites.

Also of note, when running stsadm -o export I would often encourage the use of the -nofilecompression flag. This creates a series of files (as opposed to just one file) in the directory that you specify with the -filename flag, but runs as much as 60% faster in my experience. The backup though is of course larger than it would be had we not used the flag.


No comments: