By W. Curtis Preston
Microsoft Office SharePoint Server is a popular enterprise collaboration tool. Although it's great for streamlining your office operations chores, it can be troublesome when it comes to data backup and recovery. In this two-part SharePoint tutorial, learn about the best SharePoint backup and recovery strategies, whether it's with native backup and recovery options or third-party SharePoint backup tools.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
The main problem with backing up SharePoint is that it's not just one application, but a suite of applications that work together. 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 deduplication.)
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 SharePoint 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.
SQL Server Backup. Because SharePoint stores most of its information in SQL Server, you can use SQL Server backup tools to back up most of its information, including the configuration and administration databases. You can also use those backups to restore the databases, but it's not supported. Given the synchronization issue, it would seem that as long as you make sure to synchronize what you're restoring then it should work just fine. The key thing is to ensure that no configuration changes are made during your backup window. However, you'll still be missing any customization information stored in the file system if this is the method you choose to back up SharePoint.
Because SQL Server backup tools can be run from the command line, you can schedule this to run at convenient times using Scheduled Tasks. It does require that you manually reattach your databases to the appropriate Web application after a recovery.
What it can't do is back up the search database, and for an odd reason: the search indexes aren't stored in SQL Server. Because you can't synchronize the search database after a database-only backup, this backup approach isn't a viable option for that database.
Windows Server 2008 Backup. The native backup and recovery system for Windows Server 2008 can be used to back up all those things that aren't in the databases (such as the configuration and customization files), but it can't be used to back up the databases themselves.
It seems that the native tools have as many limitations as they have benefits, but it's possible to create a "workable" solution if all you have are the native tools -- especially if you can do a regular shutdown of your farm. If you do a shutdown, you could do a SQL Server backup of all of the databases to a file system that's then backed up using the Windows Server 2008 backup system, along with the directories where customization and configuration information is stored.
EDITOR'S TIP: Click here to read this next part of our SharePoint tutorial on backup and recovery, where we look at third-party SharePoint backup tools.
About this author: W. Curtis Preston (a.k.a. "Mr. Backup"), executive editor and independent backup expert, has been singularly focused on data backup and recovery for more than 15 years. From starting as a backup admin at a $35 billion dollar credit card company to being one of the most sought-after consultants, writers and speakers in this space, it's hard to find someone more focused on recovering lost data. He is the webmaster of BackupCentral.com, the author of hundreds of articles, and the books "Backup and Recovery" and "Using SANs and NAS."
This article was previously published in Storage magazine.