none
Sharepoint ContentDB not backed up by SharePoint protection but by Auto SQL protection RRS feed

  • Question

  • Hi all,

    we have set up dpm2012 environment protecting a SharePoint 2010 Farm. we have some different protection groups to be able to specify different parameters for the items (e.g. retention, sync frequency). One of them, say PG1, protects the sharepoint farm via sharepoint protection. one other, say PG2, protects the rest of sql server databases of the sharepoint sql instance via sql autoprotection.

    The issue we're facing is that we have a content database contained in the list of databases protected via the auto-sql protection instead of appearing in the list of items protected via sharepoint. In other words, this content database is being protected by the sql server protection instead of the sharepoint protection. so, among other things, we could not perform granular recoveries as it is seen as a regular sql server database by DPM.

    How has this db arrived there? I don't know, but my best bet is that during the db creation (we pre-provision contentdbs and then attach them to sharepoint), and before attaching it to the web application, the sql server autoprotection "saw" it and picked it as a regular database (it WAS a regular database at that very moment). once it is included in the sql server protection, sharepoint did not take it into account (which also seems strange to me, dpm should have complained), although the db is registered as a content database attached to a web application of the farm.

    My problem is, logically, how to stop sql server protection on this database (keeping the autoprotection for the rest of the instance) and make the sharepoint protection integrate it with the rest of content dbs.

    any ideas?

    Thanks in advance

    Thursday, January 17, 2013 10:13 AM

Answers

  • I have come across the same issue and it is also discussed here ( http://www.itwalkthru.com/2010/11/dpm-2010-sharepoint-farm-backup-errors.html)

    Looks like the only way around this is to ensure that you have a process in place to remove the DB from the SQL protection group then re-run the SharePoint protection job (or turn off Autoprotect if you have that luxury).

    I would also expect DPM to complain about not being able to backup the new content database.  Something to be fixed in a future SP perhaps?



     



    • Marked as answer by Roberto MD Friday, January 18, 2013 2:03 PM
    Friday, January 18, 2013 1:43 PM

All replies

  • I have come across the same issue and it is also discussed here ( http://www.itwalkthru.com/2010/11/dpm-2010-sharepoint-farm-backup-errors.html)

    Looks like the only way around this is to ensure that you have a process in place to remove the DB from the SQL protection group then re-run the SharePoint protection job (or turn off Autoprotect if you have that luxury).

    I would also expect DPM to complain about not being able to backup the new content database.  Something to be fixed in a future SP perhaps?



     



    • Marked as answer by Roberto MD Friday, January 18, 2013 2:03 PM
    Friday, January 18, 2013 1:43 PM
  • Cool! that explains exactly what is happening to us. Thank you very much for sharing, and also to your thorough sharepoint admins...

    I also miss a bit more of robustness on DPM, more when dealing with medium/big sharepoint farms (the ones where DPM should prove the best benefits). This issue happens because content dbs are pre-provisioned (as opposite to create them with default values), which is "mandatory" on large farms with non-default sql server settings. We have also had issues with optimized ILR just because the instance is clustered and this is not supported on pre-sql server 2012, and typically you set up a cluster when your instance is somehow candidate to be backed up with something more than a simple maintenance plan.

    Maybe the DPM team comes to this forums from time to time and reads these comments for getting hints on future features...

    thanks again, you did my day!

    Friday, January 18, 2013 2:03 PM