MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

MOSS D/R solution

  Asked By: Heriberto    Date: Nov 14    Category: MOSS    Views: 834

We are running MOSS on a medium web farm. We have a single server farm
in a remote location to serve as our DR solution. I have been task with
refreshing the production data to our remote location. The servers in
our remote location have different server names. We are using SQL Server
2005. We are currently copying the production databases to our remote
database manually.

The portal is currently running at our remote location but I need to
refresh the data. This was easy to do in 2003 but it looks a little
complex in 2007. What I was planning on doing was running the
configuration wizard, and disconnect the server from the farm and then
create a new configuration database and then run the PSConfig wizard and
recreate a new Central Admin and recreate all the web applications using
new content database names (just appending the date. The old databases
were deleted from the server). Create a portal with a dummy database
and hen run stsadm -o addcontentdb and add the content databases to the
farm. Then remove the dummy content database

What is the best way to do this? If I create two portals and use the
same database names in both production and remote location, what is the
best way to refresh the databases in the remote location. In 2003, all I
had to do was delete the portal and then restore the databases with the
new data and recreate a new configuration database. In 2007 it seems
like I am recreating everything. Is that because of the configuration
database in 2007 needed to be exact.

Please help. This is just a temporary solution for us. We are looking
for a third party solution that will allow us to duplicate data in our
remote location. We are looking at VMotion but in the interim I need to
use the above solution.



4 Answers Found

Answer #1    Answered By: Lynsey Carver     Answered On: Nov 14

My recommendation is very cost effective and it will resolve your short term
issue. Since you are already looking for another solution, have you tried just
doing the SQL Log Shipping of your content DBs?

You just have to create s separate farm  on your DR side and set the config to be
the same as prod. This way, all you have to do is a DNS cut over and bring the
DBs online.

Answer #2    Answered By: Richard Allen     Answered On: Nov 14

I thought that for this solution  to work that all the hardware and
server names  had to be identical. We have a medium  server farm  in
production (2 WF2/1 IDX and a cluster SQL server) and a (1 WFT that runs
all services) in our remote  location. Even if we have the same
configuration database name, I did not think it would work since the
config db keeps track of the server  topology and it is different in the
two locations. Isn't this correct? If not please advise.

Answer #3    Answered By: Ian Davis     Answered On: Nov 14

I did this same configuration not too long ago where they had the same exact
setup you are talking about. Hardware does not need to be the same. How many web
apps do you have? Do you use host headers? Do you have DNS entries?

You will not be able to logship the configDB. This is to say that you need to
build the DR farm  just like your production  farm.

The only thing that you are going to log ship are your content databases. If you
know SQL then you can do it yourself, if not, then you need to ensure that your
SQL DBA is performing this. They are going to know how to do it.

Answer #4    Answered By: Jagjit Hui     Answered On: Nov 14

Microsoft have just published a TechNet article "Configure disaster recovery
across SharePoint farms by using SQL server  log shipping":


The article addresses a number of the issues around how this needs to be
configured, including which databases  should be shipped, and the need for a
script to detach and re-attach the content databases at intervals to make
SharePoint update its config database with any site collection changes. It
provides some options for configuring the log shipping if performance is an
issue, and describes how to apply patches.

SP2 provides some key elements to the solution. One is that, if the databases on
the destination farm  are marked as read-only, SharePoint will now automatically
mark the site collections read-only, removing all update functions from the UI.
Another is that detaching and re-attaching the content databases will not
trigger a full re-crawl of the content.

Didn't find what you were looking for? Find more on MOSS D/R solution Or get search suggestion and latest updates.