The growing popularity of Microsoft SharePoint within organizations stands in stark contrast to the annoyance and loathing many administrators feel for it. One particular irritation involves the way SharePoint stores all of its relevant data in a few different places, making it somewhat tricky to perform a SharePoint-specific backup. It’s not impossible to back up each of the individual pieces, but it’s certainly cumbersome.
The script – dubbed SPBackup -- can be run manually, in a scheduled task or triggered from some other script as needed, and is freely available under the terms of the Microsoft Public License (Ms-PL). The script supports IIS 6.0 and IIS 7.0 backups and works on all versions of Windows that support SharePoint (client and server) and have PowerShell.
SPBackup consists of two components: the script itself and an XML configuration file that the script parses to obtain information such as the backup destination (which can be a local path or a server share). Both files need to reside in the same directory, but the choice of directory is entirely up to you.
Of course, you’ll need to edit the XML file to provide the right parameters for your server. Several of the parameters are internal to the script and explained in the script’s documentation. For instance, the backupdestinationmaxkeepdays parameter lets you specify how many days older backups are kept before they are automatically deleted.
You can also set parameters that allow an email to be sent at the conclusion of a job with a description of what happened during the backup process. Other parameters let you specify passwords for IIS 6.0 metadata encryption so that you can choose to restore backups on other servers or perform a catastrophic backup (a full SharePoint backup as performed from the Central Administration panel).
A report is also logged to the console, but there’s currently no provision within the script to write the report to the system log. To be honest, it doesn’t seem too hard to add such a thing by using an extension of the sendemail function within the script and the Write-EventLog cmdlet to write the results to the log. In addition, one user-requested addition involved a way to backup the GAC folder and virtual directories without doing the full farm backup, a process that has since been documented.
Note that the options exposed by the script don’t make up a complete list of the options that can be passed to stsadm.exe (which performs the backup operations for SharePoint itself). One option that’s not used at all is –backupthreads, which defaults to 1 even though it’s recommended that those running SharePoint Server 2007 have it set to 3 for efficiency. You could add this to the script directly depending on your performance requirements. If you have multiple cores on your server (and these days, who doesn’t?) it makes sense to use as many of them as you can.
Finally, while the script performs backups, it doesn’t perform restore operations, so you still have to perform those manually and separately for each element of SharePoint.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
ABOUT THE AUTHOR
Serdar Yegulalp has been writing about computers and information technology for more than 15 years for a variety of publications, including InformationWeek and Windows Magazine.
This was first published in January 2011