SharePoint Insider

Open source add-ons enhance Sharepoint 2010 collaboration


Manage Learn to apply best practices and optimize your operations.

Well-planted SharePoint 2010 backup strategy could help save the farm

A SharePoint farm backup as part of an enterprise SharePoint 2010 backup strategy is simple, but on its own might not be enough. Brien M. Posey points out the other important considerations.

SharePoint includes so many different components that it is sometimes difficult to determine what needs to be incorporated in a SharePoint 2010 backup strategy. Part of the reason for this is that many different types of backups can be done for the enterprise collaboration platform. For example, SharePoint 2010 can be backed up at the server farm, application and database levels. There are also numerous other categories of backup procedures intended to duplicate individual aspects of SharePoint such as searches or customizations.

Of all the individual backup techniques that can be used when planning for the worst, one of the easier ones to tackle is that of backing up a SharePoint farm. A farm backup is a simple process that can, in fact, be completed using a single PowerShell command:

Backup-SPFarm –Directory <Backup folder> -BackupMethod {Full | Differential}

The basic farm backup, as you can see, involves nothing more than specifying a backup destination and determining whether you want to create a full or a differential backup. You can either run this command manually or build a script around the command to schedule backups as part of your SharePoint 2010 backup strategy. Using it essentially saves the configuration and the Central Administration databases. It is worth noting that recovering these databases from a backup is anything but intuitive, but the recovery process is laid out in detail on the Microsoft TechNet website.

In addition, a farm backup preserves the following elements:

  • Web applications
  • Service applications
  • Search
  • Secure Store Service user credentialing system (Note, though, that the Secure Store Service is only included in a farm backup when you perform a full backup.)
  • Content databases
  • Database snapshots
  • Site collections
  • Trusted programs
  • Sandboxed packages (Though technically included in a farm backup, such programs are not visible to the rest of the farm since they are associated with specific site collections.)

It might at first seem as though farm backups are all one needs for a SharePoint 2010 backup strategy. But while Microsoft recommends that you routinely back up farms, doing that alone might prove to be inadequate.

Read more about SharePoint 2010 backup strategy and collaboration

Learn how Tyson, others focus on prep, training in their SharePoint 2010 strategy

Find out about the importance of governing SharePoint 2010 capabilities from experts who say it is the starting point for best practices

Discover the six key steps suggested by consultants and analysts for successfully deploying SharePoint 2010 capabilities

One of the reasons for this is that farm backups are not completely inclusive of all components. While it is true that they protect the majority of your SharePoint configurations and data, there are a few elements that are not included in farm backups and therefore must be backed up separately.

For example, a farm backup does not do anything to protect the digital certificates used to form trust relationships between different SharePoint farms to enable systems on one to access applications on the other. In the event that you have to restore an entire SharePoint farm, you will have to manually deploy the certificates and re-establish any existing trust relationships. It is therefore critically important to make copies of any such certificates used by farms.

Another thing to take into consideration is Web applications. While they are included in farm backups, if an application has been configured to use forms-based authentication, the configuration process will alter the Web.config files. When that situation arises, those files will have to be backed up separately at the file level.

Yet another component that might have to be backed up separately from the farm is the Business Data Connectivity (BDC) service, which enables organizations to import data from business applications and other external systems into SharePoint. Performing a farm backup will back up the BDC service itself as well as any existing external content type definitions. The problem is that the underlying data source is not backed up.

Normally, you won’t have to worry about manually backing up your SQL Server systems. The various databases are typically backed up as a part of the farm backup process. However, if you have configured SQL Server to use the optional Transparent Data Encryption (TDE) technology supported by Microsoft, then you will have to separately back up the TDE encryption keys. Neither the SharePoint tools nor the SQL Server tools will back up or restore these encryption keys. Protecting them is an entirely manual process for SQL Server backup.

Finally, it’s important to consider content databases as part of a SharePoint 2010 backup strategy, even though no special procedures are necessary since they are included in farm backups. However, there are a couple of points regarding content databases that are worth weighing.

First, content databases can expand in size to such degrees that it might be easier to back them up separately rather than as part of a farm backup procedure. Second, content kept in external BLOB (binary large objects) storage will be preserved in a farm backup, but only if SharePoint connects to the BLOB store by using the Filestream Remote BLOB Storage provider.

Farm-level backups can protect the majority of your SharePoint data, but there may be some components that need to be backed up separately. Depending on your organization’s SharePoint configuration, it might be wise to explore other avenues and aspects of data and information safeguarding as part of an enterprise SharePoint backup strategy.

Brien M. Posey is a Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Posey was chief information officer for a national chain of hospitals and health care facilities and a network administrator for insurance companies and the Department of Defense.

Article 2 of 3

Dig Deeper on Enterprise SharePoint strategy

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More SharePoint Insider

Access to all of our back issues View All