Monday, June 20, 2011

Differences between stsadm export and backup operations

 

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

Stsadm –o backup/restore

With the URL and filename 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 keeps every GUIDs except one (and the most important): when you restore the file, it generates a new GUID for the site collections. This was done on purpose because Sites table of configuration database uses SiteID as 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 all others GUIDs remain unchanged.

This operation is probably more designed for SharePoint administrators that want to backup data. Because it does not do anything else than dumping the SQL content database, administrators can be sure no data will be changed, transformed or lost.

Stsadm –o export/import

This is the only standard operation that allows you to store a sub site (a SPWeb), but it can also export a site collection or an entire web application. It exports the data using object model, and generates a new GUID for every objects such as sites, sub sites, lists and items.

Another difference is that an import does not involve losing existing data. You can restore a site 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 copy any information related to workflows. If import creates new lists and a workflow was associated to them, you must recreate it manually. Additionally, it does not copy workflow history and tasks lists.

Contrary to the backup operation, it does not matter in which content database you run import operation, and you can restore a top site as a subsite, and reciprocally.

This operation is probably more designed for people that want to merge content of sites, and finely choose 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. Now let me boil down this more a precise tablular manner….!!remember this used to fetch more marks…..school day… hmmm… Smile 

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.

If this helps...... then please share......

HaPpY CoDiNg... (Aurum)

No comments:

Post a Comment