A simple procedure gone wrong.
When do simple procedures go wrong? Never …
Recently an attempt was made to restore a SharePoint 2007 content database from our production system to our staging system. The restore was necessary to fully test new customizations with an up-to-date version of the content database from production. Seems reasonable, no?
The process went a little like this:
- Backup the content database on the production SQL Server
- Copy it over to the staging SQL Server
- Restore it over the top of the staging content database
- Re-attach the content database using Central Admin:
- Go to Application Management -> Content Databases
- Select your Web Application
- Click on the existing content database, check “remove” and hit OK
- Then re-add the content database
After this restore the site did not come back up. This is a fairly simple procedure and in most cases should yield a functional SP site. After some investigation, we noticed the following:
So what happened here?
After hours of digging, it turns out our staging farm had TWO instances of the same content database. The first instance, let’s call it “foo1.foocompelsyou.com”, was the original staging SP site, which was at one point restored from the production content database using the same procedure outlined above. The second site, let’s call it “foo2.foocompelsyou.com”, was a second instance of the same site, which ORIGINALLY was created via a stsadm backup/restore operation.
Restoring the backup of production’s content DB over foo2’s content DB made the Site Ids and Database Ids in f001 and f002 identical. The farm knows that these ids in the attempted restore of foo2 is already used by another site, hence why the current number of sites is listed as 0.
The fix is in.
Ok, so there are two identical content databases on my farm server with the same ids. Now what? Well, there’s not much you can do. I thought some behind-the-scenes trickery would work, such as manually updating site id and database id values. There are various posts on the interwebs that describe nefarious procedures to manually correct the problem, none of which really fit the bill.
Ultimately this did the trick:
- Restore the production content DB over the top of foo1.foocompelsyou.com’s content db.
- Using central admin, remove any existing content databases from foo2.foocompelsyou.com.
- Again using central admin, create a new content database for foo2.foocompelsyou.com.
- STSADM -o backup -url http://foo1.foocompelsyou.com -filename c:\temp\foo1.bak
- STSADM -o restore http://foo2.foocompelsyou.com -filename c:\temp\foo1.bak
And *poof*, foo2 is back in business.
In an ideal world …
The second foo site on staging, foo2.foocompelsyou.com, is essentially a deployment/QA test site. If there were a completely separate farm for foo2, this would not have been an issue at all. In our case there’s not enough spare iron or virtual space to create a new farm instance.
Well, that’s all I have on this one. Happy SharePointing.