Backup to Disk: Retention and Sizing
-
So I am having a discussion with some collegues at work regarding a standard sizing for backup space. We backup to a separate backup disk on the server, and sweep through and pick up the backup to VTL.
I have been telling them that I recommend 2.5 times the potential growth, which is essentially the size of the data disk. (of course it would never get past 90% as we would always expand the disk)
I stated, on a 100GB data disk, we should provide a 250GB backup disk. They think I am nuts. 1.5 times is enough (150GB), they say. My problem with this is even if you are only doing a weekly full and retaining one week, once your backup gets to 75.1GB... you cannot create your new backup and then delete the older backup. Which I think is the safest way to go... you should have a validated backup before you remove the old one.
And that is only a minimal full backup with 1 week retention. We intend to do weekly fulls and daily differentials.
I think the problem is that we have customers that make lofty requests like, "We want a 500GB data disk." And then they throw a 10GB database on it that grows a gig a year. So why make that customer buy 1.25TB of backup space, right? My point would be, why give them a 500GB data disk. How about a 30GB data disk and 2.5 times that for their backup disk, and grow as needed. It saves on cost, and they will always have space for minimal backup requirements.
I was curious what some of you thought about disk sizing for backups. I know it can vary drastically based on retention.
-
You are right that you'll want to keep the old backup until the new one is finished. So to that end, you'll just size based off of that. 2.5x is prob a good number because you'll want a little grow room and you do need to house that extra data. Though, if they're doing logs and diffs like you said, you'll need more than 2.5x right...
So it sounds to me like you're on the right track.
Watch my free SQL Server Tutorials at:
http://MidnightDBA.com
Blog Author of:
DBA Rant – http://www.MidnightDBA.com/DBARantMinion Maintenance is FREE:
-
Even more space would be better. There are always situations that come up during upgrades, year end processing, big data fixes etc that will require extra backups to be taken at certain points in time until the project is over.
You could buy a 3rd party product to compress your backups to save space. Our 250 G database backs up to 45 G, in less time.
I have a 300 G backup drive that allows me to fit 6 compressed backups on it.
-
>Which I think is the safest way to go... you should have a validated backup before you remove the old one.
If you have more than one large database it is also a question about when you're removing the old backup files.
Consider a sql server with 5 databases with a size of 100 GB each that you're doing a full backup of.
You could do a backup of all databases and then on success delete the old backup files. (If you have a Maintenance Plan with a Back Up Database Task and a Maintenance Cleanup Task then it works like this.)
You could also do a backup of the first database and then on success delete its old backup files. Then you could continue to the second database and so on. (My backup stored procedure DatabaseBackup works like this. http://ola.hallengren.com/sql-server-backup.html)
As you can see this has a large impact on the amount of space that you need.
Ola Hallengren
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply