Microsoft’s SharePoint Server has probably had the most variety in its backup and restore solutions. The first version of the product was essentially a modified version of Exchange Server, and used the same database engine that Exchange did at the time. Today, SharePoint Server uses multiple databases to store its content, configuration, search catalogs, and more—and even stores some critical files as simple disk files. All that data stored in different places helps make SharePoint Server one of the most difficult Microsoft server products to work with in terms of business continuity and disaster recovery. It becomes even more complex when you start dealing with SharePoint Server farms— collections of servers designed to serve up the same content for load-balancing purposes. Is it even possible to move beyond the Backup 1.0 mindset and start using Backup 2.0 when it comes to SharePoint?
Microsoft defines three levels of data recovery for SharePoint Server:
- Content recovery is when you recover one or more items using a Recycle Bin or retrieve a previous version of the items from the content database. This relies on functionality within SharePoint itself and is accessible to end users.
- Site recovery is when you recover an entire SharePoint Server site, or Web site. This is the type of recovery most administrators are concerned with.
- Disaster recovery typically involves site recovery to new hardware