Cutting through the BS around EBS and RBS

By Dave Martin posted 12-01-2010 13:45


Okay, I’ll do it.  I’ll deal with the elephant in the server room.  I will try, at the very least, to get a dialogue going around the two APIs that Microsoft has created for the externalization of content.  [Please note that I did not say that these APIs were created for the externalization of SharePoint content, as I have read and discussed enough to know better].

Of course I am talking about the External BLOB Storage (EBS) and Remote BLOB Storage (RBS) APIs. And this topic for me comes long overdue as I have been talking to everyone I know who knows anything about externalization of SharePoint content, repeatedly, for the last two years.

I think the moment that sticks most firmly in my mind occurred at TechEd this year.  I was sitting in a SQL Server session listening to a gentleman speaking quite descriptively about both SQL’s FIlestream and RBS capabilities.  Every once in a while he would mention SharePoint 2010 and when he did so he only mentioned RBS.  I found this curious as SharePoint 2010 had yet to Release to Manufacturing.  I thought to myself, “Surely he was aware of EBS?”  And I’m certain he was, but he never let-on like it.  So at the end of the session, during Q&A, I asked a question… well a string of questions… which resulted in a curious look and for me, a disappointing answer.

I asked: What about EBS?  Does SharePoint 2010 still support it?  If I have deployed an EBS solution are there tools to migrate to RBS?  Is that even a possibility?

The answer: You should probably take that up with the SharePoint guys.


Since that moment, I made it my life’s mission to figure out as many whats and whys around these two APIs to try and surmise when I should use which, and how.  Okay maybe not my life’s mission, but at least an adamant pursuit.

To you I would like to present, the facts!

Fact #1: SQL Server is not the best place to store BLOBs. I’m not saying it’s the worst place, but I have read a few TechNet articles stating that at a certain point storing large volumes of BLOBs in SQL will negatively affect performance.  This is ultimately why I’m writing this post.  Microsoft - understanding that SQL isn’t always the best home for BLOBs - went out of their way to ensure customers had a solution to resolve the issue and created both EBS and RBS.

Fact #2: EBS was created by the SharePoint team for SharePoint. EBS shipped with Service Pack 1 of Microsoft Office SharePoint Server 2007 (MOSS 2007) and was specifically designed to help organizations (overwhelmed with rapidly growing SharePoint databases) redirect the BLOB content into another storage environment (like SAN or NAS or File Systems) to help reduce the load on SQL and ensure performance and scalability for SharePoint.  EBS can be used with both MOSS 2007 and SharePoint Server 2010, SQL Server 2005 and 2008. Lastly, EBS can externalize down to the individual BLOB level.

Fact #3: EBS requires a little help from its friends. Basically, EBS doesn’t offer everything you need to simply start redirecting BLOBs.  It requires a third-party handler or as some refer to it, a provider, that helps redirect the BLOBS normally destined for SQL Server into the storage device of your choosing. This provider will be COM based and not .Net, so in terms of SharePoint 2010 it’s a little antiquated. Also, someone has to clean up after EBS, meaning there is no garbage collection capability natively offered so this too must be created by a third-party.

Fact #4: RBS was created by the SQL team for SQL Server. RBS is part of SQL Server 2008 R2 so in order to use RBS you of course must be using SQL 2008.  If you have decided to support SharePoint 2010 and back-end it with SQL 2005, you WILL NOT be able to use RBS.  So there are a few overall infrastructure and deployment considerations you’ll have to make if you’re transitioning to SharePoint 2010 and intend on externalizing content. 

Fact #5 – RBS needs a little less hand-holding. Microsoft makes the creation of a provider a little easier by providing an interface and specification for third-parties to leverage. Also, garbage collection is made a lot easier as Microsoft has included an executable for RBS called RBS Maintainer so no third-party dev required here either.

Fact# 6: RBS is not SharePoint aware. Because RBS resides within SQL 2008, SharePoint itself has no clue it’s there, as RBS only ships the BLOBs to the external storage, without any real context regarding what the content is itself.  To add to this, RBS is pretty much an all or nothing option, such that if you are externalizing SharePoint content, you have to externalize the entire DB (as mentioned EBS lets you get a little more granular).

So what is the result of my life’s work? From what I’ve seen it would be fair to say that RBS is pretty much the wave of the future and Microsoft is dictating that this be the case, but that isn’t to say EBS should simply be discarded (it will be supported through the life of SharePoint 2010 plus maintenance and support). I think the bottom line here is that both EBS and RBS can help you do the same thing, each with its own intricacies, each ideally suited for different use cases.  With that said, choose wisely, and as always, choose based on your organizational requirements.

#SharePoint #storagemanagement #SharePointarchival #EBS #RBS #externalization #sharepoint #SharePointstoragemanagement #SharePointgovernance