Last month I was unbelievably lucky enough to be invited to provide a guest blog post at the Hey, Scripting Guy! Blog over at TechNet on the subject of how to go about scripting out a full backup of a SharePoint farm. Please feel free to head over to their blog to see the post if you want (the biggest difference between that post and what I’m listing below is that you’re going to be subjected to an awkwardly large photo of me over there, none of that nonsense here!), but I want to go ahead and post it here in my blog as well, because I’m also going to do a followup post here in the next day or so to tie up a couple of loose ends that people have been nice enough to point out to me :) So without further adieu, here’s the info!
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 to getting it right than that. The nice thing is that we’re talking about a pretty specific situation here: how to script out a backup of a SharePoint farm using SharePoint’s own backup tools. Interestingly, the general intent and scope of SharePoint’s backup command line tools didn’t change much from the product’s 2007 release to its 2010 release. Yes, SharePoint 2010 ships with plenty of great 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 ain’t a whole lot different from the new Backup-SPFarm CMDLET. Plus, compatibility for STSADM was retained in SharePoint 2010, so if you already had a script using it, you can continue to take advantage of that investment if you want.
If you want, a PowerShell script for SharePoint backup can be pretty simple. Just call Backup-SPFarm or STSADM’s Backup operation, wrap it in some error checking logic, save it and 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 do still have some requirements for using them that you need to keep in mind:
- A SharePoint 2007 or 2010 farm
- A service account to run the Scheduled Task calling 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 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 (ex: C:\backups\). If SharePoint and SQL aren’t on the same server, this MUST be a shared drive with a UNC path (ex: \\server\backups). The account running the SharePoint Timer Job service and the SQL Server service account for SharePoint’s SQL instance must both have full control of the directory.
If you want to keep it vanilla, you can stop here. But, if you want to really turn things up to eleven, I’ve got 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 and yet you need it to efficiently use your available resources to provide that consistent protection.
I’ve listed below some items 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 backup, the less up-to-date your backups are.
- Take advantage of varied backup types: SharePoint allows you to do both Full and Differential backups, so you want a script that is more heavily weighted towards Differential backups to save space but 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 back up, so you always have to have at least one Full backup. But you also want to continue to do 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 (either with STSADM’s Backup operation and its Site Collection backup option or with the Backup-SPSite CMDLET).
- If you’re running SharePoint 2010, backup 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 backup this critical resource as an additional layer of coverage for your farm. It’s not a complete capture of your farm’s configuration data (see http://sharepointinterface.com/2010/09/10/configuration-only-backup-and-restore-in-sharepoint-2010/ for a great explanation of its limitations), but it’s a start.
- Also 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 script 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 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’s a lot to consider and may seem a little daunting, but I’ve got good news for you: I’ve gone ahead and written up a script that does everything listed above and is compatible with both SharePoint’s 2007 and 2010 releases. I’ve posted it to the TechNet PowerShell Script repository for your downloading pleasure, so feel free to have at it here: http://gallery.technet.microsoft.com/scriptcenter/9b99c435-8831-4c9e-a70b-1f13158ef22a
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 be able 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’re planning on running this script, as well as 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 aren’t any conflicts, and run them between Midnight and 5 AM (based on the local time for my largest group of users).
- Document the configuration of your Scheduled Task, and store it somewhere it can be accessed centrally.
- You must either have already completed a Full backup in your environment, or set the initial run of this Scheduled Task to be on the day you have selected to do a Full backup. You cannot create a Differential Backup until there is first a Full backup in the farm.