One of the things administrators quickly discover is that SharePoint backup and restore has different kinds of...
granularity throughout a given system. A Windows Server box, for instance, can be backed up as a single snapshot, which is useful for a bare-metal restoration of the whole system at once from a given point in time.
Such monolithic backups are often less useful for selectively restoring individual subcomponent -- for instance, Exchange message stores or a SQL Server database. Those products typically have their own backup plans and granularity of backups, to say nothing of things like mirroring or clustering as interim forms of protection.
SharePoint includes a slew of PowerShell cmdlets specifically for backing up and restoring content.
SharePoint 2010 is much the same way. You can back up a whole server as part of a way to protect SharePoint's object and site database, but such backups don't always help if you're trying to restore a very specific part of the SharePoint installation.
The good news is that SharePoint itself offers a good deal of granularity for backup and restore, both with its own native backup system, via Microsoft SQL Server's native command set and from products like System Center Data Protection Manager and third-party file-level backup systems. Let's start with the last of these items as a way of exploring the granularity issue in detail.
File-system SharePoint backups
Backing up an entire server with all SharePoint databases and system configuration is the easiest but least flexible way to protect a SharePoint installation. It's best for bare-metal scenarios, where you have a hardware failure or other disaster, want to start over from scratch or just want to pull everything at once from a single restore source.
Microsoft notes that a full file-system backup also provides protection for a few corner-case types of data that might need protection in SharePoint: any manually deployed customizations and any changes made to Internet Information Services (IIS) or web.config not made through SharePoint itself or set via conventional administrative methods (e.g., APIs). These are the extreme exception rather than the rule, but it's useful to know a full file-system backup will cover them.
SharePoint backup via SQL Server
Since SharePoint stores a big portion of its content as SQL Server databases, it follows that backing up SQL Server databases -- either via SQL Server's native backup/restore technology or a third-party, SQL Server-aware product -- will protect those things as well.
That said, not everything vital to SharePoint is stored in SQL Server. List items and documents, and the farms or service/Web applications themselves aren't kept there, so they would have to be restored or reconstructed on their own. (On the other hand, this is good to know if you want to restore one independently of the other.)
As a general rule, it's best to keep SharePoint's storage in its own SQL Server instance whenever possible for the sake of both performance and granularity of restoration. If I keep my SharePoint data in a central instance of SQL Server along with a number of other databases, a problem with that instance will affect everything. If SharePoint is in its own SQL Server instance, any damage to that is self-contained and can be handled on its own.
Backups via System Center Data Protection Manager 2010
Data Protection Manager, or DPM, provides a good mix of complete and granular protection for SharePoint servers. Most everything that is protected via SQL Server's native backup is also protected through DPM, along with the things described above that are only covered by a filesystem backup.
More about SharePoint backup
When disaster hits, SQL Server log shipping is an option
The security weaknesses in SharePoint collaboration
Is it better to use multiple instances?
How companies often overlook SharePoint controls
The one area where DPM falls down in terms of granularity is the applications set up by SharePoint. A DPM backup will cover entire farms, but it won't allow for restoring individual service or web applications. DPM also doesn't automatically protect data in remote BLOB stores—that is, files stored outside of the database itself directly on the filesystem through the Remote BLOB Storage function. Those files would have to be manually backed up via a separate protection group in DPM.
That said, this isn't terribly difficult to set up. It just requires you to be diligent and to remember that both the databases and the file system need to be restored simultaneously.
Backups via SharePoint itself
SharePoint includes a slew of PowerShell cmdlets specifically for backing up and restoring content for SharePoint itself. Because they're cmdlets, they require some manual heavy lifting to be useful, but with a little work they can be used to give extremely granular and precise protection:
- Backup-SpFarm/Restore-SpFarm backs up and restores an individual database, Web application or the entire SharePoint farm.
- Backup-SpSite/Restore-SpSite backs up and restores site collections.
- Backup-SPConfigurationDatabase backs up the configuration, not the data, for a given farm.
Using the cmdlets, however, means dealing with a few drawbacks. For one, you can't use them to back up or restore list items or documents; you need Data Protection Manager to do that. It's also possible to use a third-party tool, such as the SharePoint Content Deployment Wizard, to accomplish this, but with the caveat that it's an unsupported solution. Another drawback is that the above-noted direct changes to IIS, Web applications or the system itself will not be backed up via the cmdlets.
The best way to protect a given SharePoint installation seems to be twofold: one, by using full file-system protection via an existing backup product (including, but not limited to DPM); two, by using on top of that SharePoint's native backup functionality via cmdlets to protect SharePoint from the inside out. The latter will protect SharePoint itself; the former is used to protect everything outside of SharePoint (e.g., BLOB storage, direct system changes, etc.).
About the author:
Serdar Yegulalp has been writing about computers and information technology for more than 15 years. Check out his blog at GenjiPress.com.