Currently we have a series of scheduled granular backups for the site collection level that use the PS "Backup-SPSite" command (e.g. https://myportal.com). I test these backups frequently, and have found them to work fairly well when restoring to a SP server that is already fully configured the same as the original SP server that was backed up from.

I am wondering if we should also be performing a scheduled backup of the content database specifically via SQL, and if we should, why we would want to consider doing so?

I would also be curious to know how this is different from a granular backup on the site collection level?

Lastly, are there any other backup options that I failing to consider? Our SP site collection is under 10gb and is relatively simple (one physical server, one farm, everything in one spot).

I did take a read over the Microsoft SharePoint Foundation 2010 Backup & Recovery overview document, but I found it to bring up more questions than it answered:

1 Answer 1


If your storage window allows. More options for backup provides a better, stable and reliable system for restoring data that is corrupted, deleted, or otherwise not available. If one fails, you now have another net of security. I would even go so far to only allow one copy of backups. Obviously, if storage is a pain to keep/get, I wouldn't worry about it.

Edit: I won't say "Always", because it depends on the company's decision whether or not that is something they want to invest in -- another backup failover.

To answer your question about backup types - they are the same, its either granular (site coll) or farm backups. I would also look into farm backups, just in case your whole system crashes--especially if you have a single-server deployment.

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.