This is my research today/this week, until I get it working and properly documented, at least on our configuation traking Wiki.

Links:

• ITPRODSK-106: Microsoft Office SharePoint Disaster Recovery (recommend IE only): http://www.microsoft.com/technet/community/events/moss2007/dsk-106.mspx

Colleagues have alluded to “The GUID Problem” wherein if you don’t take a site collection’s content database offline before restoring a copy of it to the same farm, you’ll get errors because the GUIDs will match and confuse SharePoint, so the recommendation there is that if you have retroactive data you wish to restore to a different web application/site collection while maintaining your main branch on a prod server, try instead to stand up an entirely different farm, restore to that farm, then use stsadm with the -o export operation to backup the content and then restore it again on Production.

Or better yet, don’t fiddle with Production!

Anyhow, here’s the steps I am going through to get this to work. Again, my situation is that I’m just trying to verify that a full farm backup can have part of its content (one web application’s site collections) restored somewhere else if need be.

1. Take the full farm backup with either stsadm -o backup -directory \\UNC\path\ -backupmethod full - url http://mossdev1/ or via the Central Administration UI to do the same thing (left as exercise to reader). (Note, you need to make sure that the service account that’s running your instance of SQL Server for the back-end has write access to the filesystem/UNC Path you provide during the backup setup steps.)
2. Copy the xml files and directory tree generated to a new farm for restore. Share this directory to make sure it has a valid UNC path. Make sure your SQL instance Service Account has full access to the share/UNC path.
3. Check to make sure there are no failed Job Statuses for Backup/Restore on your target (restore) farm.
4. Locate the directory where you want to/already store SQL database files (your SQL admin may already have placed this somewhere else on the server or it may go to the default: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data. Make sure you’ve got proper permissions to write to that directory (I used a very high-level account, permissions-wise, to request the restore, and made sure that it had write permissions to the directory, but am not entirely sure that’s the correct account to configure – need more research here.
5. Restored part of full farm (only one web application: http://mossdev1:44444/ and one Content Database: WSS_Content_Database).
6. Because the security model was completely different for the target server from the source server, went into SQL 2005 Management Studio, connected to the proper instance, and found the Content Database (to make sure it was properly restored), opened the AllDocs table to make sure data was in there, and then edited the SQL instance’s logins to make sure that the Farm Service Account had proper rights to access the Content Database (I gave it dbo rights on the database, but you can probably get away with User rights specifically granting Connect rights within the database in question).
7. Because the host name of the Web Application I restored is different from the VPC’s hostname, make sure that IIS recognizes the proper host header, and that you have DNS or hosts file entries that map to the proper IP address. Go into the IIS Manager, right click the Virtual Server that corresponds to the Web Application you just restored. Click the Advanced button in the Web Site Identification control group on the Web Site tab. In the pop-up box, click the entry for your port, click the Edit button, and add the proper host header value(s) to the Host Header Value text box. If you are changing DNS records, be sure to create an A and a PTR record. If using hosts files, just go to C:\WINDOWS\system32\drivers\etc\ and edit that file!
8. Because the fact of the different security model probably kept the Content Database from being properly attached to your Web Application, go back and do that manually. Go to Central Administration, choose Application Management. Then choose the Content databases link under the SharePoint Web Application Management section. Click the Add a content database link in the title bar. On the next screen, specify the database server/instance, database name and you can probably leave the other fields at their defaults (unless your organization specifies other settings).
9. Because of the different security model, you’ll also need to add your current login account to the Web Application’s policy. Do that now. From Central Administration’s Application Management area, choose Policy for Web Application (Under the Application Security section). Click Add Users, then make sure you’ve got the right web application and click Next. Specify the user(s) you wish to have Site collection administration, choose Full Control and click Finish.
10. Now try out your site restore by going to the URL it should be at. If you’re not sure about that, check out your Site Collection List under Application Management for that Web Application.
11. If you have any other issues, you may be on your own, because honestly that was enough problems to surmount for me today! 🙂