Replacing File Shares with Sharepoint

I had some folks return to the office recently, from a Sharepoint meetings of sorts.  A message I received was:
"Speaker just talked about moving all of their file shares to SP.  Eric mentioned that our file shares were 6tb and asked how their sql guy felt about that.  Response was that their sql guy originally balked but was reminded that sql was geared for this.  It can handle it and it will happen.  Eric and I immediately thought of you.  :) "

I should say I'm the SQL guy around here, but have dealt with what I consider 'relatively small' databases, and I'm the SQL guy because I'm the person most willing to look at it.  I don't consider myself a 'real dba'.  

All my SQL backups are to disk, and the backup program on the servers pick up the SQL backup files and write them to tape.  When I need to perform a restore, often I have the most recent backup or two still on disk, but even if I don't, I can restore from tape back to disk - and perform a SQL restore to put the database back.  In the past, when someone has lost a file in Sharepoint, and I have to pull back an old copy of the database -- I can restore the database to a different name, and using a vb script, pull out the file the end user needs restored.  (With some databases, I have transaction log backups to work with as well, but all the Sharepoint DBs are in Simple restore mode.)  

Working with 11 GB database files, that means I have 11 GB once for the database, plus a little for a transaction log.  I have 11 GB for the latest backup.  If I need to do a restore, I have 11 GB for the restored database backup file, plus ANOTHER 11 GB for a second copy of the database running.  Working with 11 GB files, it's at least doable.  If someone seriously proposes working with 6 TB Sharepoint DB files, I'm going to experience push back from the financial folks if I ask for 24 TB of drive space.  (And I could bring it down to 18 TB by keeping only one backup file online for any purpose, and if I use backup compression, I might get it down to 15 TB... but that's still pretty significant to replace a 6 TB file share.)

I've done a little poking about, and I see a best practice of using differential backups to speed up the backups, and working with dbs that big, I suspect that'll be necessary, but that compounds my space problem if I ever need to perform a restore.

So now to the questions:
Are there other technologies I'm missing that solve this problem?  (And if they are things like DPM 2010... are they THE solution?  because I'd be giving up TSM backup to a very large tape library system.)
I'm not a Sharepoint person... but I know there is some versioning in Sharepoint... is the standard answer, "No, you can't HAVE an older copy restored?"  Or are people using 6 TB Sharepoint installations just living without backups?
LVL 31
Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooterAsked:
Who is Participating?
sharepointguru14Connect With a Mentor Commented:
Well there are a few things here. First I'll pitch a 3rd party product which I do like alot and it is the AvePoint DataProtection suite to handle the backup restore process. Although backups can be done many different ways they make the restore much easier.

Now that I got that out of the way....1 I wouldn't recommend ALL files in the company be placed in SharePoint. There is a cost there storage in SQL (maybe on a SAN) is much more expensive then typical file share storage. I would only recommend moving files that are going to be actively used into SharePoint.

2nd and this is the part that probably answers your question the best. You wouldn't have a 6TB database EVER!. You would architect your sharepoint environment so that you have content databases in the 100GB or so range. There isn't a hard limit on how big a SQL db can be but after getting above 100GB backup and restores become increasingly more difficult. You can assign multiple databases to a single web application in SharePoint. You do this and spread your site collection amoungst those numerous dbs.

3rd I would strongly recommend a purge of data. When you have 6TB of files there is surely tons of stuff that is no longer needed.

and finally there is something called RBS in SQL. what this does is allow you to store your files in on a fileshare but still expose it through sharepoint. You can create rules like everything over 1mb goes RBS and everything less than 1mb can be stored in the SQL db.
If you have a budget to buy a tool, you can also look at AvePoint again and they have a file connector which will actually leave your fileshares in place where they are, but expose the content in sharepoint giving you all of the functionality that sharepoint provides without the headache of migrating 6TB of data into your SQL environment.
Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooterAuthor Commented:
Thank you Sharepointguru14!
I'll look into AvePoint DataProtection when I get to work in the morning.  (I've avoided third party backup products for SQL in the past, because it adds one additional complication during a recovery scenario.. but it's not such a strong bias that I'm not willing to look again.)

Is RBS related to Filestreams in SQL?  Or is it a completely different critter?
yes RBS is related to filestreams. RBS stands for Remote Blob Storage.

The 3rd party products actually add another component of complexity to the backup process, but with sharepoint they ease the pain of the restore. 2010 made restores slightly better but still really missing the mark with the out of the box restore capability.
Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooterAuthor Commented:
Thank you for your help!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.