Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Short version:

I'm building a NAS box to act as storage for backups. How big does it need to be compared to the amount of data it's backing up to adequately cover deleted files and previous versions of files (assuming that I save incremental changes rather than full backups)?

Long version:

I'm looking to replace our existing storage over the summer. Currently it's just a trio of RAID 5 volumes located in a 7-year-old server; total space: ~550GB. Backup is to 40 400GB tapes. Since server C: drives and system states live on those tapes as well and the existing space is starting to fill up, we've moved to a staggered backup (every weeknight does a full backup for 1/5 of the total, plus a differential on the rest).

To keep it simple I'm planning for a straight migration of our existing three volumes to newer, bigger, faster ones. We still have a lot Windows XP, so I'm hoping for 6TB of space to max out each volume to the 2TB supported by XP, so each volume with have 4 1TB disks in RAID 10. For backups, I want to ditch tape and go all disk.

So here's the plan: I'm hoping to build 3 units. The first two are the primary and a hot standby. I'll replicate to the standby nightly. The final unit will be for backups, and I'll locate it on the far end of campus and use my existing Backup Exec software to pull from the standby unit to the backup unit (pull from the standby to reduce network contention or downtime on the primary). Since all the new systems will be running Server 2008 R2, there's no 2TB storage limit any more. My backup unit can use much larger volumes.

This should have multiple versions of files for the "Oops, I deleted that file I needed. By the way, it's been a week" case and also protect against the "Oh no, our server room caught fire" scenario.

So my question (at last) comes down to this:

Is there a good rule of thumb for how much space should I build into the backup unit (and if so, what is it)? If not, what do I need to know to make an informed decision about how much space I need?

To this point, I've been planning on about 2.5x more space than my primary (or about 15GB), but I'd like something a little more accurate than a number I pulled out of the air.

Part 2: comments on my general strategy here are appreciated. What am I missing? How could I do this for less?

share|improve this question
add comment

1 Answer

I've come up with a potential answer to my own question that I can provide for other comment/vote on:

I can plan for a new full backup each month (or other fixed period), with incrementals every night, and use logs from my existing backup as a reference. I'll take the size of my current full backup and compare it that plus to the cumulative size of all my differentials in the last 30 days. That should give me a better idea of the ratio I'm looking for, at least relative to how we currently use our data. It's not perfect (weekly differential will be larger than daily incremental), but it's better than the guess I'm using right now.

Of course, I'd like to hear comments on how well people think this will work, how (in)accurate it will be, and on issues I raised in "Part 2" at the end.

share|improve this answer
    
I think this is exactly the approach you should be taking. It's hard to come up with a number that will work for you (beyond just guessing), without some analysis like you've described above. –  LukeR Mar 29 '11 at 22:34
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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