"SharePoint 2007 to 2010 Upgrade" online project (part 5) : Backup strategy

[What you have]:
 A SharePoint farm.

[What you want]:
Backup the SharePoint farm in the way that you can restore all of the parts from scratch. Maybe you want to build the exact replica of Prod for staging purposes, or maybe you want to be fully prepared in case of the disaster.

[What you want to know]: 

Here is the backup coverage of the SharePoint data with different tools:

The red  SharePoint blocks are more important than green to back up. The Large blocks are more crucial than smaller.

VM snapshot\server image
As you can see a VM snapshot\server image covers all aspects of the SharePoint farm. You could say - why bother? I will make do with snapshots\images. Before to decide on that be aware of following:
- Image\snapshots restores everything. In some cases, you would like to keep some system state untouched.
- If you want to restore the copy of Prod for staging purposes - You have to take care for  IP\SID that got duplicated in the network after the restore of an Image\Snapshot.To check the SID

Windows backup utility with selected option "System state"
"System State data contains, among  other things, the Windows Registry, the Active Directory service database, the IIS metabase, and system files that are protected by Windows File Protection. You cannot pick and choose which items within the System State you want included. Microsoft actually recommends that you back up all boot and system disk volumes in addition to the server's System State."
(SharePoint 2007 Disaster Recovery Guide)

Central Administration "Backup and restore"
 Central Administration - Operation has a section "Backup and Restore", if you ever have tried to backup through it - you would have  noticed that  the backup has an option to backup "Farm". But even you select this option it will not backup the registry keys, file system, or IIS metabases of your SharePoint servers, and the farm's configuration database.
 This option lack the full coverage, plus it doesn't have a schedule. Every time it's a manual work. My recommendation - use it when needed but don't rely on it as a systematic backup\restore procedure.

SQL backup:
The book Microsoft SharePoint 2010 Administrator's Companion states:
  "If you could back up only one server, it would have to be your SQL server. SQL server contains more than 95 percent of your SharePoint information."
  "With the exception of the SQL server and the operating system, the server hosting the Central Administration Web application  is the most important component in the recovery of a SharePoint installation"

Please refer to How to restore a sharepoint web app from a SQL backup

 I would like to address the issue with  "SQL backup of config database". Partically, the intrigue topic "How to backup\restore SharePoint configuration database"

Microsoft support on Restoration Config db :

 In Microsoft Office SharePoint Server 2007 and in Microsoft Windows SharePoint Services 3.0, restoration of the configuration database is not supported using the built in backup and restore functionality.

The way to perform the full farm backup: Mysterious config database: you can back it up but not restore?

The actual steps to move of SharePoint databases which is similar to copying them: SharePoint 2007 – Move Content and Configuration Databases

My suggestion is: If SharePoint databases are in full recovery mode. Backup all of them, + logs. And restore them at point in time.

Stsadm backup

In SharePoint 2007 out of the box the smallest component you can backup\restore is a site collection.

!I am not aware what functionallity is available regarding backup\restore in stsadm 2010\PowerShell.
Since this post is one of the series "SharePoint 2007 to 2010 Upgrade". My focus is to elaborate the backup plan for my 2007 old farm to make the transition to 2010 safe.

Stsadm backup\restore is a great tool for small easy managed site collections. It doens't work well with large sizes.
To be honest, I don't use it. On Prod we have a big site collection (30 Gb). Even with small site collection stsadm is kind of slow.
 I don't include the stsadm import\export command in this scenario. I consider it is not a backup option, but a way to import and export the site. For more details refer to Sharepoint: How to backup site: stsadm export and SPD backup 

What if you need to restore site collection not the whole web appliaction? Definitely try to utilize stasdm backup\restore

[What you want to do]:
Chose the appropriate backup strategy. Document it. Proceed with backup. Test the restore beforehand.  

Buy the book:  SharePoint 2007 Disaster Recovery Guide

[What you want to consider]:

Should I back the Index server up?

"If your index sizes are measured in gigabytes or terabytes, you will want to back up your indexes so they can be restored, providing a reasonably timed return to service."
(Microsoft SharePoint 2010 Administrator's Companion)
"When requiring a speedy return to service, you should consider using disk-to-disk backups for your indexes."
Microsoft Office SharePoint Server 2007 Best Practices recommends use a native catastrophic backup tool stsadm.exe -o backup -directory to back up and restore SSP. The SQL backup of SSP of search db  doesn't include the search indexes which are stored on the file system on the Search role of the farm.