SharePoint is being deployed in more organizations each year. In fact, it has become for many companies a mission-critical solution because it provides such capabilities as wiki, blog, document library, photo gallery, and more, thus comprising a collaboration hot spot.
The amount of SharePoint data grows incredibly fast because additions come not from a single person but rather, from members of your workgroups. Announcements, links, documents, tasks -- they stream into the server from everyone in the organization with contribution permissions. Like Public Folders for Exchange, SharePoint has become a dumping ground for all sorts of content. And it must be protected.
Backing up SharePoint is not difficult. But restoring it is.
Behind the scenes, SharePoint is composed of IIS (Internet Information Server) configurations and a set of SQL databases: Farm Configuration, Administrator Content, Shared Service Providers Configuration, Search, Web Application Content, and more. All the information on the SharePoint site resides in those databases.
SharePoint has a built-in backup utility, but it has limitations, especially around recovery. Before I explain how to deal with those limitations, let's consider the levels of data recovery you want to prepare for: content, site, and disaster.
- Content recovery: SharePoint provides both versioning and a two-stage Recycle Bin to help users retrieve deleted content easily. With versioning enabled, SharePoint retains multiple copies of the document so that a previous version can be restored if needed, thus reducing the risk of data loss caused by overwriting a document. Users can go to the Recycle Bin to recover accidentally deleted content; that's stage one. The second stage is part of the site collection itself, from which an administrator can restore content deleted from the first-stage Recycle Bin.
- Site recovery: This is the restoration of a site or parts of a site in the event they become corrupt or are accidentally deleted.
- Disaster recovery: This is the recovery of an entire farm, or the migration of a farm, site, or database.
I know one company (to remain nameless) that set up and ran a SharePoint server successfully, but had no site or disaster recovery in place when it crashed. Instead, the company's IT staff resolved to forget the whole thing and not use SharePoint any longer. Can you imagine such a case in your environment? Picture the SharePoint server going south, then you report to your superiors, "I have no way to bring it back. We can either start from scratch or just forget the whole thing." Welcome to the unemployment line!
What could that company have used? SharePoint does include two full farm backup options. One is the command-line backup tool STSAdm, and the other is the Web-based Central Administration backup and restore; another option is SharePoint Designer. Outside of SharePoint, you might be able to use SQL Server 2005 Backup and Recovery. You might also consider going for Microsoft's System Center Data Protection Manager (SC DPM) or a third-party tool. How do you know which to use?
Cost versus recovery
Every solution has a cost and recovery pain associated with it. Often, free tools involve a learning curve, which a paid tool might avoid. You'll have to ask yourself these questions: What are your needs? How large is your organization? What is your budget? What is your aggravation-to-cost ratio?
The built-in SharePoint tools (Central Administration and STSAdm) have several function limitations to keep in mind. First, although both tools can back up and recover the server farm, neither can recover the configuration or Central Administration databases, nor can they back up customizations. Central Administration cannot schedule backups or back up site collections. Neither tool can back up directly to tape, nor can they provide an incremental backup -- only full and differential.
So, you may wonder, how do you recover items not supported by the built-in SharePoint tools? One option is to restore these databases from a backup of a fully stopped farm. Another option is to document all configuration settings so that you can re-create them. You could establish a form of mirroring or clustering for your SharePoint farm so that there is a duplicate. Not surprisingly, Microsoft recommends you buy SC DPM to recover an entire farm.
SC DPM's cost is fairly low. I believe that SC DPM is worth looking into because it does more than back up SharePoint; it can also handle Hyper-V child VMs, Exchange, SQL, files, and more. From a SharePoint perspective, SC DPM uses the Volume Shadow Copy Service (VSS) writers. It can perform incremental backups, schedule backups, back up files and folders with customizations, back up directly to tape, back up the configuration database and Central Administration database, and restore them as part of a farm recovery. SC DPM can recover the farm, a site, and even an individual item. (Note: You will need SC DPM SP1 to ensure that the search database and index are backed up.)
SC DPM is pretty capable, but I have a caveat: If you want to have site and item recovery, it is recommended that you configure a recovery farm, which requires server and admin resources. This is a second farm used only to restore data. On the plus side, it doesn't have to completely mimic the live farm and can be a single server installation or virtual server farm. During the restoration process for a site or item, SC DPM restores the databases to and extracts the site from the recovery farm, then imports it into the target production farm.
Options beyond SC DPM
Your SharePoint backup and recovery needs may go beyond what the built-in tools or SC DPM provide and support capabilities such as archiving and e-discovery. That means looking at third-party tools.
One tool I've had a chance to work with is Mimosa NearPoint, which provides continuous data capture, immediate recovery of items or sites (without the need for a recovery farm), e-discovery and retention management, and single-instance storage. Of course, all these features come at a price. That higher cost may be justified by the reduced risk and faster recovery, archiving, and e-discovery.
Where do your needs fall in relation to the tools available? What are you using to back up SharePoint in your environment? I'd like to know.
Follow J. Peter Bruzzese on Twitter.
This story, "Don't be caught without a SharePoint recovery solution," was originally published at InfoWorld.com. Follow the latest developments around SharePoint at InfoWorld.com.