I have always felt that one of the greatest features in SharePoint, going back to the 2003 version, was the ease at which you could restore a copy of your environment. Having that backup file can prove to be very powerful in setting a development copy of your portal or even restoring in the event of a real disaster. A key piece of this process is to understand what is NOT carried over in a backup. First, custom web part files (i.e. dll's) which typically reside in the /bin folder of your portal directory will not come over. You will need to copy these manually or re-execute a deployment package. The other important piece to note is that in the restoration process SharePoint resets the web.config to its default state. What does that mean? All registration for custom and third party web parts as safe controls is lost. The challenge with this, of course, is that your restored portal pages maintain their reference to these web parts so, after the restore, certain pages may throw errors or reference web part errors. Once again, here is my plug to have a fully documented Disaster Recovery plan that details all custom or third party web part installations.
All that said, sometimes "stuff" happens and you don't have a document. Maybe you inherited an environment; maybe the SharePoint person is on vacation. Here is a quick primer on troubleshooting web part problems in a restored environment (this is especially useful in the 2003 version [pre-Features] but pertains to 2007 as well)…
1. Note all custom and 3rd party web parts being used; also determine if you have installation instructions (if not, note the location of the web part files on the file system)
2. Take a copy of the production web.config file
3. Restore your environment
4. Perform all web part deployments. If you don’t have an automated process, copy all appropriate files (typically in the /bin folder or GAC) to the same location on the new server
5. This gets you all the way there 90% of the time. Two things to look for if you have problems after this point…
a. Check the original web.config file for differences against the current version. I have never been a big fan of dump and run (i.e. copying over the original file). Use this opportunity to understand the differences. One of the first places to look is the Trust level. Some web parts will want you to increase this to Full to execute with elevated privileges. You’ll want your systems to match.
b. Look for an appSettings section. This will contain application parameters that a web part might use to connect to another system or access external content. Often times, these parameters will point to the original server database or file system. Make sure all parameters point to the right place.
c. I always do an IISRESET after web.config changes
That’s it! I advise folks to do quarterly restores (at a minimum). More than anything, it helps prove that you can actually do one. And remember, document everything!