We have a large content database (2.5TB) that we're trying to reduce the size of. The business unit will not let us delete old content, citing a legal need to keep all documents for X years.

The bulk of the content is under a single subsite, so splitting the site collection into separate content databases would be useless.

My manager is pushing the idea of RBS, with the justification being that the bulk of the space would shift onto a SAN drive instead of our local SQL server.

However, while trying to implement RBS in our dev environment, using a copy of the large production database, I'm running into a lot of issues. I've read online that using RBS adds additional backup/restore time as well as additional storage needs, given that it creates a new copy in the blob store each time a document's metadata is updated (regardless of versioning settings in the library).

I've got RBS working in dev for new files, but migrating the existing content is proving problematic - the process keeps crashing, probably due to space limitations.

I've done numerous searches but so far I'm unable to find anything that lists out when and when NOT to use RBS in your environment. Can someone clarify this for me?


SharePoint 2013 Enterprise farm, patched up to August 2016 CU. Content is nearly a million files (DOC, XLS, PDF), Last 2 versions kept, the typical file size is anywhere from 1MB to 1GB. Smaller files are accessed often, larger files are not. Using SQL 2012 as backend.


I should also point out that, when I say the bulk of this content is under one site, I am not exaggerating. Out of 2.5TB, around 2.2TB is in a single subsite. Half of that - around a terabyte - is just in one LIBRARY alone. It's definitely a beast, which is why I'm trying to get the reins on it now instead of later when it hits the 4TB limit.

2 Answers 2


I think you should be aware that if you are using Remote BLOB Storage (RBS), the total volume of remote BLOB storage and metadata in the content database must not exceed the 200GB limit.

Check Software boundaries and limits for SharePoint 2013

This also corroborates to the guidance that RBS does not increase the storage limits of content databases. All limitations still apply to RBS-enabled content databases. RBS is intended to lower storage costs by allowing you to store large read-intensive BLOBs on less expensive drives. For example, if you have 150 GB of RBS data and you have a content database that is 70 GB, this still exceeds the limits.

See Deciding to use RBS in SharePoint 2013

  • So, to clarify, if my total size (content DB + blob store) is going to be over 200GB, it would work... but not be supported by Microsoft. I can see no realistic scenario where that total would get down to 200GB, but I wasn't even aware of that limit so now I know.
    – Omegacron
    May 31, 2017 at 20:31

I think Ransher Singh has covered off your problem quite well.

As for a solution, your original idea of splitting your data into multiple content databases is the right one. It can however be a complex and painful process if you are not using third party tools.

You can roll your own using SPExport and SPImport to export existing webs or libraries or even folders. You could even do it in PowerShell if required but for it to be successful you will need to build new site collections mirroring your current one (active features, content types etc.)

Your other option is to convince your boss to migrate to SPO where you could have a single large site collection and none of the management headaches :)

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.