cancel
Showing results for 
Search instead for 
Did you mean: 

Help - BE2012: Determining Disk Space Needs for Deduplication Volume

edj3184
Level 2
Hello all,
 
Today I'm needing help on determining how big our deduplication volume should be.

I've been tasked with calculating the rate of data change across all of our servers that are to be backed up with Backup Exec 2012. We need this information to determine the size of the deduplication volume that we need for this to work. We have purchased the dedupe option already. 

I've tried to do my due dilligence in researching this, grilling Symantec support reps and "sales engineers" ( who are useless and exist only to sell the product - indeed, this experience has taught me the true meaning of the title "sales engineer" - a waste of space.  One of these..."engineers" even went so far as to ask me during a conference call WITH MY BOSS, "did you do your research?" ), but I'm at a loss as to how to prepare this analysis.

I suspect that this requires a historical account, broken down weekly or monthly, of disk space used up across all of the servers / partitions / folders that we desire to back up.

Well I don't have that! So...what now? Do I bust out my business Calculus book for this?

 
1 ACCEPTED SOLUTION

Accepted Solutions

teiva-boy
Level 6

File servers are easy to figure out.  Take your incrementals and divide that into your fulls.  That'll give you your rate of change on file servers.  Industry average is around 1-3% for file servers.

Exchange 2010 will be around 10% daily rate of change.  Exch2007/2003 will be much less around 3-5%.  You can take your transaction log totals and divide that by your Db size, to get a rough idea on change rate for at least 2007/2003

SQL will depend..  But as a rough guess you can take your transaction log totals and divide that by your Db size. 

*Note for Exchange and SQL, you can screw your dedupe rate if you rebuild your indexes or run an eseutil.  Your dedupe will go to zero.

Don't forget to facctor in retention.  You need at least 3+weeks of retention to see any real dedupe levels.  Factor in you havee a 10TB backup and 30days retention, you should have around 12-13TB of disk.

You can message me privately if you need more help.

View solution in original post

7 REPLIES 7

teiva-boy
Level 6

File servers are easy to figure out.  Take your incrementals and divide that into your fulls.  That'll give you your rate of change on file servers.  Industry average is around 1-3% for file servers.

Exchange 2010 will be around 10% daily rate of change.  Exch2007/2003 will be much less around 3-5%.  You can take your transaction log totals and divide that by your Db size, to get a rough idea on change rate for at least 2007/2003

SQL will depend..  But as a rough guess you can take your transaction log totals and divide that by your Db size. 

*Note for Exchange and SQL, you can screw your dedupe rate if you rebuild your indexes or run an eseutil.  Your dedupe will go to zero.

Don't forget to facctor in retention.  You need at least 3+weeks of retention to see any real dedupe levels.  Factor in you havee a 10TB backup and 30days retention, you should have around 12-13TB of disk.

You can message me privately if you need more help.

edj3184
Level 2

Thank you very much for your reply this morning :)  Totally gives me a direction to go towards now.

The email server won't be a factor in this analysis.  We don't have an Exchange server - email's hosted with a company we contract out to.

So what you mean by the following: 

File servers are easy to figure out. Take your incrementals and divide that into your fulls. That'll give you your rate of change on file servers. Industry average is around 1-3% for file servers.

Does it equate to this?  Is my train of thought on the rails here, so to speak?

Where X = weekly sum of all incremental backups performed  ( in our enviro, Monday through Thursday.  4 incremental backups are done, one for each day )

and Y = weekly sum of all full backups performed ( only one is done during the week - on Friday ).

Then,

Y / X ?  Or the other way around?

 

To add to this, I have another question - how can we use this rate of change to determine our disk space needs for the deduplication volume?

pkh
Moderator
Moderator
   VIP    Certified

Get a partner to run the

https://www-secure.symantec.com/connect/forums/introducing-backup-exec-deduplication-assessment-tool

for you.  This will give you an assessment on how dedup would help in your environment, dedup rates, etc..  Unfortunately, the BEDAT is not available to normal users, only the partners can access it.

edj3184
Level 2

I've contacted the vendor we purchased our BE2012 licenses from and got the ball rolling on this this AM - here I am trying to circumvent having to go through this process of hunting down an available rep who can do this for us...it feels like such a waste of time. 

Why must you restrict this tool such that only "partners" can use it?  This is absolutely ridiculous. 

I'm voting down your post because of this process.  Once Symantec CORRECTS this process I will remove that demotion ( if that's at all possible to do in this forum ).

I hope you understand and don't take it as a personal slight.

This is one of many gripes I have with Symantec and their product line in general...WORK ON RECTIFYING THIS - PLEASE.

teiva-boy
Level 6

So 1TB FULLS, and each day you had an incremental of say 50GB, 35GB, 100GB, 200GB.

Thats a daily change rate of 5.0%, 3.5%, 10%, and 20%. or an average of  9.6%, which you can use 10% just to be safe. (My math sucks, and I was terrible at it as a child, so if I'm off, I'm sorry)  

Incremental/Full is what I used.

That said, if you then did daily incrementals and weekly fulls, storing 1 month of backups on disk...  That one month of backups, can be stored in about 1.15TB of disk.

If you didn't have deduplication, it would work out to about 6.6TB of disk needed for just plain JBOD.

I will warn you, that you're getting at least a 5-6x reduction using deduplication in my calculation.  And not all data is created equal.  Typically OST devices from Exagrid, DataDomain and the like dedupe more aggressively than BackupExec.  But they also cost more.  You really do get what you pay for here in this case.  So let's assume BackupExec only get's a 2-3x reduction.

So let's say you need more like 2.2TB of disk to store your 1TB of backups for a month.  Which is still better than buying 6TB of disk.

At the end of the day for most dedupe products, you need 1:1 storage at minimum, and the more fulls you retain, the better your dedupe rate.  Change rate will be the biggest factor in determining the required capacity.

 

 

 

 

pkh
Moderator
Moderator
   VIP    Certified

We, Trusted Advisors, do not work for Symantec.  We are users just like you.  The restriction is imposed by Symantec not me.  You are shooting the messenger.  Do get your facts straight before you shoot off your mouth.

If you do not like my suggestion, you can ignore it.  I find your answer offensive. Who are you to tell me to work?  I do not like to be shouted at, especially when I have done no wrong.  Regardless of whether I am a Symantec employee or not, when someone is trying to help you, you do not turn around and slap him.  It is extremely rude. Throwing infantile tantrums on a public forum does not reflect well on you.

edj3184
Level 2

My apologies to you, pkh, and the community here. 

Soon after that childish rant I posted, I had to be hospitalized for bipolar disorder.  I had a blood pressure spike that week ( 223 / 97...yeah, I was quite "fun" to be around) and I was sent in for evaluation in a psych ward, where I stayed over a week.   

I've been released a week ago and the meds work great.  Now I'm getting back into work mode and catching up on things at the office.  I will be contacting our vendor tomorrow to hammer out details on running the dedupe calculator. 

Again - my sincerest apologies.  The only thing I can do now is contribute positive things to the community from here on out.  The meds will most definitely help me do that :)

I really wish I could say I was lying about all this, but it's the truth.  I wouldn't wish this on anybody...