Recently there have been a few key improvements to the STSADM
backup command which I have found to make life a lot easier (and
safer!).
After installing
Service Pack 2 and running the backup command you will
notice a few subtle, but important changes:
Previously it was a best practice to set the site being backed up
to read only using the setsitelock
command. This is something that I am guessing 95% of people never
did. And who can blame them as it wasn't made terribly
obvious. Fortunately the backup command now automatically sets this
and lazy admins can have peace of mind.
The April CU also provided an important update to how backup and
restore works, particularly with publishing sites. In SharePoint,
the actual page layout aspx files are stored with some hardcoded
metadata which includes the url of the site they belong to.
Previously when performing a backup & restore to different
farms with different URLs this could
cause issues. Import/Export does not have this problem as the
page layouts are recreated in the target site. The backup command
has now been updated to fix this issue and this method of migrating
content between farms is now supported. Note that
the
June CU is now available and supersedes the April CU.
So why would you want to use backup/restore over import/export
to migrate content anyway?
If you commonly use the SPSiteDataQuery class, ContentQuery
webpart or the DataView webpart you rely on GUID
references to lists for query commands. By default, import/export
assigns new GUIDS to any lists that are migrated which will
upset the queries that rely on them. Using backup/restore was an
easy way to avoid this issue.
Of course it was fairly easy to write some import code
using the object model and retain the GUID values. And if you still
want to use import/export that is the way to go.