RBS Primer

Problem: Provide a quick overview of Remote Blob Storage (RBS).

Overview:  When uploading files into a document library or list, the data is stored in the content database, this consists of meta data and the binary blob.  All content database storage is done using SQL Server, the recommended maximum threshold for content databases is 200GB (they can be bigger depending on you IO speed on your SQL Server - this applies to SP2010 (pre SP1), MOSS had a recommended 100GB content db limit from MS) these binaries can make your content database big that results in expensive storage as the disks are usual RAID 10, backup operations can take a long time and speed of data access/write can slow down.

You can configure RBS on a per content database on your farm using 'storage providers'.  There are 3rd party suppliers that provide the storage and the 'storage provider' and they make claims of saving clients up to 90% of their content database size.  You can also store the blobs on files systems.  RBS is useful for medium and large farms, it can be applied retrospectively be setting up RBS on a content db and performing a backup and restore.  EBS was performed at a farm level whereas RBS is content database level.
RBS is only a good candidate if your content database has blobs, the blobs are individually bigger than 256KB and you content database is over 100GB.  RBS is more useful on really big content db's.  Content database size is bizaarly calculated by including the content db size plus the RBS storage.
Tip: RBS is similar to EBD in MOSS except it's applied at a content db level.
Tip: RBS requires SQL Server 2008 R2 (I'm not sure if SQL 2008 will work).  FILESTREAM needs to be activated on SLQ Server for RBS to work.
Tip: SP 2010 has a hard limit of 2GB per item, this is due to SQL server using the varbinary (max) column type for storage and IIS recommended max app pool sizing.  Changing to RBS will still enforce a maximium size of 2GB per file.
Tip: RBS is setup on the farm using PowerShell there is no CA UI interface.

What RBS gives you:

1. Performant SharePoint farm - the most common bottle neck is SQL Server in SP2010 farms, by reducing the blobs being stored and retrieved within the content database you get better performance on your farm.
2. Lower cost of disk storage - SQL is normally stores data on your SAN, these disks are expensive and usually RAID10.  Additionally, the backup/HA/mirroring/clustering will also be expensive disk space.  Using RBS moves all your storage to cheaper disk storage.  Furthermore, you normally use an external RBS supplier so if you RBS storage is growing you only pay for the current storage unlike in SQL you would need to have the space to provide for future growth.
3. Faster DR - Your farm backup and recovery process will generally be faster but more complex.  As the content db's are smaller you can backup and recover quicker however you now have to ensure RBS data is part of your DR planning.
4. Dead link data - you need to run RBS tools to delete data from RBS that has already been removed by SP2010.

Source: Srini Acharya & Burzin Patel - Externalising BLOB storage in SP2010 slide deck.  This slide shows the process of saving a document using RBS and SP2010.

Providers of RBS:

• AvePoint
• OpenText
• EMC (EBS based I believe)
• StoragePoint (Metalogix) EBS or RBS based.

More Info:
http://technet.microsoft.com/en-us/library/ff628254.aspx