We are a service provider hosting several hundred SharePoint sites and we are trying to figure out the best way to do our backups so that they are viable and helpful.

The problem is that when we do a full backup through the Central Administration, it takes about 9 days to complete because we have so many sites. Once that full backup completed, an incremental backup took approximately 5 days. This is obviously not acceptable.

I'm also concerned that those backups aren't backing up everything we need to restore completely (e.g., IIS, GAC, etc). I'm considering a full Windows Server Backup instead, but I don't know if that'll work for a full restore. The same can be said for just doing a SQL backup: I'm not sure if a SQL backup will get us up and running on its own.

Does anyone have any tips for backing up such a large-scale deployment?

Note that for the most part the servers are self-contained. We have one server cluster that has four Sharepoint servers sharing one separate SQL server, but the rest are self-contained.

Thanks for your help!

  • It sounds like what you really need is to scale out your environment: technet.microsoft.com/en-us/video/…
    – Mike
    Jul 12, 2013 at 20:48
  • By the sounds of your backup times, you need to break up your and slim down your SQL databases, and back them up on differing schedules. @Luis has a lot of good points. I will add that if you are virtual, you can get a lot of milage from VM backups and SQL backups. you can pair that with tools like VEEM or SAN tools to get item level restore capabilities. Jul 13, 2013 at 21:51

1 Answer 1


SharePoint disaster recovery is a complex subject and one you should give some serious though.

There are several methods to backup your environment, and one would need a spreadsheet to identify the advantages and disadvantages of each method. I can only tell you that no backup method is perfect when you're talking about large volumes of SharePoint sites.

Before we can talk about the methods, there are much more important things to define like your RTO, RPO and RLO?

  • RTO - Recovery Time Objective
  • RPO - Recovery Point Objective
  • RLO - Recovery Level Objective

Which all combined will mean that you will recover X many components of your farm, in Y hours and will loose the last Z hours of content changes.

Example: In the event of a disaster I want to get my content [SQL content DBs] available for users (RLO) in 2 hours (RTO) and don't mind loosing the last hour of content changes (RPO).

Other components of the farm can have diferent objectives, some of my clients don't backup some of the service applications, they've assumed that those will be rebuilt as part of the disaster recovery plan.

The more components you want to recover the more it will cost you to implement a disaster recovery plan. Reducing the time it will take you to get up and running will increase cost and reducing the amount of lost data will also increase cost.

If you want to backup everyting, are not prepared to loose anything and want to be up and running in no time, be prepared to spend some serious money. The kind of money that will make your CFO turn blue, then red, then green...

Let me ask you a few questions:

  • Do you have a fully redundant farm: SQL cluster, multiple app servers and multiple WFEs?
  • Do you plan on having a cold, warm or hot standby farm?
  • Do you have any custom solutions installed on your servers?
  • Do you have External BLOB Storage enabled?

And for the methods:

  1. A SQL backup is good for content DBs but that's about it, if your content DBs change alot but your configurations don't, then a regular SQL backup (full / diff) of the content DBs combined with a farm backup (using PowerShell) will get you up and running.

  2. Forget the windows backup for SharePoint farms, it's not even supported by Microsoft

  3. PowerShell backups are a good option, the Backup-SPFarm command will let you choose either full or incremental backups, choose the components you want to backup and will let you choose if you want configuration only or both configurations and data.

  4. System Center Data Protection Manager - All singing all dancing backup & restore solution!

Because you can specify the granularity of your backup using the PowerShell command, it's a much more versatile method.

Note that if you never touch your 14 hive (and you shouldn't) and all your custom solutions are deployed via solution packages, these will be stored in the configuration DB, so there is little need to backup the windows file system, if any.

On the other hand, restoring Search Service Applications and User Profile Service Applications is a nightmare on its own, and I'd define diferent RTOs for these.

For PowerShell backup see the command Backup-SPFarm: http://technet.microsoft.com/en-us/library/ff607881.aspx

Also see Backup-SPSite and Backup-SPConfigurationDatabase.

There is a lot to think about, and before you decide on how you want to backup your farm, decide what you want to backup, what you can afford to loose and how long your customers can have they're services unavailable and which services.

Make a good plan and that you can start thinking about methods. What I descrived above is a very brief idea of what you can and should do.

Last but not least, test your backups in your target recovery farm. Are your backups secured? Are you able to use your backups to recover any data? Do you know how long it takes to restore your data if the backup took five days?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.