Restoring SharePoint 2007 sites and web applications from a backup can be quite a headache; SharePoint is famously tight-lipped when it comes to error messages. This is a rundown of some of the issues we've run into in restoring from backups.
--
Restore Errors
DCOM Permissions
If your restore fails with a log referencing "UnauthorizedAccessException" referencing a COM class with a long CLSID and error number 80070005, you've got a COM Config permissions problem. This error is accompanied by a system event log like the one below.
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{3D42CCB1-4665-4620-92A3-478F47389230}
to the user domain\databaseconnectuser SID (S-1-5-21-2142909598-1293495619-134157935-85307). This security permission can be modified using the Component Services administrative tool.
As the event log error indicates, the fix for this is to use the Component Services tool (dcomcnfg.exe) to give Local Activation permissions to the user listed. Here's the rub: you don't at this time know which COM class to modify. To figure that out, search in the registry for the CLSID as referenced in the event log and restore log.
The registry search will give you the name of the com class. Unless it doesn't: a common class to have this problem is OSearch. If, when you search the registry, you see "Microsoft Office SharePoint Server Search Gathering Manger", the name you'll look for in the component services tool is OSearch.
By the way, you're looking in the DCOM Config tree in Component Services, as in this screen shot.
Right-click on the appropriate class and select Properties. Then click on the Security tab and edit the Launch and Activation Permissions.
Add the user that is mentioned in the event log, and give that user local launch and local activation permissions.
Finally, restart IIS with a iisreset /noforce. That should take care of this error.
Web Site Is In Use Restore Error
Especially if you've set up multiple SharePoint sites using host headers and SSL, you'll likely end up with the following error when trying to restore the web application:
ArgumentException: The IIS Web Site you have selected is in use by SharePoint.
You must select another port or hostname.
The issue is that SharePoint, in restoring the IIS sites, doesn't restore the host headers, as well. Hard to figure out why, but there you have it. Moreover, this error isn't a IIS error, which is to say that, even if you fix the alleged conflict, SharePoint still will error out on the restore, because it still thinks there's a problem.
So you have to do one of two things: customize the settings when you restore the web applications (to use different port numbers), or restore them one at a time, configuring each after the individual restore to use host headers. In either case, to end up with the original URLs, you'll have to do some fiddling after the restore is complete.
In short: you want to restore the web applications, such that you've got the content back. Having done that, you can re-create the web sites, using the Extend an existing Web application component of SharePoint's Application Management.
Extend the newly-restored web application to a new IIS web site, using the appropriate port number and URL. Once you've extended it, you can go back and "Remove SharePoint from IIS Web site." Using the remove function, you can delete the unwanted site, leaving only the desired URL.