none
Item level recovery fails - unable to create database RRS feed

  • Question

  • I am trying to recover a file from a Sharepoint 2013 Farm without using a recovery farm.

    I can see the file in DPM.

    I have set the recovery to go to a different SQL instance than the production farm which has nothing but the system databases created on it plus a database called TMPRecover. I have granted the Network Service account DBCreator and Sysadmin roles as well as dbowner and dbsecurityadmin roles for the master database and the TMPRecover database.

    I am selecting this as the instance to attach to when specifying the temporary server.

    The recovery seems to start OK but then fails with the error below. Not sure where else to be looking to get this to work.

    Affected area: Sharepoint Farm\SPSQL\SharePoint_Config
    Occurred since: 09/01/2014 19:05:20
    Description: The recovery jobs for SharePoint Farm Sharepoint Farm\SPSQL\SharePoint_Config that started at 09 January 2014 19:01:55, with the destination of gallow-sp01.gallowglass.local, have completed. Most or all jobs failed to recover the requested data. (ID 3111)
     DPM was unable to attach the database to the SQL Instance NAVTMPSQL. CREATE DATABASE permission denied in database 'master'. (ID 32000 Details: Unknown error (0x80040e14) (0x80040E14))
     More information
    Recommended action: 1) Check to see that the specified instance of SQL Server is online.
    2) If your SQL database files do not have the .mdf, .ndf, and .ldf extensions for the primary data file, secondary data file, and log file, respectively, then DPM will not be able to attach the database to the specified SQL Instance.
     On the Jobs tab in the Monitoring tasks area, group jobs by type to view details of the recovery jobs.
     Retry the recovery job...


    Darren

    Thursday, January 9, 2014 7:30 PM

Answers

  • Hi,

    Reviewing the DPMRACurr log on the target server during the Date/Time of restore may assist with potential paths to why the job is failing. The logs can be found in the following path on the target server <DPM Install path>/Program Files Microsoft Data Protection Manager/DPM/Temp

    The logs may uncover why we face the current issue. For example the following “ATTACH " – Failed <and also reason why>

    Also the DPM server MSDPMCurr log during the Date/Time of restore may also assist with the issue you face. For example the following may be seen “MountDatabaseFailed”

    Also note the below process is carried out with the method of restore which was used.

    DPM restores the DB to the destination SQL server once the DB is attached, then the restore process is complete and now will be SharePoint front end server connecting to that DB using the account that was setup with configuresharepoint.exe -enablesharepoint protection. That account needs permissions to connect to that database. The attach phase itself is using the system account from DPMRA process on the local SQL Server.

    If you identify the issues are permission related first ensure the DPMRA service [logon account] has access within SQL for the SQL instance that we are restoring to this account will need DB creator for the following system DB master.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Dwayne Jackson II. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights."


    Thursday, January 9, 2014 8:55 PM

All replies

  • Hi,

    Reviewing the DPMRACurr log on the target server during the Date/Time of restore may assist with potential paths to why the job is failing. The logs can be found in the following path on the target server <DPM Install path>/Program Files Microsoft Data Protection Manager/DPM/Temp

    The logs may uncover why we face the current issue. For example the following “ATTACH " – Failed <and also reason why>

    Also the DPM server MSDPMCurr log during the Date/Time of restore may also assist with the issue you face. For example the following may be seen “MountDatabaseFailed”

    Also note the below process is carried out with the method of restore which was used.

    DPM restores the DB to the destination SQL server once the DB is attached, then the restore process is complete and now will be SharePoint front end server connecting to that DB using the account that was setup with configuresharepoint.exe -enablesharepoint protection. That account needs permissions to connect to that database. The attach phase itself is using the system account from DPMRA process on the local SQL Server.

    If you identify the issues are permission related first ensure the DPMRA service [logon account] has access within SQL for the SQL instance that we are restoring to this account will need DB creator for the following system DB master.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Dwayne Jackson II. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights."


    Thursday, January 9, 2014 8:55 PM
  • Thank you so much for that. The issue was permissions related. Once I gave DB Creator to the DPMRA account and also permissions for the Sharepoint Farm account on the temporary SQL instance server the restore worked.

    Wouldn’t it be nice if the DPM team sorted out the links in the “More Information” bits in DPM to actually tell you what the problem was rather than always going to a page not found (haven’t had one work yet from DPM!) This is the link from the event in More Information for this problem followed by where it ended up.

    http://go.microsoft.com/fwlink/events.asp?ProdName=Microsoft%20System%20Center%20Data%20Protection%20Manager&ProdVer=4.1.3417.0&EvtID=32017&EvtSrc=MSDPM&LCID=1033&P2wAppId=p2wMsdpmEE

    http://technet.microsoft.com/en-us/library/ee958049.aspx

    Or even better when selecting the instance have it check that the permissions are in place to do the restore before starting it and letting you know.

    Oh well – we can but dream that one day the dev team will make life a little easier rather than having to revert to the forums to find out what is missing. ;)

    Thanks again for your help - saved me from the ire of a very careless user!


    Darren

    Friday, January 10, 2014 6:33 AM
  • Dwayne,

    Is there any documentation that details the necessary permissions to complete a SharePoint Restore?

    I have struggled with trial and error to get this working for SQL and finally the file share. In my case the DPMRA is running as Local System on SQL, is this correct or should it be a domain account? (Should I grant "Local System" DBCreator? that just seems wrong.)

    Also, the DPM CPWrapper Service is Disabled on SQL is this correct?

    The problem is now that I can actually restore an item in SharePoint, it is not the same as when it was backed up, the dates and time are current and the Modified User is the "System Account".

    Matt


    Matthew McDermott, MVP SharePoint

    Tuesday, January 21, 2014 1:42 PM