Let me start by saying that if I've missed out on some very basic papers, KBs or anything, feel free to link me in the right direction. I've checked some threads here and haven't found the answer to the questions I have.
I've created a simple script as per MS example for full backup (stsadmin with full backup option to a network drive). Now to the question:
Scenario: We have some kind of disaster destroying this server. How do we get it up again together with the content? I've gathered that the stsadmin tool backup everything important in terms of content and such, but what about settings and WSS itself? Would I just to install a new server with IIS, WSS 3.0 with the same configuration settings added as during the first install etc., and afterwards run the stsadmin tool to restore data, or am I missing anything here?
Thanks in advance.
IMHO, it would be much easier, faster, and safer if you used a third party backup product that can backup the server, the system state, and sharepoint using a windows backup agent and a sharepoint backup agent. BackupExec comes to mind.
Do a trial restore of your proposed method (STSADM backup to new WSS server) using a VM and see if the sites come back in an acceptable form. Your backups are only as good as your last restore.
By only using STSADM you will lose everything in Central Administration and any customizations you have made to the Themes, CSS, or any XML config files on the filesystem. If you are using a vanilla WSS install and only care about emergency document retrieval this may be fine for your organization.
MS has docs on backing up using SQL Server tools, which should back up the site configuration and content, but not anything that has been altered on the filesystem. Note "You cannot use the SQL Server 2005 backup and restore tools to restore your configuration database to a different farm or topology configuration." So, if you have a simple topology this may be an acceptable limitation.
Also make sure you are capable of getting the recovery server up to the same exact version that your production server is currently running.
But yeah, if your company cares about the data, fork out the dough for a decent backup package. We use Commvault's connector.
I would recommend the following:
Following scenarios of DR can be resolved via these backups:
The stsadm method works ok, but never felt very efficient to me. Disasters happen very rarely, but you should be backing up your Sharepoint daily, and don't want to be burdened by poor performing backups all the time.
If you backup your databases, and any customisation files you have, then getting back up and running is more or less a matter of building a new Sharepoint server and SQL server, installing the customisations, then pointing Sharepoint at the config database. It should then pick up all the settings and content databases.
The all singing all dancing way I prefer is to have virtualised Sharepoint servers, which you backup in entirety in addition to all your Sharepoint databases. You can then restore the VMs and databases, and get up and running in a very short period of time with minimum stress. It's really easy to document compared to other methods too.
There are third party solutions for Sharepoint backup/restore that might provide more granular options, particulary when it comes to restoring individual items, but I'd be surprised if they provide much more benefit in a true disaster scenario. At the SQL side you may find something like Quest Litespeed backs up and restores your data more efficiently, which is of value.