If you want a straight and fast backup and restore, use the stsadm backup and restore operations.

To back up a site, go to the 12-hive bin folder and type the following command:

stsadm -o backup -url http://mysite -filename myfile.dat

Then to restore your backup, use the following command:

stsadm -o restore -url http://mysite -filename myfile.dat

Notes about using STSADM backup and restore commands:

1. Security settings (owners and permission levels) and other user-informated (Created By and Modified By fields) will carry over when you restore it.
2. This is faster than using STSADM export/import operations.
3. You can only do this on a top-level site. Say you want to get a subsite inside your site-collection, forget it–this operation can only get that subsite by backing up and restoring the whole site collection.
4. Point is, backup/restore is not granular. It’s an all-or-nothing backup and restore of a site collection.

If you want to get ‘somewhat’ granular, you can use STSADM export/import command. I say ‘somewhat granular’ because you can’t really drill down to list or library level. But if you have many subsites and you just want to backup and restore (or migrate) a few, then STSADM export/import will be for you.

To export a sub-site, go to the 12-hive bin folder and type the following command:

stsadm -o export-url http://myserver/mysite -filename myfile.dat

Then to “restore your backup”, use the import command:

stsadm -o import-url http://myserver/mysite -filename myfile.dat

Notes about STSADM export/import command:

1. Slower than using backup/restore
2. Security settings and other user information (Last Modified By, Created By, etc.) do not carry over to the new site. I didn’t had a chance to test this operation with a site that uses some type of approval workflow–I don’t think the “Assigned To” properties will stick with export/import simply based on the observed behavior on standard documents and list libraries.
3. Yes, you can export a sub-site so that you don’t have to export the whole site-collection. But you can’t export a library or list or document. You say “why not just template the site and include the content in the template”. You got size-limitations there bud and you won’t be able to ‘template’ a site and include its content if the library or list has too many files.

By the way, I’ve only shown examples using the required parameters -url and -filename. There are other optional paramters to use when using these STSADM commands. For full details, visit the Microsoft page Index of STSADM Operations and properties (Office SharePoint Server)

The WSS 2.0 environment has “moved around” a lot. The front-end and SQL backend has been toasted at least once and the environments had to be recreated from scratch. The only backups they had were SQL backups. The SQL backups were okay.

Now, he wants that WSS 2.0 upgraded to WSS 3.0. I thought, well, this should be easy–only one Web front-end and one SQL server. Also, he had no intention of keeping WSS 2.0. So, just do an in-place upgrade, and it should be done, right?

Well, I ran into problems when I did the pre-upgrade scan prior to running the WSS 3.0 Configuration Wizard. You’re supposed to run the pre-upgrade scan tool prior to upgrading WSS 2.0 sites to WSS 3.0. Otherwise, if you run the Configuration Wizard without running the prescan tool, you will get:

Configuration Failed.
One or more configuration settings failed. Completed configuration settings will not be rolled back. Resolve the problem and run this configuration wizard again.

To run the prescan tool, go to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Bin and execute the following command:

prescan.exe /all

(For more details, see the Microsoft KB article 938216. )

When I ran the prescan tool, I encountered errors and it says on the log file:

Upgrade has encountered one or more lists that were not updated by Prescan.exe and must exit. The most likely reasons for Prescan to skip a list are covered in the Knowledge Base article at: http://go.microsoft.com/fwlink/?linkid=69958&clcid=0×409 (http://go.microsoft.com/fwlink/?linkid=69958&clcid=0×409) For more information about the lists that are not upgraded, see the upgrade log file.

It seemed like there were orphaned objects. I told you, this WSS 2.0 had been recreated a few times and they used SQL backups to restore the contents. Things have been orphaned or convoluted along the way. Oh yeah, the Web front-end server also had several (non-WSS) virtual sites that were running on port 80; they were differentiated only via the use of host-headers. I couldn’t find the orphaned objects to drop and realized that the I’m stuck and couldn’t proceed with the upgrade. I spent an hour performing the recommendations on how to repair/remove orphaned lists and then I stopped.

So here’s what I did instead:

1. Backed up the WSS 2.0 site collection using stsadm
2. I restored the WSS 2.0 site collection in a different environment/farm. I used my home lab environment for this.
3. I then upgraded my home lab WSS 2.0 to WSS 3.0.
4. I backed up the WSS 3.0 site collection using stsadm. Now I have the site upgraded to WSS 3.0.

Only thing I have left to do is cleanup the Web front end server at my customer’s site and re-install WSS 3.0 without the upgrade option. Once WSS 3.0 is installed and configured, I can restore the site collection. I’ll do that tomorrow.

Sometimes, you just have to do what you have to do to get the job done.