I'm looking to deploy Symantec Backup Exec 2010 and I am trying to figure out how much storage my media server should have to allow for adequate growth and retention periods. 2010 offers block level de-duplication which changes the game dramatically. This seems like a stupid question but how do you calculate rate of changed data and then turn that information around to estimate backup storage needs.



Run a full backup. Then run an incremental backup on the following 6 days. Take the total of the amount of data from those six incremental backups and divide by 6. That gives you the avaerage daily rate of change of the data being backed up. Multiply the average daily rate of change by the number of days in your retention period and that should give you an idea of how much storage you'll need. If you perform differential backups instead of incrementals then you'll need to calculate the total of the 6 differential backups and multiply that by the number of weeks in your retention period. Don't forget to include the number of full backups that will occur in your retention period into your storage calculations.


Ask management what growth they are expecting the business to see in the coming months/years. Sure it won't link directly to amount of disk usage (unless you're selling disk space) but it'll be some indicator as to expected growth.

Extrapolating from previous data is also good, but that's not always available - either you backup solution isn't giving that kind of data or there is no backup system in place. But combined with growth forecasts from managers it's a good answer.

If your solution makes it easy to add extra space to backup to later then don't worry about it too much from a technical point of view (though presumably you'll need to estimate costs for somebody). If it's relatively difficult to add extra space then add as much as you can justify now.


Can you get some statistics from your existing backup program?

For example, see how long it took to complete the backup, and what the backup size was on the first of every month for the last year.

Put this into a spreadsheet and see if you can determine if the rate of change is constant, or whether it is increasing. From there, you can try and extrapolate what it might be in a years time from now. You might want to add up to 20% of storage capacity more than you expect, just for a bit of wiggle room.

It's never an exact science, and something I hate trying to do - but if you try and calculate it, and in a year you are running out of storage, you can say "at the time, with the information I had - we made the right decision about the amount of storage we needed".


I can't honestly say I have an answer to your question, I could suggest looking at previous data, capturing current changes etc. but it's all going to be in vain as what you're asking is going to change every day. What I can suggest is that you buy a Media Server with a lot of disk slots and use a controller that can expand an array easily. As an example we use HP's DL380 G6's for these Media Servers, they can have 16 disks in so what we do is use two mirrored disks for OS/code and then install a minimum of 4 disks for the temporary data store in a R6 array. The built in controller can then expand this R6 array quickly if we guessed wrong. This way you can go from a small ~1TB temporary data store up to ~7TB in 600GB chunks as and when we see the need.

Hope this help.s


Cant talk about Backup Excec, but in the Commvault world we use the following as pretty good estimate.

Take the amount of space you require to perform a full backup of your systems, and then double it. For example you have 750 GB of production data, provision 1.5TB of capacity on your Media Agent.

This will now allow you to hold 1 month of backups on disk (de-duplicated). I would always allow a little extra head room for growth.

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.