• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 510
  • Last Modified:

SharePoint 2010 Backup Strategy

I need some help with creating a backup strategy for SharePoint 2010, backend using SQL 2008 R2.  Can someone please give some insight, or point me in the right direction to a good site to read about it.

I've read a number of things, but it's all kind of confusing.  What technology should be used, PowerShell or SQL backups?  

I've read that Sharepoint should be used for the config and central administration content database backups...but then SQL backups can be used for all the other databases.  SharePoint should be the only option for the config/administration content database, because if you try to restore a SQL backup of these databases you'll corrupt the database.  Can someone cofirm and/or deny, with some explanation?

If SharePoint should be used for those two databases, then why not simply use SharePoint for all databases?  I'm assuming that SQL backups would be more efficient, but what else would I be gaining from using SQL backups?  Is it just point-in-time recovery, with the transaction logs?

It seems as though I'd be creating a headache for myself if I were to backup some of the databases using SharePoint and SQL backups for other databases.

Point is, I need to create a strategy and I'd like to know what I'm talking about before making any recommendations.

C Williams
C Williams
  • 2
1 Solution

regarding the SQL database behind Sharepoint, it'd be better to take SQL backup.

Create a Maintenance Plan for each of the following:

- Full Database backup (must include all the "use database", with a backup file for every DB)
- Incremental backup (differential, with the same options as the FULL)
- Transaction logs backup (only for the Sharepoint DB's )

In this way you are sure you can restore any version of the DB as per your policy and just restart the Sharepoint software immediately after.

I was discouraged by Sharepoint guru to make it differently, since the backup will be less reliable and more difficult to restore. The SQL backup can be easily moved to a new machine and then used to rebuild all the configuration.

I don't understand why a backup made by SQL should corrupt the DB itself if restored. It's the native way to do it, and it works pretty well. Of course, you need to have the transaction logs backup, otherwise you risk to compromise the integrity of the DB and Sharepoint might present several issues.

Hope it helps.
C WilliamsDBAAuthor Commented:
Alright, I appreciate your suggestions.  I've just read in a couple of locations that restoring the configuration database and the central administration database from a SQL backup is not supported, some even saying that it simply won't work and you may corrupt the database.  But in theory, I completely agree with you...I'm just concerned because of the difference in opinion out there.

I wonder if anyone else can confirm what I'm thinking and what you're saying.
Well, I must say that on the first configuration I had the opportunity to talk with an high expert and he confirmed this was the best option for the Sharepoint backup. Indeed it's the one I use. It'd be nice to hear from other experts btw.

Kind regards

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now