Is it possible to backup content in a SharePoint DB that is using RBS with SMSP? [ Edited ]

[#1]

Our SP admins want to setup a content DB to use Remot BLOB Storage (RBS) for a site that hosts large video files.  He set this up in a test SP environment, but now SMSP shows the content DB as disabled (I cannot check it to back it up with SMSP).  Is there a way to use SMSP to backup RBS content databases?  In the documentation, it talks about using SMSP to migrate files for you (using either EBS or RBS) - but I am not looking to use SMSP to perform this function. Instead, I just want SMSP to be able to back it up like any other content DB.

Thanks

NK

[#2]

SnapManager for SharePoint (SMSP) does allow for the backup of SQL databases that are RBS enabled.

There are a few requirements for things to work:

SnapManager for SQL and SnapDrive for Windows need to be installed on the database server.

The database server needs to be connected to the NetApp and the databases need to be on NetApp LUNs.

SnapManager for SharePoint member agent needs to be installed on the database server

From a security perspective, you need to give the SMSP service account sysadmin permissions on the SharePoint databases (page 18 of th SMSP IAG).

Please keep in mind that third Party RBS providers are not supported with SnapManager for SharePoint.

Can you provide any further information about your environment?

Thanks,
Mark

[#3]

Hi,

Thank you for the prompt response.  All of the requirements you mentioned in your reply are setup.  We are an existing user of SnapManager and have been sucessfully backing up SP 2010 content for several months.  So everything is in place as you describe.  This issue is, is that we recently enabled FILESTREAM on one of the content databases in our test environment in order to test using RBS on a specific SP site for which that content DB is dedicated to.  Our SP admin wanted to test the feasiblity of using SharePoints built-in RBS feature for large video files.  However, as soon as he enabled RBS on that content DB, I am no longer able to backup that DB.  So I started researching the EBS/RBS features of SMSP, but all I can find is infomation about using it to archive data for us - however, I don't need this as RBS is already taking care of doing the archiving for us (it is a seemless process from what I understand).  But I do want SMSP to be able to backup that data, if possible, in that content DB now that RBS has been enabled.  If it is not possible, I understand, but if it is possible, I am looking for instructions on how to make this work.

Thanks

NK

[#4]

Did you run the SMSQL configuration wizard on the database server after enabling the RBS FILESTREAM?

It may be that SMSQL is not aware of the new FILESTREAM object. It can account for new databases, but it may be that SMSQL does not know about the FILESTREAM object and the backup fails. Attaching the SMSQL backup report file from a failed backup may help confirm this.

Just to let you know SMSP RBS has both the capability of externalizing content as well as archiving content. The extender function in Storage Optimization in SMSP handles the policies to externalize the content. The extender policies are based on database and content size.

The archiver function is used in records retention scenarios where you want to age out content using business rules based on records retention policies.

In the case of the video, you would apply extender policies to the web application with the video content.

I think that you might get better performance with the SMSP RBS provider instead of FILESTREAM RBS.

When comparing the video access from FILESTREAM RBS or SMSP RBS, when you get video data from SharePoint, it is actually treated as HTTP download because SharePoint itself doesn’t support streaming protocol.

First for FILESTEAM blob data access, the request is sent from WFE to SQL, and then converted by SQL and mapped to a file share UNC path to FILESTREAM data store, and then FILESTREAM RBS provider on WFE access the data using the file share UNC path. The SQL FILESTREAM RBS provider needs SQL to convert the FILESTREAM to file hare UNC path, and then it rely on the windows file server on SQL to expose the share, in the case the FILESTREAM is on iSCSI based LUN (on the filer), the file server on SQL also needs read data from SAN first and then pass to WFE. SQL server also rely on an additional file system filter driver to process the UNC path to FILESTREAM share, which will add more overhead for FILESTREAM read/write.

For SMSP RBS provider, the RBS provider gets the blob requests and then directly reads the path on NetApp storage so the CIFS read/write between WFE and filer can have greater performance than reading from local disk on the SQL server. The performance depends on the type and number of disk drives on the NetApp where the BLOBs are stored.

There is a tool in SMSP 6.1 that will allow you to convert SharePoint FILESTREAM RBS stubs into SMSP RBS stubs. The tool is called SMSP2010StorageRBSTool.exe and the procedure to convert the stubs is on page 227 of the SMSP 6.1 IAG.

Thanks,
Mark

[#5]

Excellent suggestion.  However, when I run the SQL wizard, it shows that FILESTREAM database as invalid and I don't know how to make it "valid" using the wizard.  I have attached a screenshot.

NK

[#6]

SMSQL has configuration rules based on Microsoft API requirements. The main thing about SMSQL is that all of the files on a LUN have to be laid out in the same way.

So in the case of this database with the SharePoint RBS enabled, it is sharing a database LUN (or VMDK as the case here) and transaction log LUN with other databases.

You will have to move the database files and RBS files to their own LUNs and SMSQL should be able to backup the database, transaction logs, and the filestream data.

Alternatively, you can use SMSP RBS remove the FILESTREAM object and not have to move anything.

Thanks,
Mark

[#7]

OK - I will try that.  So right now, the RBS content DB is on the same drive as all the other content DBs and the BLOB data is on the F: drive.  So are you suggesting I move the RBS DB to the F: drive so that the DB, Log, and BLOB data are all on F: or do I move the RBS content DB to yet another drive so that it is seperate from both the other content DBs and the BLOB data?

Current:

S: All content DBs and LOG files

F: BLOB data

D: SQL System DBs and LOG files

Future 1:

S: All content DBs and LOG files except the RBS content DB

F: BLOB data and the RBS content DB and LOG file

D: SQL System DBs and LOG files

or:

Future 2:

S: All content DBs and LOG files except the RBS content DB

F: BLOB data

G: RBS content DB and LOG file

D: SQL System DBs and LOG files

NK

[#8]

I suggest the layout to look something like this:

S: DB and Log files that are not RBS enabled

G: DB and Log files that are RBS enabled

F: BLOB data

D: System Databases and Log Files

Thanks,
Mark

[#9]

Excellent - thank you so very much for the help.

NK

[#10]

I have been doing a bit of research, I think I was a bit confused by the terminology and technology.  For example, I assumed FILESTREAM was a feature that enabled RBS to work.  But from what I read, it sounds like the two are different techniques to achieve SQL optimization.  FILESTREAM is a SQL tecnology whereas RBS is a set of APIs that allow other products to plug-in and do what FILESTREAM can do, but in a different way.  So I think that SnapManager is more of a product that plugs into RBS and does BLOB archiving, instead of what I had originally thought, which was SnapManager needing FILESTREAM to work.  I bet when we enabled FILESTREAM, it broke the backups because SMSP does not work with it.  I also thought EBS was a NetApp technology and RBS was a Microsoft technology - but I now it sounds like EBS was just the older version of RBS and both are Microsoft technologies.

So anyway - I think I am going to start fresh and sit down with the DBA and SP admins to figure out how we want to do this.

NK