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.
In addition, some of SharePoint's customization is stored in files in the file system, not in a database at all. This means you have to back up both databases and file system data to fully back up SharePoint.
The content database is where all of SharePoint's collaborative content is stored. This includes Microsoft Office documents (e.g., Word, PowerPoint, Excel) and any communication related to those documents. One of the interesting things about how the SharePoint content database works is that as users share documents and store multiple versions of the same document in SharePoint, they significantly increase the amount of storage needed for their database.
Consider what you would do without SharePoint. You would put the file on a file share and turn Track Changes on. When you finished working on the file, you would send an email to your co-workers to take a look at it. They would review the document, make their changes and save them to that document. Track Changes keeps a record of all the edits and additions, and you didn't have to make a separate copy of the document. But SharePoint stores every version of the document, and it doesn't have deduplication enabled. This is an important point because if you thought deduping Exchange data received good data deduplication ratios, you're going to love the ones you get from SharePoint. (While we're focused here on backing up SharePoint, its versioning process also makes it a good candidate for primary storage
When planning your SharePoint backup and recovery system, you're obviously going to want to be familiar with the content databases, configuration databases and any other databases that are part of your SharePoint configuration. You also need to think about what you want to recover because the different backup and recovery options allow you to do things at different levels. In addition, some of the options allow you to recover at lower levels of granularity than others. A good place to start is with this Microsoft TechNet article that explains in detail the capabilities of the various backup and recovery options described here. The article focuses on using Microsoft tools like Data Protection Manager (DPM), but discusses other options as well.
Native backup and recovery options
The following is a summary of the backup and recovery options that are available free of charge with any SharePoint installation.
SharePoint Central Administration. This is a GUI option available when running SharePoint Central Administration. While it can back up the entire site, it has three very big limitations: It doesn't have scheduling capabilities; it can't be used to restore the configuration or administration databases; and it can't back up site collections.
SharePoint stasdm.exe Command Line. The command line utility (stasdm.exe) is very similar to the Central Administration option, but since it runs from the command line it can be used in concert with Windows Scheduled Tasks to provide scheduling of backups. It still can't be used to restore the administration or configuration databases. Unlike the Central Administration option, it can be used to back up site collections, but Microsoft warns against performing such backups because they say site collection backups can affect performance and should only be performed when the site collection is locked. Microsoft also notes that these types of backups can be particularly slow when dealing with site collections larger than 15 GB -- a very modest size for a site collection. In addition, this utility doesn't seem to like backups that run longer than 17 hours, as it automatically restarts them after 17 hours. Given these issues, Microsoft recommends that to do site collection backups, you should just move that site to its own database and use database backup tools.
This was first published in June 2010