This is EXACTLY what I was going to reply. The SSP is not really "mysite," despite what doco says. It simply holds a REFERENCE to a mysite url, and has the bounce page to auto-create them.
The mysites can be restored perfectly even after rebuilding your SSP from scratch. On Thu, Jan 29, 2009 at 12:24 PM, Paul Turner <[email protected]>wrote: > Each 'My Site' is a seperate site collection and as such can be backed up > with stsadm independantly. Create a batch file and run it nightly then you > can get seperate backups of each 'My Site' and restore then if needed > without doing a full DB (sql level backup/restore). > > See here for a demo: > http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/73759029-c256-4797-a716-33f7a61fdbdb/ > > Regards > *Paul Turner > **Senior Solution Specialist** > M:* 0412 748 168 *P:* 08 8238 0912 *F: *08 8234 5966 > *A:* 66 Henley Beach Road, Mile End SA 5031 > *E:** ** [email protected]* *W:* > www.sdm.com.au<https://adlex01/exchweb/bin/redir.asp?URL=http://www.sdmcom.au/> > ------------------------------ > *From:* [email protected] [[email protected]] On Behalf Of Paul Noone [ > [email protected]] > *Sent:* Thursday, 29 January 2009 8:01 AM > > *To:* [email protected] > *Subject:* RE: SSP Restore > > Hi Simon, > > > > I would say that anyone using MySites extensively would agree. > > > > What was the solution? Simply building a new web app and pointing it to the > restored DB? > > > > It would be great if you could outline this broadly for the rest of us, or > just me if you like, so I can add it to our DR plan. J > > > > Regards, > > Paul > > Online Developer, ICT > CEO Sydney > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Simon > Ashworth > *Sent:* Wednesday, 28 January 2009 4:13 PM > *To:* [email protected] > *Subject:* RE: SSP Restore > > > > > > We actually spent hours with Microsoft support with this one and > successfully managed to restore the SSP back to its former glory BUT not > without a great amount of work. I was attempting to use the same web > application to run the SSP which didn't quite work, so a new app had to be > created. The upshot is that everything in central admin works, all SSP tasks > (indexing, searches, AD imports & audiences) are restored as well as all > previous 'My Site' creations. I guess it may have been quicker & easier to > rebuild the SSP from scratch, but losing My Sites wasn't an option for us! > > > > > > *Simon Ashworth* > Senior Developer > > *Vivid* *Group* > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Paul > Noone > *Sent:* Wednesday, 28 January 2009 6:51 AM > *To:* [email protected] > *Subject:* RE: SSP Restore > > > > Well that's good to know. It's a pity there white paper (page 47) on data > protection and recovery doesn't provide the same advice. > > > > Small wonder I've been having issues. > > > > 8ß--- > Considerations when restoring an index server > > To restore an index server, in Step 3, "Restore the Web application," you > must restore the SSP associated with the index. > > > > *Restore an SSP* > > 1. > ------------------------------ > Support procedure: https://www.codify.com/lists/support > List address: [email protected] > Subscribe: [email protected] > Unsubscribe: [email protected] > List FAQ: http://www.codify.com/lists/ozmoss > Other lists you might want to join: http://www.codify.com/lists > style='font-family:"Verdana","sans-serif"; color:black'>Open Central > Administration, and on the *Operations* tab, in the *Backup and > Restore*section, select > *Restore from Backup*. > > 2. On the Step 1: Select Backup Location page, under *Backup File > Location*, specify the path to the backup folder. > > 3. On the Step 2: Select Backup to Restore page, select the most recent > backup package to restore, and then click *Continue Restore Process*. > > 4. On the Step 3: Select Component to Restore page, select the SSP to > restore and then click *Continue Restore Process*. > > 5. On the Step 4: Select Restore Options page, click *Same > Configuration*, and then click *OK*. Click *OK* again in the *Warning*dialog > box. > > 6. The *Backup and Restore Status* page appears. This page is refreshed > every 30 seconds. The recovery can take a few minutes to start. > > *Note*: If either the content index or search database recovery process is > not successful, you must reset the index and perform a full crawl before > search and indexing will work. > > > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Bill > Williamson > *Sent:* Tuesday, 27 January 2009 11:02 PM > *To:* [email protected] > *Subject:* Re: SSP Restore > > > > We've never had SSP restores work. MS advised us that recreation of the > SSP from configuration documenation is the supported methodology. > > On Thu, Jan 22, 2009 at 1:56 PM, Simon Ashworth <[email protected]> > wrote: > > Hey Guys, > > > > I'm currently performing a migration of an SQL server including all MOSS > 2007 config and content databases. I've used a technet article > http://technet.microsoft.com/en-us/library/cc512725.aspx that states a > process to use for the migration but have fallen foul at the final stage – > restoring the original SSP. The high level process I have followed (as per > the article) is: > > > > · Perform an SSP backup via Central Admin > > · Used STSADM to remove SSP from the farm > > · Stopped farm services > > · Performed SQL backups of all content and configuration dbs > > · Restored database (via SQL) to new server > > · Recreated SQL users & permissions > > · Used STSADM renameserver command specifying new SQL server > > · Restarted Central admin server > > · Restore SSP via Central Admin > > > > I can access the Central Admin site and also browse to the web apps and can > confirm that these are running off the new SQL server, all good here, but > the final step (the SSP restore) appears to hang stating that the SSP is 30 > percent complete but goes no further. I left the job running overnight but > I believe the timer service cancelled it after running for 9 hours. I've > since attempt the restore numerous times with different accounts (just in > case the issue was permissions based) still with no luck. I've checked the > SharePoint logs, event logs and SQL logs but can't see anything pointing > towards a resolution. Can anyone offer some advice? > > > > For information the SQL servers in question are at the same version/SP > level (SQL 2005 SP2). > > > > Simon Ashworth > > > ------------------------------ > > Support procedure: https://www.codify.com/lists/support > List address: [email protected] > > Subscribe: [email protected] > > Unsubscribe: [email protected] > > List FAQ: http://www.codify.com/lists/ozmoss > > Other lists you might want to join: http://www.codify.com/lists > > > ------------------------------ > > Support procedure: https://www.codify.com/lists/support > List address: [email protected] > > Subscribe: [email protected] > > Unsubscribe: [email protected] > > List FAQ: http://www.codify.com/lists/ozmoss > > Other lists you might want to join: http://www.codify.com/lists > ------------------------------ > > Support procedure: https://www.codify.com/lists/support > List address: [email protected] > > Subscribe: [email protected] > > Unsubscribe: [email protected] > > List FAQ: http://www.codify.com/lists/ozmoss > > Other lists you might want to join: http://www.codify.com/lists > ------------------------------ > Support procedure: https://www.codify.com/lists/support > List address: [email protected] > Subscribe: [email protected] > Unsubscribe: [email protected] > List FAQ: http://www.codify.com/lists/ozmoss > Other lists you might want to join: http://www.codify.com/lists > -------------------------------------------------------------------------------- Support procedure: http://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists
