Versioning is great, but if a user uploads with overwrite, in some cases this creates a new document. This happened to Sudip about a year ago. In explorer mode. It required a full content DB restore to Dev. In-location restore was not an option, as that would roll all content back.

Feature fails on retract across: farm and orphaned GUIDs; perhaps SharePoint server and configuration DB out of sync with content DBs and GAC, Registry, and Web.config. Other areas that can get out sync are IIS configuration (IIS Metabase), SharePoint webroot folders, and certificate stores. Note registry syncs with the config DB (there are PowerShell commands to force a resync in some cases). Third party apps can touch standard XML files, customize site definitions (webtemp.xml), iFilters (like PDFs), workflows, custom fields, custom content type definitions and so on.

Imagine a need to restore BCS, search, or MMS. Imagine an MMS rollback that results in recent terms, that are used in content DBs, disappearing. This includes references used within a content DB, as well as the service application linkage to its own databases. Restore has to include the proxy connection.

Best practice is to store all code and install packages on each SharePoint server. If a rollback or uninstall fails, the reinstallation can sometimes restore the farm to a working state. Server rollback would cause these to roll back as well, which is not always what is desired. Best practice is to supplement server storage of releases with a dedicated drive for such static install packages so that they don't get rolled back.

Depending on what was changed, Secure Store entries can be out of sync, as can BCS items, search managed crawl properties, or if a server snapshot was restored but the databases are not, or vise versa.

Imagine a rollback of either content DBs or search; the search index can be ahead of the older content DB restore, having references to documents that were added after the content restore point. Or the incremental crawl won't pick up on Content DB change log entries after a restore point. The short answer is a full crawl after a restore.

Consider any additional IIS web services for customizations. SharePoint Central Administration backups are unaware of these additions as they exist outside SharePoint, and their backup/restore needs to be taken into account.

If there are multiple servers in the farm, they need to be chronologically in sync; if one server is restored but not another, the server GACs will be different. If the servers are not consistent, then users who are being served by one server may receive different results than users who are being served by another server.

IIS settings need backup/restore consideration. At the very least, the following settings need to be documented as part of the DR plan:

SharePoint configurations that need to be in sync across environments are as follows:

Consider the following scenario. There is a major problem with your current live SharePoint environment and everything goes wrong. All there are, is some new hardware, DVDs, and a set of backups if you are lucky. Could this be rebuilt from scratch within a reasonable timeframe? Would all of the necessary documentation be in place, detailing the steps to take in order to rebuild your SharePoint environment? Granted, this is an extreme scenario, but once the basics are in place, it makes sense to devote some thought to the more extreme scenarios.

There are limits to the capabilities within SharePoint that are addressed by third party vendors. These can blur the line with backup/recovery software. Below is a sample of some vendor offerings to be aware of in the planning stage: