Go 4 Sharepoint

Search:

Welcome: Guest!

Sharepoint Forum

Home » Forum » Sharepoint

Ask a question

RSS Feeds

Sharepoint restore quirkiness

Asked By: Dominique Higgins Date: Feb 22, 2007 Category: Sharepoint Views: 167

When I am doing a Sharepoint WSS V2 restore, I get some weird behavior. Here's
my process:

1. Perform SQL restore of production content DB to a new database.
2. Create new IIS Virtual Server and Extend it with new content DB
3. Remove existing content DB
4. Add restored DB as primary content DB

At this point, I see the sites enumerated in the Content DB settings and I can
get to the site. At the same time, though, I notice that our primary virtual
server's content DB now appears empty. If I remove the existing production
content DB and then bring it back in it appears to work, but then the secondary
virtual server seems to lose it's association with its content DB. This seems
to be an endless cycle. Anyone else experiencing this issue and how I can
resolve this? I'd like to be able to have both virtual servers up and running
simultaneously so that people can access the restored site and copy content back
to the original site.

Tagged:sharepoint restore quirkiness

2 Answers Found

Answer #1 Answered By: Yvonne Rodriquez Answered On: Feb 22, 2007

You're restoring the production database twice on the same farm, that's the
problem.

Every site has a unique identifier for the site (A Guid)

Even though they are different Virtual Servers, the Site GUIDS are stored in
the Configuration database (The farm database)

when you do it this way, the Unique Site Guid is getting introduced into the
Configuration databases sites table.

Thus the reason you're seeing the weird cycle.

Bottom line, you cannot restore the same "Site" content database twice into
the same farm.

If you need to recover those sites, you need a separate machine hooked into
a separate configuration database (A recovery farm)

Answer #2 Answered By: Elisha Abbott Answered On: Feb 22, 2007

I left out a key word in my explanation, i.e. the word
[twice] to indicate the site guid was being introduced twice into the
configuration database J

You're restoring the production database twice on the same farm, that's the
problem.

Every Site has a unique identifier for the site (A Guid)

Even though they are different Virtual Servers, the Site GUIDS are stored in
the Configuration Database (The farm database)

when you do it this way, the Unique Site Guid is getting introduced [twice]
into the Configuration databases sites table.

Thus the reason you're seeing the weird cycle.

Bottom line, you cannot restore the same "Site" content database twice into
the same farm.

If you need to recover those sites, you need a separate machine hooked into
a separate configuration database (A recovery farm)

Didn't find what you were looking for? Find more on Sharepoint restore quirkiness Or get search suggestion and latest updates.