Posted by: John Ferringer | July 11, 2011

Use PowerShell to Back Up Your SharePoint Farm

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 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:

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.


  1. Thank you, thank you, thank you, thank you! I cannot express how much help this is to me right now. I “accidently” volunteered to be the SharePoint Admin at my work after admin’ing a site collection at my last job and this has been one of my greatest fears in setting up and managing SharePoint 2010 in our upcoming Prod rollout in the middle of August. I am currently testing your script and it makes sense to me (something that PowerShell didn’t always do). Thank you for this and I will be following your blog as long as I am around! 🙂

  2. Brian, you flatter me way too much. I’m thrilled to hear that you’ve found it to be helpful, and even more pleased to hear that you’re actually TESTING it before you use it!!! That’s the mark of someone who knows what they’re doing!

    Let me know if you run into any issue or problems and I’ll do my best to help you out as best as I can.


  3. Thanks John. I wouldn’t say that I “know” what I’m doing. 🙂 Despite the fact that I’ve worked in a SP 2007 lab for a week of training, amintained our IT Site at my last job and working with our consulting company to install/configure it in our environment, I am EXTREMELY nervous and have a lot of questions with little answers.

    My manager has some Microsoft hours for a specialist to come out and I am hoping to get him/her to sit down with me and go over best practice coupled with items such as performance, monitoring, recovery, quotas, and all the other fun admin things. My biggest fear is not being able to do it the right way first. I have seen what happens when implementations are executed and then you spend the after days/months/years adding band-aids and fixes for things that could have been avoided with at the start. That’s how I am potentially feeling about this rollout and unfortunately, I am not watching what this consulting company is doing behind the scenes. So if something breaks, I won’t understand how to fix it (other than what I told my students during my tenure as a computer instructor: ‘Google is your friend!.’

    But, your script did work. Unfortunately, we’re using it as a band-aid at the moment. We have EMC Networker as our backup utility but it isn’t at a newer version where their SharePoint plugin would work. So my backup strategy is to schedule the backups, just like you suggested with differentials six days out of the week and a full on Sunday. These will go out to a network share and there we will have Networker back up those files. This is our temp solution until Networker gets upgraded.

    I am curious on the IIS addition you mentioned in the script. Any idea when you will add that or do you know of one to use? I hate scripting, but am trying to learn it. PowerShell isn’t my friend, but I am doing my best to understand it. I’ve started working with it in Exchange, so I am excited to see what it can do in SharePoint.

    Anyway, sorry for the rambling. I think it helps to get things like this off my chest because I often wonder if other people have been in the same boat. Overall, I just want to do what’s best for my company first and not have to keep fixing it later. 🙂

    • You’re not rambling at all, trust me. You’ve got a long way to go if you want to try to catch up with me in the rambling department! Something you should feel good about (seriously!) is that you’re working hard to define what you don’t know. One of the worst things I see people do over and over with SharePoint is charging in with guns blazing and digging themselves some pretty deep holes because they didn’t take the proper time to get their head around what they were doing and what they actually needed to do. I know that doesn’t necessarily help make you less uneasy about the situation you’re in with the SharePoint rollout project, but hopefully it does provide you with a little validation for what you’re going through. Overall, don’t ever feel like you’re asking too many questions when you’ve got the ear of a trusted adviser, that’s your absolute best opportunity to learn.

      On the subject of learning through Google: it’s something I do ALL the time and highly recommend. I do have two pieces of advice on that approach though:
      1) Verify your information. Look for two different sources that confirm the information you’re getting about your solution or issue before you start implementing it.
      2) ALWAYS read the full post AND THE COMMENTS! I find so much secret sauce in the comments to articles and resources, and often times those comments drastically impact the content conveyed in the article. Make sure that there haven’t been any changes or updates that may impact your information.

      Regarding the IIS Backup update, I haven’t done anything more with it lately, but I did just see a blog post on the subject come through my RSS feeds that may be interesting:

      Based on that post it sure looks easy, so hopefully in the near future I’ll get a chance to add those steps into the script. I’d strongly recommend that you take a look at either baking that into your script as you see fit, or perhaps writing up a separate script to backup IIS and call it with your scheduled task along with the SharePoint script…


  4. Good morning! I ran across this blog entry while trying to research a means of identifying causes of backup failures.
    We recently migrated from SP 2007 to 2010. As a first step, I brought along our old SP 2007 backup script, until something else was set up in place.
    Our old script generates a list of site collections, then loops through calling stsadm -o backup for each one.
    The script was developed long before I joined the SP admin team. When an error occurs, all we see is the string “ERR” in the log where it writes the stsadm commands that are being executed.
    I have looked at the 12 hive – and now 14 hive – logs as well as application event longs and have yet to identify what problems are actually being encountered.
    I notice in your blog you write about having error handling.
    Is there anything available that I could use to identify why the errors are occurring?
    Thank you for your article and the script you have made available.

  5. […] John Ferringer on backups – […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: