Part 2 - Restore Prod to Test (backup and restore)

If you are completely new to backup and restore you might want to review my rant here: http://paisleypoint.blogspot.com/2009/03/back-up-and-restore-repeatable-process.html

Part 2 - Restore Prod to Test – for data population Assumptions – there is an existing instance of a test server – that will get the prod content db written over it. Ensure you have the same updates and services packs as on the test server as were installed on the prod server. (Make sure you run the configuration updates after the service packs)
Preparation
If you have a website for the portal – use the central admin web ui to delete it – and any databases associated with it

1. Create a new web application
Central Admin -> Application Management -> Create or Extend Web Application -> Create a new Web Application DON’T forget the Host Header
Host header: Lab-Portal
Pool ID: spdev\!spFarmAcct
1.1 When you get to the database name, put in a temporary name such as WSS_Portal_DeleteMe. You will delete this database later.

2. Restore your prod content database (leave the existing shared services database). Don’t worry about the search database. You will have to recrawl your website anyway. --MAKE SURE THE DATABASE NAMES ARE EXACTLY THE SAME AS THEY WERE ORIGINALLY

If you get an error like so: SPException: Cannot attach database to Web application, you can use the Central Administration ui (or if you enjoy torture use the command line tool) to attach the database manually to the proper Web Application.

3. Next step is to remove the temp database from each web application and attach the real database you restored in step 2 --To do this Go to Central Administration -> Application Management -> Content Databases
3.1 Remove the temp db - Select the web application you would like to change. Select the database name (for example WSS_Portal_DeleteMe). Check the box in the next screen to remove content database. You should now see no database attached to the web application (it also remove it off the sql server).

4 Connect to the restored db - Select add a content database. For the database name put the name in EXACTLY as you restored it which should be EXACTLY like it originally was.

5. Don’t worry about the Search Server field since you have not started that service yet.
6. Start required services on new server. Go to Central Administration -> Operations -> Services on Server. Start the Windows SharePoint and Office SharePoint searches. Let it create a new database.
7. Recreate the SSP -Central Admin -> App Management -> Manage this farm's shared services (Click in the Shared Services link on the left!).
8. Select Create SSP – You can use the same name before SharedServices1 or change it. I would leave it so it matches the DB name) Make sure you select your SSPadmin and MySite web applications your created earlier and your restored database names. Do I have to mention again to make sure the names are exact!
9. Select the index server (it is now available since you started the service). You will get a warning stating you are changing the association of the existing web applications. Click OK.
10. Install Branding customizations
11. Open your SSP website and start a full crawl and user import. You should notice that all your SSP settings are still there.
12. Since you did not restore the Sharepoint_AdminContent database you will have recreate things like smtp server names. These are all easy things that can be found off the main Central Admin Page. You should even go through the steps they list and complete each one.You should now have a fully functioning SharePoint site on a new server with a new sql server.

Back up and restore -Repeatable Process

Note this is a rant - it has some good background info for those who are pretty green at Sharepoint Admin -BUT if you know already know your way around an stsadm script - or the central admin UI you can skip to the actual steps in the Step by Step instructions

OBVIOUSLY we know that it's not a good idea to do development on a production sharepoint server- but the sharepoint platform makes it a bit tricky to avoid the temptation, since it seems that is what the tool was intended to be used for, and since you never quite have the same stuff on dev that you have in prod, you just might succumb to such tempations. Here are MY reasons why you should NEVER do it...

After deploying a solution-you will need to do an IISReset -- be prepared to get a scathing email (with your boss cc'd) from that unix admin type who hates sharepoint becuase he JUST happened to hit the site during that 5 second period. Worse yet - what if you screwed something up? - Be prepared to get an email from everybody in the company saying - "I can't get to my documents - sharepoint is down" (as if you didn't already know you screwed yourself)

SO - that said, I set out to follow Joel's recommendations on WHAT to do from the following article: http://blogs.msdn.com/joelo/archive/2008/01/15/pilots-proof-of-concepts-test-and-pre-production-environments.aspx Where Joel says "Although you may not find many references to dev, test, staging, environments (in sharepoint development), these are critical to large deployments..." I couldn't agree more --HOWEVER I had to piece together my own version of HOW to do it. Here is what I came up with - complete with some of the sharepoint hate I experienced along the way - maybe I can shield some others of you from some of that pain...

On the Official Microsoft Technet site, there are some failry helpful instructions here:
http://technet.microsoft.com/en-us/library/cc262946.aspx
These are aimed at people actually doing recovery of content howvere - after something got lost (probably becuase they were doing dev on production). This is not exactly what I was after so I had to do some extrapolation to get it to serve my purposes...

Basically there were 2 very basic steps I wanted to follow:
1. backup the prod server
2. restore the prod server to a dev site

Couldn't be simpler right?
1. backup the prod server (BUT WHAT?)
If you look into sql server you will see several db's
--the config db (whichs stores all the enviroment specific stuff. So you DON'T want to copy that over because that is what you are trying to change)
-- the content db for The central admin (the the one with the long guid in it which you don't need - central admin is central admin)
-- the content db for the ssp(s) (I don't have alot configured in my ssp yet so I didn't need that especially since the dev server I am restoring to is on a different domain - I wanted to keep the configurations in my dev enviro and the dev user store)
-- The content db for the site collection(s) - That is the content I was after the actual data in the portal.

If you need help seeing what you have, go the the Central Admin -> Operations -> Perform a backup (under "Backup and Restore) this gives a nice visual of what there is to backup. From the first screen - you can look at it without actually doing any backing up yet.

So the three ways to do this are:
::backup the content db in the sqlmanagment studio (which is fine if you are a dba type - but "not so much" for me)
::backup using the stsadm command line tool (fine if you are a command line type -even better if you are trying to create a script to automate this - but again - not so much for me)
::backup using the Central Admin Web UI -(this is a great way if you want to walk through the steps as they are happening-unfortunatley the Central Admin UI makes it damn near impossible to do this without pulling you hair out for a week because as we know when you get errors, Sharepoint will send you on a wild goose chase tring to decipher what is going on (wrong) in the background, burrying any actual useful information in log files or behind the custom error - stack trace curtain. Here are some tips for better deciphearge -- http://furuknap.blogspot.com/2008/11/debugging-tips-for-sharepoint.html

Oh you thought that was it? No thats just the backup part - the restore part is equally fun
2. restore the prod server to a dev site
Once you have your precious backup files - then you will need to restore them and get sharepoint to make the adjustments to read the content from your dev server's point of view. Just wave the magic wand! Or if that doesn't work, try the following...

Again the three ways to do this are:
::restore the content db in the sqlmanagment studio
::restore using the stsadm command line tool
::restore using the Central Admin UI (guess which one I like?)

This post should probably be officially labeled a "RANT" so I decided to put the actual steps into a separate "step by step" post for use when actually performing the steps

Step by Step instructions

References for Backup and Restore

Man did this give me fits!
Until I have time to write out what I came up with
here are the articles I am referencing:

yea - this is what I want to do...
http://blogs.msdn.com/joelo/archive/2008/01/15/pilots-proof-of-concepts-test-and-pre-production-environments.aspx

but how????

I tried the command line - got errors:
backup
http://technet.microsoft.com/en-us/library/cc263441.aspx
restore
http://technet.microsoft.com/en-us/library/cc671617.aspx
How to Recover a Windows SharePoint Services Farm
http://technet.microsoft.com/en-us/library/bb795596.aspx
Back up a farm by using built-in tools (Office SharePoint Server 2007)
http://technet.microsoft.com/en-us/library/cc263298.aspx
Move content databases between instances of SQL Server (Windows SharePoint Services 3.0)
http://technet.microsoft.com/en-us/library/cc288554.aspx

I tried to use the backup and restore utils in sharepoint central admin
-got access denied errors
http://technet.microsoft.com/en-us/library/cc262946.aspx
http://www.windows-tech.info/15/b0dffeee963e602d.php



this is a good comprehensive one - but I did not like having to re run the config wizard
http://lkar.blogspot.com/2008/05/moving-moss-project-server-2007.html

this one is even better - step by step (simple) NOTE THE PART ABOUT NOT CHANGING THE DB NAME??? not sure if that is true
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/MS-SharePoint/Q_23185385.html#a21129547

this is a good one
http://office12.blogspot.com/2007/05/when-sharepoint-2007-restore-fails.html

at the end I was getting an error while restoring (after the restore - but during the attch to the website)-http://www.sharepoint-girl.com/2007/12/error-on-restoring-wsscontent-database.html

restore MOSS 2007 problem: IIS Web Site already in use by Sharepoint
http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/6f75daf7-1b84-43ed-a98c-280d5afc35b4/

others
http://www.eggheadcafe.com/software/aspnet/33771569/backup-and-restore-from-t.aspx

this one is backwards
http://blogs.msdn.com/priyo/archive/2008/01/14/move-moss-2007-from-test-to-production.aspx


this guy had fits too
http://wss.made4the.net/archive/2008/05/26/solution-development-in-sharepoint-2007.aspx

cool deployment tool - on codeplex
http://www.codeplex.com/SPDeploymentWizard