Hello, my name is Walt Whitman and I am a Sr. Support Escalation Engineer with Microsoft. Today we will be discussing how Data Protection Manager 2010 knows about the different data sources that comprise a SharePoint farm.
SharePoint farms come in all shapes and sizes. In most situations though you will find that a SharePoint farm is comprised of several servers. A simple yet common configuration is:
Once you configure protection for SharePoint with
which starts the
SharePoint VSS Reference Writer
, DPM “requests” the Web Front-End Server to implement a method within VSS called
. This Method requests VSS subscription information of SharePoint data sources on the WFE server. The WFE server does not know about the entire farm configuration, but it is aware of the location of the configuration database. On the SQL Server, the farm configuration information is gathered from the SharePoint configuration database and the associated servers that make up the farm. The data is then passed back to the WFE server in the form of a
writer metadata document
and then onto the DPM Server. This is why it takes a few minutes sometimes to enumerate all of the data sources within a farm or server when trying to select members for a protection group.
The writer metadata document is a volatile document and gets re-created each time DPM “requests” information about the farm. The writer metadata document contains 3 types of data: writer identification and classification information, writer-level specifications, and component data. All three pieces are important, however the Component-level information is created by calling
. The Component-Level information contains the specifics of each data source; where the data lives, what parts of the data live where, what type of data it is, etcetera.
Many farms however are comprised of much more than a handful of servers, content databases and configuration databases. What about user databases or other types of databases that are not content databases?
The SharePoint Reference Writer is only responsible for databases that are flagged in the Writer Metadata Document as content_db.
If there are other databases that need to be protected outside of content data bases, simply protect them in the same protection group as standalone SQL databases!
Use caution when selecting these other non-Content databases so double-protection of existing databases doesn’t occur. This may cause a race condition when the backup begins and can potentially cause the backups to fail.
I hope this sheds some light on how DPM determines what to back up on a SharePoint farm.