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.