When SharePoint 2010 and SQL Server 2008 R2 presented us with the Remote Blob Storage (RBS) option for a SharePoint content management system, the timing couldn't have been better.
At the time, I oversaw a content management system (CMS) migration from LiveLink into SharePoint for one of the world's largest human resources companies. Its legacy CMS was packed to the gills with old junk files (video, media, JPEGs) that were voluminous but also required because of compliance issues.
Historically, SharePoint has posed
When SharePoint RBS makes sense
Historically, SharePoint has posed a storage problem given the volume of content it can store.
The RBS feature is a useful tool in the SharePoint CMS kit. But like many Microsoft products, it's unfinished. It doesn't support data compression or encryption and requires special configuration for log shipping and mirroring. But these issues are annoyances, not deal breakers. So let's look at scenarios where SharePoint RBS is the right choice.
RBS was designed to accommodate large files in SharePoint. RBS allows them to be stored outside in NT File System (NTFS) storage -- which is far cheaper and more plentiful than database storage. At the same time, it provides all the benefits of SharePoint CMS storage -- metadata, security and administration -- as if they reside in SQL.
Whether you decide to use RBS or not depends on the content you need in your CMS. Are the files large (larger than 256 K)? Are they read- or write-intensive? If they're read-intensive, RBS is the way to go; but if they have lots of write access, RBS is a mistake because RBS storage represents an extra hop in the journey to and from the user. Adding write activity amplifies the burden on the CMS processor.
Enter SharePoint 2013
With SharePoint 2013, you can put peripheral data elsewhere in the same network, which helps smooth out the traffic. Using a remote RBS provider, you can now store BLOB data on a separate server. Note that this requires installing RBS on every SharePoint 2013 server and every database server; you also need to run SQL Server 2008 R2 Enterprise on the database that stores the metadata.
This differs from the old method, where peripheral CMS data lived in the NTFS of the server where SharePoint's SQL Server instance was deployed; the FileStream provider did the lifting, and it is designed to work on local hard drives. A local RBS FileStream provider can't access NAS.
The impressive thing about SharePoint RBS is that, from the user's point of view, the BLOB content is in SharePoint: It is accessed through SharePoint, secured and administrated through SharePoint. This provides SharePoint file utility at a lower cost and with less loss of CMS efficiency.
For more on SharePoint 2013
That's because metadata is associated with peripheral content. This metadata lives in a Filegroup other than the one the BLOB files are in, however, which means you can't back up and restore from SharePoint Central Administration. The BLOBs and the metadata can't be handled from the same place at the same time. It’s not critical, but it is inconvenient.
You can, however, handle the backup and restore of site collections as a whole with RBS providers. And you can back up and restore a farm if you use the FileStream provider.
Finally, if you want to use the RBS feature as part of a migration from another CMS platform into SharePoint, consider building out your migration scripting in PowerShell. Of the various routes you could take when moving things into a SharePoint BLOB store, the SharePoint 2013 Management Shell is likely to offer the fastest, most trouble-free method: You can easily retrieve your BLOB store configuration, list the installed providers, set a provider for the migration and move the data in a single sitting.
This was first published in October 2013