2

I'm assisting a client with a SharePoint migration, but have run into a situation with some of the document libraries. The SharePoint server was configured to use RBS via the native FileStream provider. Documents over 1MB were sent to the remote blob store. Several weeks ago, the disks failed on SQL Server. The machine had to be rebuilt, SQL Server was installed from scratch, and the databases restored. The blobs (RBS) appeared to restore cleanly. Folders appeared on the drive that was designated for RBS. I can browse to the drive and see files that have the same timestamp/size as corresponding files in the SharePoint libraries.

Here is the catch. Since the SharePoint server had not failed, it was not rebuilt. Once SQL Server was restored, the SharePoint server was fired back up and appeared to be functioning as before. Its configuration still referenced the same config db and content databases. So there were no noticeable errors until someone (weeks later) needed to open a file larger than 1MB. SharePoint displays a File Not Found error (http 404). So it appears that the linkage between SharePoint and the RBS is in a state of limbo, or that the pointers are messed up in RBS itself.

Let me describe what is happening. If I view a document library, I see a proper list of documents with all of the correct metadata, etc., as before the disk failure. If I click on a document that is smaller than 1MB, everything works as expected. If I click on a document that is larger than 1MB, I get the 404 error stating that the document cannot be found. The SharePoint logs just reiterate that the document at path could not be found.

I have only dozens of documents remaining to migrate. I know exactly which ones are missing from the destination site on Office 365. Since they still show in the list view for the document libraries of the on-premises server, I can see their names, created date, and size. I can browse to the folder on SQL server where the BLOBs are stored. Of course, the files names are all cryptic, but I can find the file by the same size/timestamp. An article I read led me to believe that I could open the file in the client application associated with its original file extension (PDF in this case). I cannot do so.

What I need to be able to do is to extract (even if manually) these missing files from the BLOB store, and copy them into the appropriate libraries in Office 365. So I need to know if there is a tool that will allow me to retrieve a file from RBS back into its original format? Or if there is a way to fix the tie between SharePoint and the apparently orphaned BLOBs that was broken after the disk failure/restore.

Thanks for any advice!

  • As someone about to implement RBS in a large environment with millions of documents... this question scares the ever-living crud out of me. – Omegacron Jan 27 '17 at 23:01
0

What solution did you come up with for this Rob as we’ve hit exactly the same issue from a failed attempt to migrate our RBS back into SQL Server?

  • In our case, it appeared to be a latency problem. I searched for a couple days for a solution, and found none. Then I noticed some of the files that I knew to be missing were starting to show up. Eventually, they were all restored as far as I could tell, so we completed the migration. – Rob Wilson May 8 '18 at 19:13
  • Thanks Rob. I wish we had the same happy story. Thankfully we managed to find a database backup that still had the RBS references within the records so that was put on an old development environment and we used ShareGate and a custom PowerShell script to basically delete and copy across the individual files. It looks us months to fix it all. – James Buckingham Jan 24 at 9:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.