Considerations for SharePoint Application Backups

A SharePoint application is made up of many inter-dependent services. These services could live on the same server, or they may span across several different servers, depending upon the configuration for that particular SharePoint server application.

Due to the SharePoint application’s distributed nature, a backup must address each server belonging to that application’s configuration. Otherwise, you run the risk of creating incomplete backups that do not fully address the inherent co-dependencies embodied in that application’s logical and physical architecture.

When creating a SharePoint application backup, keep the following dependencies and restrictions in mind:

  • To provide the best protection for a SharePoint farm, your backup job’s definition should include the virtual node and all of the physical nodes that belong to that farm.

  • You cannot select individual components (or servers) from the Configuration and Central Administration Databases group; you cannot backup that content unless it is defined as part of a full backup of the entire SharePoint application.

  • You can select the entire Search Database and Index files group, but again, you will not be able to select individual components.

  • You can select the full set of Shared Service Providers, or you can select one or more individual Shared Service Providers, but you cannot select the individual sub-components that appear under a single Shared Service Provider entity.

  • A SharePoint application backup does not include any component from front-end servers, perform a server backup to ensure their protection. If you want to protect a front-end Site Replication Service (SRS) server component, you need to perform a node level backup for each front-end server found in the SharePoint server configuration. If the front-end server has any of the index files, they will be included in the SharePoint backup.

  • In DPX, the SharePoint application appears below the virtual node for the SharePoint farm, but SharePoint dependency targets are found within their assigned physical node groups. (This includes SharePoint SQL databases and Search Index files.) If you run a backup of these dependent physical nodes without having a SharePoint control node in the same job, DPX will back up these servers without using the SharePoint VSS writer. Backups performed in this manner may produce backups/snapshots that are not consistent from a SharePoint perspective.

  • You can create backups that use a combination of virtual node and physical node volume selections.

  • Make sure that Windows SharePoint Services Search (SPSearch) is currently running (on the same server that hosts the index files) before you attempt to back up any WSS index files. To avoid having to check this before running each backup, you might want to change the startup type of the SPSearch service to use an automatic setting instead of the manual startup type.

Protecting Front-End Servers with a SharePoint Server Backup

A regular node-level backup will protect front-end servers, including their IIS configurations, any of their virtual directories, and any additional customizations.

Note. The IIS database is a part of the system state volume; the file system backup protects its virtual directories and customizations.

In case of a front-end server failure, you can:

  • Reinstall (if needed), run the SharePoint Configuration Wizard to configure that server as a front-end server, and copy all custom settings from the node-level backup.

  • Restore the system state, virtual directories, and customizations from a node-level backup (and run the SharePoint Configuration Wizard if needed.)

  • Perform a node-level restore.

Last updated