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:
- 2x Web Front End Servers (usually load-balanced)
- 1x Search Index Server
- 1x SQL Server or Cluster
For detailed instructions on setting up protection with Data Protection Manager 2010 please follow the “ How to Protect SharePoint with DPM 2010 ” whitepaper available from TechNet.
The key to DPMs ability to determine what is in a SharePoint farm is rooted in VSS (Volume Shadow Copy Services,) a public API used to backup data in Microsoft environments.
Once you configure protection for SharePoint with configuresharepoint.exe which starts the SharePoint VSS Reference Writer , DPM “requests” the Web Front-End Server to implement a method within VSS called GatherWriterMetadata . 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 IVssCreateWriterMetadata::AddComponent . 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.
Walt Whitman | Senior Support Escalation Engineer
The App-V Team blog:
http://blogs.technet.com/appv/
The WSUS Support Team blog:
http://blogs.technet.com/sus/
The SCMDM Support Team blog:
http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog:
http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog:
http://blogs.technet.com/operationsmgr/
The SCVMM Team blog:
http://blogs.technet.com/scvmm/
The MED-V Team blog:
http://blogs.technet.com/medv/
The DPM Team blog:
http://blogs.technet.com/dpm/
The OOB Support Team blog:
http://blogs.technet.com/oob/
The Opalis Team blog:
http://blogs.technet.com/opalis
The Service Manager Team blog: http:
http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http:
http://blogs.technet.com/b/avicode
The System Center Essentials Team blog: http:
http://blogs.technet.com/b/systemcenteressentials
The Server App-V Team blog: http:
http://blogs.technet.com/b/serverappv
