Because of SharePoint's complexity, backing up and restoring the content management and collaboration platform sometimes can be quite challenging.
One reason is that there are so many varied aspects to the Microsoft technology; as a result, it can be difficult to figure out the components of an effective SharePoint backup strategy. In fact, there are numerous types of backup procedures for SharePoint 2010, ranging from ones at the database level to SharePoint Server farm backups and from duplications of applications to backups of individual searches.
Though there is no single step for getting SharePoint backups and restorations to work correctly, there are certain issues that tend to repeat themselves time and again. We'll take a look below at the most common problems associated with backing up and restoring SharePoint and offer some practical steps for avoiding the pitfalls.
Most backup applications require a software agent to be installed on the SharePoint servers that are being duplicated. The agent is used to facilitate the backup process, and though the concept of deploying a backup agent probably seems simple enough, there is at least one issue tied to the process to watch out for.
More about SharePoint backup and SharePoint collaboration management
Use SQL Server log shipping for SharePoint backup and disaster recovery
Save the farm with an established SharePoint 2010 backup strategy
SharePoint 2013: New apps and a simplified user interface
Backup agents can only facilitate the backup of a SharePoint server if the agent can gain access to the various SharePoint components. Most backup agents run using either the Local System account or a dedicated service account. In the case of SharePoint, however, sometimes this approach is inadequate.
Microsoft's best practices for SharePoint 2010 call for using several different service accounts. That way, no single individual service account ends up with excessive permissions that an attacker or malware could then potentially exploit. Depending on what backup software is being used, it might be necessary to manually grant the agent permission to back up SharePoint.
For example, Microsoft's System Center Data Protection Manager (DPM) 2010 Service Pack 1 and DPM 2012 backup tools include a special utility called ConfigureSharePoint.exe. This utility must be executed on a front-end Web server to give DPM permission to back up a SharePoint farm. Furthermore, this utility must be executed any time the SharePoint farm administrator's password is changed.
Complications backing up site collections
When it comes to performing site collection backups for SharePoint implementations, some administrators opt to use Microsoft's Windows PowerShell command-line task automation environment instead of -- or in addition to -- a typical backup utility. SharePoint 2010 contains a lightweight PowerShell cmdlet called Backup-SPSite that can be used to back up or restore an entire site collection. The backup is written to a folder on the SharePoint server's hard disk. After the site collection backup has been completed, the contents of the folder can easily be written to tape. The command syntax looks like this:
Backup-SPSite –Identity <site collection name> -Path <Backup path> [-Force] [-NoSiteLock] [-UseSqlSnapshot] [-Verbose]
Though Microsoft makes the Backup-SPSite cmdlet relatively easy to use, there are some things SharePoint administrators should watch for. First, unlike a typical backup application, this method forces the entire site collection into read-only mode for the duration of the backup. Because of that, some admins are quick to circumvent the process by using the [-NoSiteLock] switch, which goes in the command syntax after [-Force]. But using that parameter causes the site collection to remain in read/write mode throughout the backup. That means the entire backup can be corrupted if a modification is made to the site collection while it is in progress.
Another problem related to the Backup-SPSite cmdlet occurs at restoration time. When a site collection recovery is performed, the recovery farm must be running the same version of SharePoint (including service packs) as the server farm in which the backup was made.
A SharePoint backup can also fail due to writer errors in Microsoft's Volume Shadow Copy Service technology, or VSS for short. Shadow copies created by VSS augment the storage administrator's tape backup. Because SharePoint makes extensive use of databases, VSS snapshots help make sure that the databases remain consistent during the backup process.
The snapshots make use of components called VSS writers. Each VSS writer is responsible for one specific aspect of the backup process, and all of them work together to create the backup. However, if even one VSS writer fails, it can cause the entire backup to fail.
If your SharePoint backups are failing and your backup software cites VSS-related problems, you should try to troubleshoot the underlying VSS writers. The easiest way to do this is to open a Command Prompt window and enter the following command:
VSSADMIN List Writers
Fig. A: You can use the VSSADMIN command to generate a list of the VSS writers that are in use during a SharePoint backup process.
This command will bring up a list of all of the VSS writers that exist on the system, as shown in Figure A. More importantly, Windows displays each writer's state (which should be listed as stable, if there are no problems) and the last error the writer produced.
Using the VSSADMIN command won't solve your problems, but it will usually show you which VSS writers are causing them, which will make it much easier to resolve the situation.
While the issues explained here do not make up an exhaustive list of the things that can go wrong during SharePoint backups, they do represent the more common among them. Hopefully, by reviewing these, you'll have a better understanding of what might occur so you can be prepared to sidestep the customary challenges during your next SharePoint backup procedure.
ABOUT THE AUTHOR
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.
This was first published in November 2012