If I schedule a backup of a Sharepoint site using stsadm, then I can restore that site – but only if the destination server has the same system state and STS_Config database as the original server. Not normally gonna happen in a disaster recovery scenario. OR – I could schedule a backup of a Sharepoint site using smigrate, and get a backup set that I can restore to any site on any Sharepoint server at any time, without having to worry about system state or the presence of other databases such as STS_Config. Take a guess what I’m going to be using for my scheduled Sharepoint backups going forward . . .
One of the biggest challenges with Sharepoint is backup and restore. Actually let me redefine backup and restore by the tasks we hope it will accomplish.
- Total restore. This is when we want to recover the entire backkup from a disk drive failure, theft, fire, hurricanes, etc.
- Partial restore. This is when we want to recover a specific file or group of files. The classic example of this is when someone calls and says they accidentally deleted the document or presentation they were working on yesterday.
- Archival restore. This is when we are asked to keep archives of files or groups of files for a period that goes beyond the backup retention cycle. Compliance laws typically push this requirement.
- Migration restore. This is a bit more complex. This is when we want to save the data in one format or structure and restore it into a different structure or format. This happens when we change data bases, operating systems, or storage technology.
The present Sharepoint backup technologies cover the total restore task pretty well. The partial and archival restore tasks are covered best by third party products. It is the migration restore task that the author is talking about. The standard backup is not independent from the template or the STS_config. By using the smigrate utility you can migrate your data to a new format or new server. The price is right. Obviously, this is worth further investigation!