This article can also be found in the Premium Editorial Download "Storage magazine: The business case for solid state vs. disk storage."
Download it now to read this article plus other related content.
Microsoft SharePoint is gaining in popularity as a corporate collaboration tool; it's great for office efficiency, but tough on backups.
Microsoft Office SharePoint Server is an interesting suite of applications. I've heard from a number of users who extol its collaboration methods, but from a backup perspective, SharePoint is somewhat analogous to VMware and other server virtualization technologies. SharePoint may be solving the world's problems, but how do you back this thing up? (Interestingly, the backup solutions for SharePoint and VMware are eerily similar; more on that later.)
The challenge with backing up SharePoint is that it's not just one application, but a suite of applications that work together. Each SharePoint portal consists of one or more Web servers, application servers, query servers and index servers, all of which store their data in multiple SQL Server databases (at minimum, one content database and one configuration database). In a very small environment these can all be placed on a single physical server, but they're typically configured across multiple servers to provide some scalability.
A look inside SharePoint
SharePoint's configuration database obviously stores the configuration of SharePoint itself, including such things as:
- Internet Information Services settings, including IP addresses and Secure Sockets Layer (SSL) certificates
- accounts that are used to run various services such as search
- Search, connection, workflow, email, antivirus and logging settings
- Recycle bin settings, such as whether to have a multilevel recycle bin to protect against accidental deletion
Closely related to the configuration database is the administration database. Both of these databases are extremely important, which is why it's so surprising that most of Microsoft's built-in backup methods don't support restoring them. Oddly enough, they support backing them up, but restoring them isn't supported (see "What's up with SharePoint's configuration database?", below).
|What's up with SharePoint's configuration database?|
None of the native backup and recovery tools for SharePoint support backing up and restoring the configuration and administration databases from a live system. The reason Microsoft Corp. gives for this is that these databases must be restored to the same point in time when the other databases were backed up or the results could be unpredictable. Therefore, while the native tools often allow you to back up the whole site, they can't (or shouldn't) be used to restore these databases because these tools have no facility for assuring that they're being restored to the same point in time. For more information on this oddity, please consult this article.
The only supported way to solve this problem with native tools is to restore from a backup of a fully stopped farm. The procedure in this article, which is about how to move all the databases from one server to another, can be used to back up and recover the entire site. (As long as you're not using single sign-on [SSO] databases, in which case you have to handle it separately using this SSO procedure.)
And then, of course, there's the configuration and customization information that's not stored in the database at all. Those files need to be backed up and restored at the same time as the others. No wonder Microsoft says, "It's not supported." They even go so far as to tell you that you should document your configuration changes so that you can redo them, because there's a good chance that you won't be able to recover the configuration and administration databases.
This was first published in June 2010