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