Amount of SAN storage Required

Hi,

This is going to be a bit of an odd question.

I remember when purchasing a SAN before (EMC Clariion CX3-20) I wanted it to back up all live data on the SAN to another volumen or LUN (believe this is snapshot) and then it would back up to tape every 2 weeks .

The live data amounted to about 4TB. I remember a colleague saying that I should really get approx 16TB of disk space, as to ensure growth for backup data. (I think).

I am trying to remember why so much (it wasnt about money or him being a sales guy) data, but i'm sure it was correct.

Can anyone enlighten me? I know its kind of vague and I cant contact the guy any more.

Thanks if you can help
58872Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Big-Z213Commented:
With SANs you're not just accomodating large amounts of data and providing redundancy, you may also be providing performance. If you have a RAID setup, the more drives you have, the more spindles you have, and hence access times are reduced with more spindles.

For example, you may have a database that requires very fast performance, although it might only occupy 1TB of space, but if you have 16x 1TB drives, you have more spindles reading the data that is spread through disk array, hence quicker the access times. More disks, more spindles.

It really just depends what you want out of your SAN. Certain applications should be set up like above whereas others you could get away with any setup you want leaving an additional 50% for growth or something similar.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
BigSchmuhCommented:
Assuming you need N drives to reach your needed capacity storage.
Redundancy requires 2xN drives in RAID 1/10/1E , N+1 drives in RAID 5, etc

In your case:
-you have 4TB of "live data"
-backuping means "issuing sequential writes" means RAID 5/50/6/60 are allowed if your SAN handles a cache with "write back backed by battery" technology
-I would keep enough storage space to allows to delay the "transfer to tape" and have 2x4TB available

==> I would recommend to go with large SATA Enterprise edition drives in RAID 6/60...this is 10x1TB drives only

Please note that using RAID 10 will require 16x1TB drives...that may be was the point in your case (for example, if the SAN does not allow RAID 6/60)
0
andyalderSaggar maker's bottom knockerCommented:
Live data 4TB, parity 4TB (maybe less), spares 2TB, snapshot area 4TB, reserve space 2TB - that's about where you're at.

I would recommend very strongly about using SATA disks (or anything in SATA sizes - 256GB, 500GB, 750GB, 1TB, 1.5TB etc. unless you are absolutely sure performance will be enough. You don't buy a Porsche and put two-star petrol in it.
0
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

Thomas RushCommented:
When you say, "back up live data every two weeks to another volume, then copy to tape every two weeks" -- do you really mean that you only want to back up once in two weeks?  If you meant to back up daily or weekly, then you'll need more space.

I also recommend that you create the tape backup as soon as you've done your full copy to disk -- why go two weeks with that full copy unprotected?  If your backup is on the same controller as your live data... it's not a backup, it's just a copy.

Consider that instead of using primary SAN storage for your first target, you might be better off with a D2D appliance that looks like a tape target, and allows for easy automated copies to physical tape.  The D2D backup devices look like tape to the outside world, so they're not subject to viruses or accidental deletes like data on a SAN.  Since they look like tape, they also easily let you do incremental or differential backups.  And the best of them let you hang the tape drive directly off the appliance, and let the device itself perform the copy to tape.

And back to your original question -- "why so much space?"  Don't forget data growth.  If your data is growing at 50%/year, as many businesses are, then you'll want to start out with enough space for at least six months worth of growth, and maybe the full year.  How difficult will it be to add more space to your SAN once you're in production?
0
raj27962Commented:
the extra space is for the incremental backups etc, your probably doing a full backup once a month or week, with incrementals most days and a diff every so often, so your 4 gigs of data can easy add upto 16
0
tellawiCommented:
It is important to first understand the concept of space reservation in SAN. The simplest way to explain that is to think of a regular magnetic disk drive - it has addresses that hosts can refer to in order to read or write data - and hosts can always send I/O write commands to these data block addresses again and again - that's the whole idea of an address space.
The SAN filesystem has a different write allocation policy - when you keep point-in-time copy of the same filesystem (Snapshots), the Filesystem keeps blocks untouched, so that one can recover from snapshots that reference these blocks.

So when point in time backup are being taken; the host is still writing data consistently into the LUN, more and more data blocks will be held "captive" by the point in time copy. This is where space reservation algorithms kick in - to protect from causing SCSI write errors to LUNs - by default, every LUN consumes its original size plus another 100% of its size as well as a protection against this rare case of frequent writes into a LUN on a volume with many point in time copies created.

this is way it is recommended in SAN is to enlarge the size of the underlying volume that holds the LUN to occupy additional point in time copies (snapshots).
0
58872Author Commented:
Thanks. Sorry for delay.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Storage

From novice to tech pro — start learning today.