The backup and restore tools that come with SharePoint are not the best in the world. It is easy to get it wrong and it takes a brave presenter to deliberately destroy a setup in order to demonstrate how the restore process works.
So what are the steps, and how did Bill English, CEO of Mindsharp, do?
Spsbackup can backup and restore the entire server farm, an individual server or component. It does not backup IIS or web services. Only supported server topologies can be backed up. SQL authentication is not supported.
What gets backed up? All SQL databases; some configdb information; index files and sps.edb; 2001 document library; SSODB; selected virtual servers/site collections.
What should be backed up separately? All web front-end customisations such as templates, web part files and other file-based information; operating system and binaries; system state data; IIS, virtual servers and metabase.
Three steps to a full farm backup: 1) backup portals including the index. 2) backup the IIS metabase on each web server. 3) backup the virtual server files for each virtual server.
In spsbackup, the backup location must be a UNC. The portal must be backed up n the front-end that it was originally extended from. When backing up the IIS metabase, if you select to encrypt it, the backup becomes portable and can be used elsewhere.
Tearing down a portal farm: delete all portals. Remove the shared services portal last. If you have separate WSS root collections, Windows SharePoint Services must be removed from the site before proceeding (Bill got this wrong in the demo but managed to recover). Remove each server from its farm roles. Detach each server from the ConfigDB.
When deleting the portals, you can choose to delete the databases or not. If you leave the databases intact, you can take the databases and attach them to a new virtual server. Also, during the restore process, you have to select new database names.
Building a new portal farm: you need a new ConfigDB. Membership is defined by which SharePoint servers are connected to the same ConfigDB. Use one of the SharePoint Servers to create the new ConfigDB. Join the other servers next.
If possible, assign all of the roles in the farm before restoring any of the portals. Ensure that you do everything possible to not move the index server role once the index is restored because it is the most difficult role to move. Review the farm topologies and ensure you are in compliance with the topologies.
From any server, create a new ConfigDB. From the other servers, connect to an existing database, i.e. the ConfigDB that has just been created. Do not do this on multiple servers at the same time! Do one server at a time. Once all of the servers have joined, you can assign the server roles.
Now restore the virtual server files, restore the metabase for each server, restore shared services, the portals and the index – all in that order. Note that WSS site collections can be restored ahead of shared services because they are a "portal thing", and WSS site collections don’t use shared services.
After restoring the shared services portal, you have to re-select shared services in the SPS interface before proceeding to restore any other portals.
The end result? Bill pulled it off!!! As you can see from the notes above, backup and restore of SharePoint is not easy, and hopefully this is something that MS will correct in the future. In the meantime, maybe the above will help.