locked
SP2007 restore problem

    Question

  • Hi,

    I'm restoring from an existing sp2007 server to a new sp2007 server using the central admin functions.

    I created my farm backup thru central admin.  Then i installed sp2007 and the same service packs on my new server. 

    NB The server has a different name.  The entire farm is on the one box i.e. sql server is installed on the same box as sp2007...i have this done on the new server as well.

    I then opened central admin on my new server and restored the whole farm using the central admin restore.  I did a 'new' restore and changed all pathways to be, for example, http://newserver:85.  However when i go to the pathway it goes to a dead link.  The resore seems to have been successful in the logs.

    I have looked on google and it says about doing some more config but im confused.  Can anyone point me to the steps im supposed to do at this point.  I want to get an exact replicia of my existing farm but just on the new server.

    Thanks for help...

    • Moved by Mike Walsh FIN Thursday, June 16, 2011 4:48 PM admin q (From:SharePoint - General Question and Answers and Discussion (pre-SharePoint 2010))
    Tuesday, September 07, 2010 9:48 AM

Answers

  • Ireland75,

    A full-farm backup in SharePoint 2007 does capture all the critical components, but putting Humpty-Dumpty back together again isn't as simple as clicking through a restore wizard in Central Administration.  One of the reasons for this was mentioned by Benjamin Athawes in an earlier reply: the configuration database isn't restored.

    When you attempt to restore all components of a SharePoint 2007 farm, either through Central Administration or STSADM, you're still going to be missing some critical pieces.  The most important of these is the configuration database.  The parameters you can set in the restore wizard attempt to overcome some of these limitations by allowing you to specify new accounts, URLs, etc, but you're still missing quite a few items.  You've already run into a couple of these -- like your web parts.  Assuming the web parts were part of a solution package, those web parts were housed in the farm solution store in the farm configuration database.  Since the farm configuration database isn't restored, none of your solution packages come over to the new farm.

    Any modifications you may have made to the web.config files in your old farm will also be omitted in the restore process.  File system data (short of a search index) isn't captured as part of the full farm backup.  The web.config files you see in your new farm are auto-generated following the restore.  Any manual changes that may have been made will have to be re-applied.

    At the end of the day, you can rest comfortably knowing that the full-farm backup process will capture your content (i.e., the content databases) without issue ... and those are obviously the most important items to grab.  Once you get outside of the content databases, though, your mileage will vary based on your farm, its configuration, and how the farm has been administered.  SSPs can be brought back in most cases.  In the case of search indexes, it's oftentimes easier to simply re-crawl your content than to restore (unless you have an exceptionally large corpus).  Central admin and config databases are out.

    So, to answer the last request you made: I can confirm that a full farm restore thru Central Administration (or STSADM) *will not* restore the exact farm.  Most of us wish it did, as it would make it easier to clone environments and restore them with minimal hassle ... but most restores are "adventures" of a sort.  Sorry  :-(

     

    • Marked as answer by Ireland75 Tuesday, September 07, 2010 9:12 PM
    Tuesday, September 07, 2010 8:00 PM
  • If you get a new config database, then your original config is not restored and your customizations probably isn't either.

    Check in central administration > Solution if your solution packages were restored.

    If you have customizations installed and they aren't there then you probably get some errors.

    Make sure that everything from the original server is installed and activated.

    Cheers,


    Daniel Bugday

    Web: SharePoint Forum Blog: SharePoint By Bugday

    • Marked as answer by Ireland75 Tuesday, September 07, 2010 9:12 PM
    Tuesday, September 07, 2010 7:53 PM
  • i also see that when i do a restore...the sharepoint_config database is not restored...this seems to be by default...is there something im supposed to run...or is the config database just standard in every install.

    See my above post. Restoring a configuration database to another server farm is not supported.

    You will need to document those settings if you are restoring to a different environment.

    Restore a farm after a configuration database problem (Office SharePoint Server) provides a pretty good list of settings:

     

    • Application pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account).
    • Alternate access mapping settings.
    • Farm-level search settings.
    • External service connection settings.
    • Workflow management settings.
    • E-mail settings.
    • A/V settings.
    • Usage analysis processing settings.
    • Diagnostic logging settings.
    • Content deployment settings.
    • Timer job settings.
    • HTML viewer settings.
    • Recycle Bin settings and other Web application general settings.
    • Administrator-deployed form templates.
    • Default quota templates.
    • Database names and locations.
    • Web application names and databases. Be sure to document the content database names associated with each Web application.
    • Crawler impact rules.
    • Activated features.
    • Blocked file types.

     

     

     


    Benjamin Athawes
    Twitter
    SharePoint Blog

    • Marked as answer by Ireland75 Tuesday, September 07, 2010 9:12 PM
    Tuesday, September 07, 2010 7:57 PM

All replies

  • Hi,

    did you update the Alternate Access Mappings.

    Cheers,


    Daniel Bugday

    Web: SharePoint Forum Blog: SharePoint By Bugday

    Tuesday, September 07, 2010 10:46 AM
  • Hi,

    The alternative access mappings says -

    (internal url)                           (public url for zone)

    http://newserver:85  default http://newserver:85

     

    Should this be different?  There are some entries there from the old server but i presume this doesnt matter?

     

    Tuesday, September 07, 2010 1:02 PM
  • Seems correct.

    If you don't need the old entries, then try to remove them.

    Also take a look at this links:

    Restore a farm by using built-in tools (Office SharePoint Server 2007)
    Restore a farm by using Central Administration (Office SharePoint Server 2007):
    Cheers,

    Daniel Bugday

    Web: SharePoint Forum Blog: SharePoint By Bugday

    Tuesday, September 07, 2010 1:49 PM
  • An alternative approach would be a backup and restore using SQL tools.

    Back up and restore an entire farm (Office SharePoint Server 2007)

    In this scenario, you basically backup each database, attach them to the new SQL server and add them in SharePoint central admin.

    In addition to restoring the content you will also need to restore any SharePoint artefacts and configuration settings: off the top of my head this includes web.config settings, features, site templates, site definitions, custom styles and custom images.

    Let me know if you have any specific queries about a SQL restoration as I have successfully used this option several times in the past.

    HTH.


    Benjamin Athawes
    Twitter
    SharePoint Blog

    Tuesday, September 07, 2010 4:54 PM
  •  

    Hi,

    Thanks for all responses.

    What i want to do is restore my sharepoint 2007 farm exactly as is on another server...and from what i gather here is that i can not do this using the sharepoint backup/restore...is this correct.

    Is there no way to use the backup i have taken through central admin...and get up and running on my new server. 

    If not then i really dont see why there is a backup/restore tool if it doesnt work correctly.  I figured i could use this tool to make farm backups and then if my server ever went down i could get back up and running SOLELY using the backup.  Is this not possible.

    I have been taking backups using central admin for some time and now decided to test whether all was okay...i am now very disappointed that this does not work as it says on the tin.  You would seriously imagine that a complete farm backup means what it says.

    All insight appreciated...hopefully i am missing something.

     

    Tuesday, September 07, 2010 6:32 PM
  • You did everything correctly and the steps you describe sounds correct.

    You can backup/restore sharepoint using the built-in tools.

    Did you check the links i specified in an earlier post?

    What exactly is your error message you get when you said:

    "However when i go to the pathway it goes to a dead link" ?

    Cheers,


    Daniel Bugday

    Web: SharePoint Forum Blog: SharePoint By Bugday

    Tuesday, September 07, 2010 7:06 PM
  • OK, just to be clear here, restoring a configuration database to another server farm is not supported.

    The backup and restore options are there so that you can successfully recover your existing farm in the event of disaster - not create a new farm using the config backup. So in answer to your question, the backup/restore tools to work correctly so long as you are recovering the farm from which the backups were taken.

    This limitation is mitigated - but not removed - in SharePoint 2010 with the inclusion of a "configuration only" backup capability.

    The limitation is there due to environment specific settings being retained in the config DB - and that includes server names.

    Microsoft's answer in MOSS is to ensure all settings are correctly documented.

    Of course, this only applies to the configuration DB; you can happily backup and restore content to your new MOSS farm without any issues.


    Benjamin Athawes
    Twitter
    SharePoint Blog

    Tuesday, September 07, 2010 7:30 PM
  •  

    hi,

    its a 404 error.  yes i checked the links and this is exactly how i restored per the links.

    what also concerns me is when i go to the web.conifg in my new intranet site - which was at http://oldserver and i have now at http://newserver:85 - it looks nothing like my old web.config file with all the custom webparts etc i have installed listed...it instead looks like the default web.config file of a fresh install. 

    i also see that when i do a restore...the sharepoint_config database is not restored...this seems to be by default...is there something im supposed to run...or is the config database just standard in every install.

    can i also get confirmed that the full farm restore thru central admin will restore the exact farm which makes the backup i.e. including all customisations and webparts installed.

    thanks for all help...

     

    Tuesday, September 07, 2010 7:46 PM
  • If you get a new config database, then your original config is not restored and your customizations probably isn't either.

    Check in central administration > Solution if your solution packages were restored.

    If you have customizations installed and they aren't there then you probably get some errors.

    Make sure that everything from the original server is installed and activated.

    Cheers,


    Daniel Bugday

    Web: SharePoint Forum Blog: SharePoint By Bugday

    • Marked as answer by Ireland75 Tuesday, September 07, 2010 9:12 PM
    Tuesday, September 07, 2010 7:53 PM
  • i also see that when i do a restore...the sharepoint_config database is not restored...this seems to be by default...is there something im supposed to run...or is the config database just standard in every install.

    See my above post. Restoring a configuration database to another server farm is not supported.

    You will need to document those settings if you are restoring to a different environment.

    Restore a farm after a configuration database problem (Office SharePoint Server) provides a pretty good list of settings:

     

    • Application pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account).
    • Alternate access mapping settings.
    • Farm-level search settings.
    • External service connection settings.
    • Workflow management settings.
    • E-mail settings.
    • A/V settings.
    • Usage analysis processing settings.
    • Diagnostic logging settings.
    • Content deployment settings.
    • Timer job settings.
    • HTML viewer settings.
    • Recycle Bin settings and other Web application general settings.
    • Administrator-deployed form templates.
    • Default quota templates.
    • Database names and locations.
    • Web application names and databases. Be sure to document the content database names associated with each Web application.
    • Crawler impact rules.
    • Activated features.
    • Blocked file types.

     

     

     


    Benjamin Athawes
    Twitter
    SharePoint Blog

    • Marked as answer by Ireland75 Tuesday, September 07, 2010 9:12 PM
    Tuesday, September 07, 2010 7:57 PM
  • Ireland75,

    A full-farm backup in SharePoint 2007 does capture all the critical components, but putting Humpty-Dumpty back together again isn't as simple as clicking through a restore wizard in Central Administration.  One of the reasons for this was mentioned by Benjamin Athawes in an earlier reply: the configuration database isn't restored.

    When you attempt to restore all components of a SharePoint 2007 farm, either through Central Administration or STSADM, you're still going to be missing some critical pieces.  The most important of these is the configuration database.  The parameters you can set in the restore wizard attempt to overcome some of these limitations by allowing you to specify new accounts, URLs, etc, but you're still missing quite a few items.  You've already run into a couple of these -- like your web parts.  Assuming the web parts were part of a solution package, those web parts were housed in the farm solution store in the farm configuration database.  Since the farm configuration database isn't restored, none of your solution packages come over to the new farm.

    Any modifications you may have made to the web.config files in your old farm will also be omitted in the restore process.  File system data (short of a search index) isn't captured as part of the full farm backup.  The web.config files you see in your new farm are auto-generated following the restore.  Any manual changes that may have been made will have to be re-applied.

    At the end of the day, you can rest comfortably knowing that the full-farm backup process will capture your content (i.e., the content databases) without issue ... and those are obviously the most important items to grab.  Once you get outside of the content databases, though, your mileage will vary based on your farm, its configuration, and how the farm has been administered.  SSPs can be brought back in most cases.  In the case of search indexes, it's oftentimes easier to simply re-crawl your content than to restore (unless you have an exceptionally large corpus).  Central admin and config databases are out.

    So, to answer the last request you made: I can confirm that a full farm restore thru Central Administration (or STSADM) *will not* restore the exact farm.  Most of us wish it did, as it would make it easier to clone environments and restore them with minimal hassle ... but most restores are "adventures" of a sort.  Sorry  :-(

     

    • Marked as answer by Ireland75 Tuesday, September 07, 2010 9:12 PM
    Tuesday, September 07, 2010 8:00 PM
  • Also check this link:

    Restore a farm after a configuration database problem (Office SharePoint Server):
    Then you just install all your customizations
    Here's the link to the KB Benjamin refers to:
    You can follow the steps here to do manual restoration of the configuration database:

    Daniel Bugday

    Web: SharePoint Forum Blog: SharePoint By Bugday

    • Edited by Daniel Bugday Tuesday, September 07, 2010 8:10 PM addes spaces
    Tuesday, September 07, 2010 8:10 PM
  • Here's the link to the KB Benjamin refers to:

    Cheers Daniel - I didn't realise there was a KB specifically stating that. Very convenient :-).

    "Restoration of the configuration database by using the built-in backup and restore functionality is not supported in SharePoint Server 2007 or in Windows SharePoint Services 3.0"


    Benjamin Athawes
    Twitter
    SharePoint Blog

    Tuesday, September 07, 2010 8:16 PM