Hi All Thanks for taking the time to read this. I've been handed off by a set of developers who've left no documentation, a sharepoint farm hosting several complex applications. I am trying to put in a disaster recovery system such that complete disaster recovery / rebuilt of the farm should catastrophe occur is possible. Unfortunately attempting to do this to test systems has been a nightmare. The developers made extensive use of off the shelf Ajax controls, and custom webparts/smartparts that are not documented anywhere. There are 50 different web.config files strewn about. The mssql database on the backend is filled with custom databases as well for the various apps that have been created. I'm coming from an apache/unix environment where backup/recovery/migration is fairly simple and straightforward, regardless of how many custom modules are used. I have copies of the 12 directory, databases, stsadm full site backup, stsadm individual site backups, Inetpub from the live production site. Am I missing something? I can't imagine sharepoint backup/restores to be this complicated? Do I really have to hunt down every single installer for every feature/webpart/etc. thats part of the site? Is there any easier way to do this?

Do some research. If the SP environment is really that complex, a 3rd party tool (AvePoint?) might get you on the road to recovery. The custom databases should be covered by normal SQL backups./bac

Well, I hate to say it, but the problem is that yes, SharePoint DR is in fact that complex. When we started the SharePoint 2007 DR Guide, I was worried about having enough content to fill 250 pages but in fact we ended up running out of room for all the information we wanted to include in it (I say that as an example, not as a plug, I hate doing plugs). As you've already pointed out, the big problem you have is the undocumented presence of custom code and solutions in your SharePoint environment. If that code is not deployed to a DR environment, any sites or pages using that code will likely not work. You have to account for those items that you've installed into your production environment so that you can reinstall them in a DR solution. Unless you use a third party tool that can account for custom code (which can be a tricky thing for any tool to do given the broad range of directions you can take with SharePoint development), the answers for you aren't all that great. You'll either have to try to capture everything that's been deployed to your production environment and redeploy it to your DR environment, or have to strip all of that customization out of your production farm so you can focus on protecting and retaining the contents of your SharePoint farm. Honestly, you've got a pretty good list of the things you need to be retaining from your production site. The only other thing to think about is SSL certificates (if your sites use them), and how your Active Directory or other account repositories are protected. Does that help? JohnMCTS: WSS v3, MOSS 2007, and SCOM 2007 MCITP: Enterprise Project Management with Project Server 2007 Now Available on Amazon - The SharePoint 2010 Disaster Recovery Guide. Also available - The SharePoint 2007 Disaster Recovery Guide. My blog: My Central Admin.

Well, I hate to say it, but the problem is that yes, SharePoint DR is in fact that complex. When we started the SharePoint 2007 DR Guide, I was worried about having enough content to fill 250 pages but in fact we ended up running out of room for all the information we wanted to include in it (I say that as an example, not as a plug, I hate doing plugs). As you've already pointed out, the big problem you have is the undocumented presence of custom code and solutions in your SharePoint environment. If that code is not deployed to a DR environment, any sites or pages using that code will likely not work. You have to account for those items that you've installed into your production environment so that you can reinstall them in a DR solution. Unless you use a third party tool that can account for custom code (which can be a tricky thing for any tool to do given the broad range of directions you can take with SharePoint development), the answers for you aren't all that great. You'll either have to try to capture everything that's been deployed to your production environment and redeploy it to your DR environment, or have to strip all of that customization out of your production farm so you can focus on protecting and retaining the contents of your SharePoint farm. Honestly, you've got a pretty good list of the things you need to be retaining from your production site. The only other thing to think about is SSL certificates (if your sites use them), and how your Active Directory or other account repositories are protected. Does that help? John MCTS: WSS v3, MOSS 2007, and SCOM 2007 MCITP: Enterprise Project Management with Project Server 2007 Now Available on Amazon - The SharePoint 2010 Disaster Recovery Guide. My blog: My Central Admin.