locked
Searching for recommendations for moss 2007 recovery process RRS feed

  • Question

  • We currently have a single production farm, with around 190 GB of data in the content database.

    My predecessor set up nightly stsadm -o backup runs for each of the nearly 900 site collections.

    However, the length of time these are taking is growing - there are times when due to various factors it takes well over 12 hours to create the backups. When these backups are running during "prime time", users experience degraded performance.

    It has been suggested that we consider just using the SQL Server backups that also are taking place as our sole recovery strategy.

    I have only worked with stsadm -o backup (and not too successfully with it), so I am not certain of the ramifications of using only the nightly backups.

    In such a scenario, if a user comes reporting having deleted a document, list, web part on a page, etc.  will I be able to have the database folks recover the production backup to our "test" sharepoint database, then access the test site and see the data that was on the production site? Obviously, there will be issues if one has to go through a web part, infopath, etc. that has URLs from the production machine as part of the process of getting the data. Assuming that is not a factor to consider, will the restored data on the test site result in a site that looks similar to the production site?

     

    Thanks for your help.

    Tuesday, July 19, 2011 1:05 PM

All replies

  • Hi,

    You do not need to take STSADM backups of your site collections when you take the content DB backups.

    Where is your test site located? Is it in the same farm or different? If in same it will not work and will throw error because you are actually adding the same content twice with same managed path and will not work. In an alternative way you can detach the current database and then attach the database for test site to take the files out from front end.

    If you have other farm then you can create the same managed path and then you can restore the database over there.

    I hope this will help you out.

    Thanks,

    Rahul Rashu

    Wednesday, July 20, 2011 3:17 AM
  • Hi,

    You do not need to take STSADM backups of your site collections when you take the content DB backups.

    Where is your test site located? Is it in the same farm or different? If in same it will not work and will throw error because you are actually adding the same content twice with same managed path and will not work. In an alternative way you can detach the current database and then attach the database for test site to take the files out from front end.

    If you have other farm then you can create the same managed path and then you can restore the database over there.

    I hope this will help you out.

    Thanks,

    Rahul Rashu

    Thanks for the recommendation regarding stsadm vs content database. In the long term, using the content databases is probably how we will handle things.

    We have top level sites: SPprod, SPqa, and SPdev. Their content databases are on 3 different sql servers. So it seems as if we should be able to detach as you suggest.

    Will the average sql server database admin know how to detach the current database and attach the backup of prod? Or is that something that I have to do as sharepoint admin?

    If that is a function for the database admin, then is there something specifically that I will need to do so that SPdev "knows" that it is now attached to another database?  Or will I have 2 SPprod web sites that I have to deal with?

    You mention creating a managed path. I've seen that term used but I am uncertain what it means.

    Thank you for your help!

    Wednesday, July 20, 2011 2:07 PM
  • Hi

     

    For SharePoint recovery i suggest that take full form back up from central admin. And also you can take differential  backup.

    Then you can configure new server form just restore the .bak file.Everything will come.


    Thirumal Rao Dage
    Wednesday, July 20, 2011 5:44 PM
  • Where is your test site located? 

    If you have other farm then you can create the same managed path and then you can restore the database over there.

    Hi, I have some more questions, if I may.

    In our case, our production sharepoint is on one machine, while the sharepoint to which we would recovery is on a separate machine.

    Is there anything special that needs to be done for the production SQL Server backup? 

    Right now, the production SharePoint database "tables" are on the same server as other database tables. Will the recovery be able to be done just for the SharePoint tables, or will the other tables on the sharepoint instance also recover to the new machine?

    Also, if we get someone who needs a single file recovered, I presume that the sql server database admin will know how to recover the prod backup to a recovery server. What, however, needs to be done on the SharePoint side, however, to ensure that we can access the data as a sharepoint site?  The recovered content database, etc. is going to have URLs that point to the production machine, not the recovery machine. How is that handled?  Otherwise, how would I make my way through the site to the location of the file?

    You mention creating "the same managed path" but I do not know what that means. Can you help me?

    Thank you so much for your kindness.

     

     

    Monday, July 25, 2011 3:50 PM
  • One item of concern is the statements that Microsoft writes at < http://technet.microsoft.com/en-us/library/cc263427(office.12,printer).aspx#recovery > in which they state:

     

    Although the configuration database and Central Administration content database can be backed up, restoring backups of the configuration database and Central Administration content database taken from a running farm by using the tools built in to SharePoint Products and Technologies or SQL Server is not supported.

    I am uncertain what good backups are if Microsoft does not support recoveries based on them!

    Monday, July 25, 2011 4:20 PM
  • Another factor that has been brought to my attention by the database admin - right now, one of the programs that sharepoint is sharing space with on both the qa and prod sql server is MicroSoft Project Server. Apparently the two share database names, thus we cannot restore the database content to the database attached to the qa sharepoint server. So the database admin is proposing that a new instance needs to be created.

    Does this mean that I am going to need to install another version of SharePoint that points to the new instance? Or is there a way to point an existing instance of SharePoint to the new database for recovery purposes, then back to the qa database for use during the times when a recovery is not occurring?


    Monday, July 25, 2011 5:29 PM