So today I ran into a disaster scenario at a client where we needed to restore a SharePoint backup because the SQL instance got hosed. Turns out all the SQL database logins were deleted by accident and nobody could connect or login to the database server. What we needed to do was create a new instance of SQL on the same server and move the SharePoint databases from the old, non functional instance, onto the new one, and thereafter restore the farm backup.
This post is pretty good at describing the backup/restore process:
http://www.sharepointblogs.com/llowevad/archive/2008/01/02/moving-to-a-new-database-server-or-instance.aspx
However, I would add that there are two important things to backup BEFORE you start this process:
Web.config(s) and other Web Application root files
This is because when you run the SharePoint configuration wizard and disconnect from the server farm, it will delete all your web applications and all web.config and other files/settings you have specified therein will be lost. If you have custom app settings, connection strings, etc, you'll in quite a panic if you don't back these up FIRST.
SharePoint Solution Packages
The SharePoint farm backup doesn't backup solution packages (.wsp files) that are installed into the farm. Make sure your solutions are backed up FIRST, otherwise your sites may suffer the lack of important functionality when you restore them. Most of the time I see people sticking the solutions in some sort of source control to get them backed up on regular bases. Alternatively, some people back up the entire inetpub/wwwroot directory, and sticking the solutions in there can be sufficient to get them backup regularly. Either way, make sure you have these files because they're GONE after you disconnect from the farm...
To check to see if you have Solutions that need to be backed up, go to Central Administration, Operations:
That's all for today!
Phil