none
Protecting Sharepoint 2010 with DPM 2010 - Missing something? RRS feed

  • Question

  • Hello,

    I am wondering if someone can shed some light on configuring protection for Sharepoint using DPM 2010. I have been using the DPM products for a long time now and feel I have a very good knowledge of it. However my company has not used Sharepoint untill recently and so, I have just started to try an protect Sharepoint using DPM.

    I have followed instructions and white papers, however I seem to get the same result, and I am not sure if this is the result I am suppose to get. After installing the agents on the SP servers in the environment, then configuring sharepoint protection on the web I go to create a protection group, however only the SP Config appears. Inside this config  is usually just AdminContent, SP_Config and WSS_Content. However when I look under SQL there is a slew more DB's for SP?

    I guess my question / concern is, should DPM's SP protection be automatically protecting those extra DB's or does it only protect the three mentioned above.

    If that is all DPM protects, what is best practice for backing up the Sharepoint environment? SP protection, SQL protection, System State?

    Or is there something my SP Admin should be configuring?

    Anyones help would be greatly appreciated!

    Thanks
    Thursday, May 5, 2011 1:32 PM

All replies

  • James

    Firstly, DPM is designed to protect all content databases in a sharepoint farm. From your description above, it is clear that you have performed the configuration steps for the farm correctly and you are able to select the farm for protection. However, since you are unable to see the content databases being backed up, there could be 2 reasons for this.

     

    1. If the content databases are on a SQL server which is on a different server than the WFE, you need to ensure that you install and configure the DPM protection agent on all such backed SQL servers.

     

    2. If the content databases were added to the farm using SQL aliasing, and you are on Sharepoint 2007, you need to install SQL 2005 client connectivity components on the WFE. Once you do this, ensure that the aliases are indeed configured properly by remotely connecting to the SQL instance from the WFE using the alias. If yo u are able to connect to tthe instance, it means your alias is configured properly.

    Please retry protection of the farm once you do these 2 steps, whichever is appropriate.

    Roopesh

     

    Monday, May 9, 2011 5:45 AM
    Moderator
  • Hi Roopesh,

    Thanks for responding to my question. I have posted this same message on a few different boards and you are the first to actually answer. I am interested in your number 2 response. I know i have installed agents on all the servers in the SP environment, however I am not the SQL or SP admin so I am not sure about those products configuration.

    However the one thing I can tell you is that SP is using SQL2008. Is there something similar to SQL2005 client connectivity that needs to be installed or turned on with 2008?

    Your help is greatly apreciated!

    Thanks

    James

    Monday, May 9, 2011 7:58 PM
  • Roopesh, i forgot to mention that it is Sharepoint 2010 w/ SQL2008... Protected by DPM2010 ver: 3.0.7707.0.

    The SP environments consist os 2 or 3 machines. Usualy a Web, Index and SQL server. some only have the Web and SQL. DPM agents are installed on all boxes... Several of the contecnt DB's are being setup by SP with aliases...

    Hope this extra info helps...

    Monday, May 9, 2011 8:09 PM
  • James

    For Sharepoint 2010 you do not require the client connectivity components to be installed. I would still want you to check if you are able to remotely connect to the SQL instance from the Sharepoint WFE using SQL management studio and using the alias to ensure that the alias is configured properly.

    The other thing to check is if the SQL writer is actually running on all backend machines. If you expand the SQL server node from DPM for the backend server where the content DBs exist do you see all databases getting listed?

    Also you can go to Program Files\Microsoft Data Protection Manager\DPM\temp on the WFE and look up the WssCmdletsWrapperCurr.errlog and dpmracurr.errlog to see if there are any errors that are getting reported by DPM when you attempt the farm protection.

    Also are the backends which you are talking about mirrored? If so the agent needs to be installed on all mirrored backends as well.

    Roopesh

     

    Wednesday, May 11, 2011 6:53 AM
    Moderator
  • James

    Taking a step back, can you tell me what DBs are actually not getting backed up? Are these DBs those which you added to the farm as content databases ?

     

    -Roopesh

    Wednesday, May 11, 2011 1:54 PM
    Moderator
  • Hi Roopesh,

    Here is one of the SP Environments I am attempting to back up. It consists of three servers, a Index (IDX01), Web (WEB01) and Sql (SQL01). Agents are installed on all three. I ran the configureSP command  plus others on the WEB01 machine. When I go to create my PG the only DB's that appear under the SP Data are:

    Sharepoint_Admin_HEX#

    Sharepoint_Config_Prd1

    WSS_Content

    WSS_Content_Collaboration_Sites

    WSS_Content_Dev_sandbox

    WSS_content_My_sites

    WSS_content_Home

     

    This is surprisingly more than before. In the past just the SP_Config, WSS_Content and WSS_content_collab would show up.

     

    However, under the SQL there are 22 other databases (including system db’s) that do not show up. Each one of them have a descriptive name and then a Hex#.

     

    Application_Registry_service_DB_Hex#

    BDC_Service_DB_Hex#

    Managed Metadata_Service_Hex#

    Master

    Model

    MSDB

    PerformancePoint Service Application_Hex#

    ProfileDB

    Search_Service_Application_CrawlStoreDb_Hex#

    Search_Service_Application_DB_Hex#

    Search_Service_propertyStoreDB_Hex#

    Secure_Store_sevice_DB_Hex#

    SocialDB

    StateService_Hex#

    Sync DB

    User Profile Service Aplication_ProfileDB_Hex#

    User Profile Service Aplication_SocialDB_Hex#

    User Profile Service Aplication_SyncDB_Hex#

    WebAnalyticsServiceApplication_reportingDB_Hex#

    WebAnalyticsServiceApplication_StagingDB_Hex#

    WordAutomationservices_Hex#

    WSs_Logging

     

    I am also starting to experience and issue with a couple of the SQL backups for these DB’s where the error message says the name is too long.

     

    Anyway, not worried about that, just the SP thing really.

     

    Thanks

    Jamie

     

    Wednesday, May 11, 2011 3:03 PM
  • James

    You need not worry about backing up these databases. As long as all the content databases which you have explicitly added are getting backed up by DPM, you should be fine.  The sharepoint config databases, which are necesasary for making the farm recovery complete are backed up by DPM.

     

    Roopesh

    This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, May 11, 2011 3:38 PM
    Moderator
  • So am I to understand that if I were to recover my Sharepoint backup right now those DB's would appear? Or am I suppose to be performing a SQL backup in conjunction with the Sharepoint?

    Wednesday, May 11, 2011 5:52 PM
  • James

     

    These DBs will appear or get recreated when you go through the farm configuration wizard of Sharepoint 2010. These are system databases which are used by sharepoint for managing the farm / WFE and there is no interesting state information in them to be backed up or restored.

    To give you further technical explanation, DPM backs up only those databases which are reported by the Sharepoint VSS Writer as "required for backup". In other words, the databases that really need to be backed up in a farm is decided and published to DPM by the sharepoint VSS writer and DPM backs up everything that is reported.

    So in a scenario where you have lost your farm completely and you do an original location recovery from DPM, the configuration of the farm will be recovered which includes the admincontent DB and the Config DB along with the all content databases. Once this is done and you go ahead and connect the WFE to this existing config db, at the end of this sharepoint configuration wizard you should see all the management databases getting recreated. Hope this clears the doubt.

    If you feel this answers your queries, please go ahead and mark this as the answer for the thread.

    Roopesh

    This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, May 12, 2011 5:45 AM
    Moderator
  • Hi Roopesh,

    I'm afraid I still don't understand. When I open my sharepoint backup I do not see all the SQL databases associated with the SP environment. Why would this be.

    If my SP environment crashed and I had to restore. Would all the DB's (that do not appear under the SP backup) be recreated. If so why can I not see them under the SP backup? What if I needed to recover an individual database... How do I locate it under the SP backup?

    Do I need to perform a SQL backup in conjunction with the SP backup?

    Thursday, May 19, 2011 2:00 PM
  • Hi, you will not see all the databases in the SharePoint Backup. For example several of the databases you listed in the other comment are belonging to SPsearch/SPProvider and/or SharePoint Application services. Those will not be included in the SharePoint Backup. What is included is the admin/config_db in addition to all content databases which are listed in the config_db. So in case you deattached a content database in SharePoint central application it will not be part of your SharePoint backup. In addition any custom database (from customization like Nintex workflows/ custom created apps...) are not included in the SharePoint backup. In SharePoint 2007 there was the possibility to backup serach/SPprovider up directly using DPM. In SharePoint 2010 you would have to create a serach/index backup from the Central administraiton and then you are able to protect this output file via DPM. So in case you need a recovery for search you will have to restore the backup and then use cental admin to restore search. So what I am doing is I created a SharePoint Backup to protect all content_db + admin/config_db. For all the other databases in my SharePoint environment (beside the Search ones) I configured SQL "auto" protection. Do not worry - any new content_db will always automatically be attached to the SharePoint backup and not to the SQL "auto" protection backup. Also keep in mind that you have to include the 14 hive (or 12 hive for older) in addition to IIS metadata like inetpub and any folder with customization into the backup. Otherwise you will not be able to recover a function SharePoint environment in a DR scenario. All backups have to have the same time stamp for a DR scenario.
    Friday, May 20, 2011 11:36 AM