Summary: Learn how to use Windows PowerShell to back up your SharePoint farm.
Hey, Scripting Guy! I’ve heard that I can automate the backup of my SharePoint farm with a Windows PowerShell script, but it seems like it’s a lot more complicated than just calling STSADM or Backup-SPFarm? What should I be including in my SharePoint farm backup script?
Microsoft Scripting Guy, Ed Wilson, is here. I am so glad you asked that question. It gave me the opportunity to contact John Ferringer again because I knew this was right up his alley.
John Ferringer is a senior manager consultant with Sogeti, LLC. He has more than seven years of experience administering and supporting SharePoint technologies, and he has spent more than thirteen years working in the technology consulting industry. John is certified as an MCITP and MCTS on several platforms, including Windows Server 2008, SharePoint, SCOM, and Project Server. He has coauthored the SharePoint 2010 Disaster Recovery Guide. His blog can be found at http://www.MyCentralAdmin.com, and he’s on Twitter as @Ferringer.
Protecting a SharePoint farm can be pretty challenging. It’s one of those all too familiar IT problems that seems pretty straightforward (“Hey, let’s just run that Backup cmdlet and call it a day!”)—until you start diving into it and realize that there’s a lot more than that to getting it right. The nice thing is that we are talking about a pretty specific situation here: how to script a backup of a SharePoint farm by using SharePoint’s own backup tools.
Interestingly, the general intent and scope of SharePoint’s backup command-line tools did not change much from the product’s 2007 release to its 2010 release. Yes, SharePoint 2010 ships with plenty of great Windows PowerShell cmdlets, which is quite a big deal for the broader SharePoint command-line management story, but when it comes down to it, STSADM’s Backup operation with its catastrophic options are not a whole lot different from the new Backup-SPFarm cmdlet. In addition, compatibility for STSADM was retained in SharePoint 2010, so if you already had a script that uses it, you can continue to take advantage of that investment if you want to.
A Windows PowerShell script for a SharePoint backup can be pretty simple. Just call Backup-SPFarm or STSADM’s Backup operation, wrap it in some error checking logic, save it, create a Windows Scheduled Task to run it, and you’re good to go. If that’s the route you want to take, SharePoint’s backup tools still have some requirements that you need to keep in mind:
A SharePoint 2007 or 2010 farm
A service account to run the Scheduled Task that calls the script (try to avoid using a named user’s account to run the task). The account must have the following rights:
If you’re using SharePoint 2010, it must be granted the SharePoint_Shell_Access role via the Add-SPShellAdmin CMDLET.
If you’re using SharePoint 2007, it must be granted local Administrator rights on the server that is running the script, and it must be an owner in SQL Server of the SharePoint databases you’re targeting.
Granted Full Control of the directory where you’ll be storing your backups.
A directory for storing backups. If SharePoint and SQL Server are installed locally on the same server, this can be a path on the server’s file system (for example, C:\backups\). If SharePoint and SQL Server aren’t on the same server, this must be a shared drive with a UNC path (for example, \\server\backups). The account running the SharePoint Timer Job service and the SQL Server service account for SharePoint’s SQL Server instance must both have full control of the directory.
If you want to keep it vanilla, you can stop here. However, if you want to really turn things up to eleven, I have some further suggestions for you. It’s a bit more complex, but to me there’s a lot more that you need to take into account when backing up SharePoint. You want to provide your environment with the most effective, thorough, and (most importantly) repeatable protection possible. You want it to work right every time, yet you need it to efficiently use your available resources to provide that consistent protection.
The following is a list of items that I think are “must haves” for an effective SharePoint backup script that goes to eleven:
· Analyze available storage before attempting a backup. If you don’t have the storage available to keep a backup, your script needs to be able to handle that situation gracefully and report it effectively.
· Take regular backups. My general guidance for your backup frequency would be to do them at least daily, but your requirements may vary. Remember, the more you run backups, the greater the performance impact on your farm. The less frequently you back up, the less up-to-date your backups are.
· Take advantage of varied backup types.SharePoint allows you to perform both Full and Differential backups, so you want a script that is more heavily weighted toward Differential backups to save space, but a script that still takes regular Full backups to keep things current.
Note Differential backups capture everything that’s changed in the target SharePoint farm, database, or site collection since the last backup, rather than including everything in the farm. Differential backups require that you first take a Full backup, so you always have to have at least one Full backup. But you also want to continue to perform regular Full backups because large numbers of Differential backups can take a long time to restore.
· Back up the entire farm. This is one of those “at a minimum” kind of things.
Note: If you have high-priority site collections in your farm, you may want to also include logic in the script to individually target them. (You can do this with STSADM’s Backup operation and its Site Collection backup option or with the Backup-SPSite cmdlet).
· If you’re running SharePoint 2010, back up the farm’s Configuration Database individually. All of a farm’s settings and setup information is stored in its Configuration database, and the new Backup-SPConfigurationDatabase cmdlet in SharePoint 2010 provides you with a nice tool to individually back up this critical resource as an additional layer of coverage for your farm. It’s not a complete capture of your farm’s configuration data, but it’s a start. See Configuration-Only Backup and Restore in SharePoint 2010 for a great explanation of its limitations.
· If you have SharePoint 2010, merge the SharePoint usage log files. Microsoft recommends doing this, so it is at least worth considering for your script.
Note: This can have some performance implications if you decide to merge all log files, so keep an eye on it. If it takes a long time to run, try limiting this to specific usage types.
· Handle and report errors. This may seem like a tiny detail, but trust me, when a backup fails you want to know about it. Write your scripts to handle errors, and write them to your server event log for monitoring and alerting.
· Rotate backup files. Over time, regularly generated backup files can take up a lot of space. Disk space is cheap these days, but you don’t want a backup to fail because there’s not enough storage to hold it, do you? Your script should retain backups for a defined number of days and either archive or delete older files to reduce your storage footprint.
Now, that is a lot to consider, and it may seem a little daunting, but I have good news for you: I have written a script that does everything previously listed and that is compatible with SharePoint 2007 and SharePoint 2010. I have posted it to the TechNet Script Repository for your downloading pleasure, so feel free to have at it
A couple of notes about the script:
· Be sure to review its required input parameters and settings, and select the options and items that make the most sense for your environment.
· Carefully consider how frequently you want to back up your environment. Understand the Recovery Point Object (RPO) of your users (how current your restored content must be) to better gauge the right setting for this.
· I wrote the script to be run once a day, with Full backups of the farm on a weekly basis and Differential backups the other six days of the week. This is a good general setting, but your approach will depend on your users’ Recovery Time Objectives (RTO). If you need to perform a restore quickly, you need to remember that Differential backups can take a long time to restore if you have a lot of them.
· Think about what else is going on in your SharePoint environment when you are planning to run this script, in addition to other systems that your SharePoint farm depends on, such as SQL Server. Backups are resource intensive, and you want to avoid any competition for resources that can cause delays or errors. I try to schedule my backups about an hour after my search crawls normally finish to ensure that there are not any conflicts, and then I run the backups between midnight and 5:00 A.M. (based on the local time for my largest group of users).
· Document the configuration of your Scheduled Task, and store it somewhere that it can be accessed centrally.
· You must have already completed a Full backup in your environment or set the initial run of this Scheduled Task to be on the day that you selected to perform a Full backup. You cannot create a Differential backup until there is first a Full backup in the farm.
Thanks John, for sharing this great script and this excellent information about backing up a SharePoint farm.
FJ, that is all there is to using Windows PowerShell to back up your SharePoint farm.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at email@example.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy