Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Sharepoint restore quirkiness

  Asked By: Dominique    Date: Feb 22    Category: Sharepoint    Views: 468

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.

Share: 

 

2 Answers Found

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

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

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.




Tagged: