Some key differences between stsadm export and backup operations

It's not obvious to understand key differences between a backup and an export. Although they are both designed to backup data, they work completely differently.

Stsadm –o backup/restore

With the URL and file name parameters, it allows you to backup either a site collection or web application. You can basically consider the file generated more or less as a SQL dump of (a part of) your content database.

It preserves the GUID of every object except the GUID of the Site: when you restore the backup, SharePoint generates a new GUID for the site collection.

This was done on purpose, among others things because Sites table in configuration database uses SiteID as the primary key.

This is very important because it allows you to restore the backup in the same farm in which you did the backup. You can even restore the same backup several times in the same farm, but you must always restore in a different content database, because the GUID of every other object remains unchanged.

This operation is designed to take an exact copy of a site collection, no data will be changed, transformed or lost.

Stsadm –o export/import

This is the only standard operation (not talking about possibilities with custom code) that allows you to backup data of a sub site (SPWeb object), but it can also export a site collection, an entire web application, or a single list. It generates a new GUID for every objects such as sites, sub sites, lists and items.

Another difference is that you can restore the content in an existing site, the behavior with existing data is defined with the parameter updateversions in import operation.

A major drawback of this operation is that it does not preserves workflows instances, associations, history and tasks. Every workflow association must be recreated and there is no way to restore the running instances from original site.

Contrary to the backup operation, it does not matter on which content database you run import operation, and you can restore a top site as a subsite, and reciprocally (except for sites with publishing feature where it is not supported:http://blogs.technet.com/b/stefan_gossner/archive/2009/05/27/limitations-of-stsadm-o-export-import-related-to-publishing-sites.aspx).

This operation is good for merging content of sites, and decide how to handle identical data between source and target. Very important, do not forget to use includeusersecurity parameter in both export and import if you wish to preserve information relative to permissions and other properties such as documents authors.

Backup/Resotre	Import/Export
1. Can back up top-level websites (Site Collections), an individual database, a Web application, or an entire farm. 2. There is no Default File Extension for back up files, however, I use “.bak”, 3. Supports "Full" and "Differential" back up. If "overwrite" option is selected while restoring it overwrites entire SiteCollection 4. Supports UNC path to save/restore backup files. 5. Backup of Site Collection can be tracked by stsadm -o backuphistory operation	1. Like Smigrate.exe utility in SPS 2003, you can migrate sites, subsites and Site Collection. 2. Default file Extension (if not mentioned) ".cmp" 3. Provides "versions" option to control migrate/overwrite files in site 4. Backup files should be copied to server 5. Sites/SiteCollections would not track export/Import history
Syntax	Syntax
For site collection backup  stsadm -o backup -url <URL name> -filename <file name> [-overwrite] For catastrophic backup  stsadm -o backup    -directory <UNC path or local drive>    -backupmethod <full or differential>    [-item] <created path from tree>    [-percentage] <integer between 1 and 100>    [-backupthreads] <integer between 1 and 10>    [-showtree]    [-quiet]	stsadm -o export    -url <URL name>    -filename <export file name>    [-overwrite]    [-includeusersecurity]    [-haltonwarning]    [-haltonfatalerror]    [-nologfile]    [-versions] <1-4>    [-cabsize] <integer value>    [-nofilecompression]    [-quiet]
For site collection restore  stsadm -o restore    -url <URL name>    -filename <file name>    [-hostheaderwebapplicationurl] <Web application URL>    [-overwrite] For catastrophic restore  stsadm -o restore    -directory <UNC path>    -restoremethod <overwrite or new>    [-backupid] <GUID from backuphistory, see stsadm -help backuphistory>    [-item] <created path from tree>    [-percentage] <integer between 1 and 100>    [-showtree]    [-suppressprompt]    [-username] <user name>    [-password] <password>    [-newdatabaseserver] <new database server name>    [-preservechangelog]    [-quiet]	stsadm -o import    -url <URL name>    -filename <import file name>    [-includeusersecurity]    [-haltonwarning]    [-haltonfatalerror]    [-nologfile]    [-updateversions] <1-3>    [-nofilecompression]    [-quiet]

To recapitulate -

It queries the site using the object model and stores everything the site had that was exposed using the front end UI, into the given file. By default, you might miss older versions of files in a document library that has versioning turned on. You can however specify command line parameters to these commands to influence further control on how older versions are backed up. Also, this approach is quite arduous for a farm with a number of sites. Most of all, stsadm can error out at times, and the error can show up on command line, or even worse, the command line may tell you that it worked, but an error may show up in a log file somewhere.