SharePoint 2010 GRT restore job fails with RBS

[Florian_Baumann]

Hi folks,

I just installed a SharePoint 2010 Server on a Windows Server 2008 R2 in a vSphere 4.1 enviroment. The database server is a physical SQL 2008 R2 (no cluster). 

For one site I activated RBS (Remote Blob Storage) with the FILESTREAM provider, which is working as expected.

We use Backup Exec 2010 R2 x64 on a Windows Server 2003 R2 SP2.

The backup job of the SharePoint DB runs fine without errors, I see all files in the restore dialogue.

Now the problem: the restore job fails with the error as described in http://www.symantec.com/docs/TECH68747 :

An error occurred on a query to filegroup ContentDBName\/\SiteName/DocumentLibraryName/DocumentName.doc

V-79-57344-33938 - An error occurred on a query to filegroup ContentDBName \/\DocumentLibraryName/SubfolderName/DocumentName.doc

With the exception:
WARNING: The file DocumentName.doc was restored from a file that was corrupt when it was backed up, or the backup file is now missing or corrupt. Try restoring the file from another backup, or try repairing the file.

I enabled debug logging, but there are not the entries described in the KB Article (probably because they are referring to Backup Exec 12.5).

I didn't saw any errors at all. (on SQL Server or SharePoint Server)

With RBS deactivated the restore job works perfectly fine. The issue is definitely RBS related.

Any ideas how to solve this problem?

Thanks!

Greetings Florian
 

[Florian_Baumann]

Hi,

after some reading and trying to get it worked, i'm wondering if RBS on SQL 2008 R2 is even supported in Backup Exec 2010 R2.

Has anyone some experiences with it?

Greeting Florian

[Conrad_E_]

I'd like to know the answer to this as well.  I'm trying to get this setup in my lab for evaluation, but I'm also getting the same exact error with a FILESTREAM enabled SharePoint SQL database.

I'm currently evaluating Backup Exec 2010 R2 as a backup solution.  If I can't get this working, I'll be looking at Microsoft Data Protection Manager next.  Unfortunately Symantec won't let me open a support ticket on this because I don't "own" this product yet (I'm still evaluating the SharePoint client), even though I have full maintenance and support on all of my Backup Exec 2010 servers.

Hopefully someone here can help on this, otherwise I'm off to MS and DPM 2010.

*** Edit ***

According to this, BE 2010 R2 supports SQL 2008 Filestream enabled databases.  How about SQL 2008 R2?

1998144

Unable to redirect a SQL 2008 database restore with SQL FILESTREAM enabled.

http://www.symantec.com/business/support/index?page=content&id=TECH137044

[Florian_Baumann]

Hey,

I opened a case at Symantec MySupport two weeks ago, no solution yet.

I let you know, if a solution is available.

Greetings Florian

[Conrad_E_]

Wow, no solution after two weeks?  I'd very much appreciate hearing about a solution if they do come up with one.  I wouldn't be surprised if this is fixed with a patch since they didn't have a quick answer for you.

I'll let you know where I get with my DPM 2010 testing.  :)

Conrad

[M_Selinger]

I'm seeing the same errors in my environment.  It seems to backup with no red flags, but restoring results with this message.

The file DocumentName.doc was restored from a file that was corrupt when it was backed up, or the backup file is now missing or corrupt. Try restoring the file from another backup, or try repairing the file.

Even if I'm redirecting the one file I'm trying to restore to the local desktop it's failing.  Do you thing RBS is still involved?  A solution to this is critical....

[Conrad_E_]

Well, this may be a SQL/RBS problem.  As I mentioned earlier, I tried doing this same process with Microsoft DPM, and their product is having a similar failure when attempting the same operation as we're seeing here with Backup Exec.  With DPM, I am able to successfully perform a backup, but receive failures when trying to restore to the RBS enabled database. 

I opened a case with MS regarding the DPM/SharePoint/RBS problem, and after lots of internal testing they have acknowledged this as a bug, MS SR number 110120161904125.  Their work around was direct the restore to a "restore" server, then copy the item back to it's original location.  However I still have a problem with this since this process might not preserve some of the metadata (created/modified dates, etc..) of the item.

They have not mentioned any plans for a fix, only mentioned this one work around.  Hopefully Symantec is addressing this with MS internally as well and they'll get MS to generate a fix someday (SQL 2012 anyone?).

I'm holding off on recommending RBS implemented in our production environments until I can get an acceptable solution to this.  Sorry for the grim news, but it looks like this may be bigger than just a Symantec bug.