Monday, November 29, 2010

DPM 2010 SharePoint Farm Backup Errors

Quick Description:  In the DPM 2010 console, a SharePoint 2010 Farm Replica shows the errors below:
Prepare for backup operation for SQL Server 2008 database ServerName\DatabaseName on ServerName has been stopped because this operation depended on another backup operation which failed or was cancelled. (ID 30200)
1 Database(s) has been removed from the SharePoint farm ServerName.  These databases are not part of the recovery point
    OR
 One or more databases seem to have been added to the SharePoint farm  ServerName.  Recovery point for the farm has been created without these databases.
Problem:
The primary error appears to occur whenever a farm configuration change is made.  Depending on whether you've added to, or subtracted from the farm, the secondary error will be one of the two additional errors.


Solution:
The error that occurs when a database is removed from SharePoint is solved by stopping protection and then re-creating it without deleting any data.  To do this right click the protected farm and select Stop Protection.  Do not check the box to Delete replica on disk.  This bears repeating.  Verify that Delete replica on disk is not checked, and then check it again, if you check the box you will irrevocably lose your existing backups.  Once you've destroyed the replica, you can re-instate it.  It will detect that there is inactive protection for the previously protected farm, and initiate a consistency check before bringing it online. 

The case in which a content database has been added to the SharePoint farm, is much more interesting.  My DPM server is protecting both the SharePoint farm, and the backend  SQL server that hosts all the additional SharePoint databases.  Since the SharePoint farm protection only backs up the config and content databases, I have the SQL servers set to auto protect new databases coming online on this server (generally there shouldn't be change other than new content databases).  It seems that databases are autodiscovered before new site collections, and since the new content database is already in DPM, it fails adding the site collections inside the content database to the farm replica.  The simple answer is to stop protecting the new content database on the SQL server and re-run the recovery point on the SharePoint farm.  Since new databases shouldn't just be cropping up unannounced on the SharePoint SQL server, you may want to stop DPM auto discovery on the SharePoint SQL server, but if you need autodiscovery on, make sure DPM is happy after any new content databases are added.


This works, and isn't disastrous unless you don't catch the DPM error and end up without a current backup of your SharePoint farm, but I think it's pretty fragile to not be able to cope with changes to the SharePoint farm.  If you have a great SharePoint administrator like we do, you shouldn't be surprised by databases appearing out of thin air, but even with warning, you will have to rebuild the replica if a content database is removed or moved to a new farm, which is at the least a hassle, and in practice just another moving part that can break.  I wish it were more robust.  Note to self:  Keep remembering how much better DPM 2010 is than the previous version.

1 comment:

  1. thanks! I have had the same issue (a database added to the farm and taken under sql auto-protection before attaching the sql db into sharepoint). I followed your suggestions and I've just needed to remove the sql server protection for the database (no further actions, no need to stop+restart SP protection. It seems that this was enough as on the following day the content db is shown on the sharepoint protection.

    ReplyDelete