Chapter 3 – Sizing

How much space do you need to provide for backup purposes?
Of course, my answer is again: it depends.

There are some questions to be answered before you can make an educated guess about this number. And sorry, it won’t be more than a guess.

Fist of all, we need the amount of data to protect, the so-called front end data. If you’re unsure about the actual usage of this data, you should invest some time to figure it out. At the end of this post, you’ll know, why.

The second question is,what type of backups you plan to run. Fulls every day? Or today’s standard, One full per week and incrementals every other day?

Finally, you have to define, how long you want to keep your backups.
Let me get a little afield here. Every now and then people tell me that they have to keep their backups for ten years, because of legal requirements. This is a common misconception. I most cases, there is a requirement to be able to present fiscal data of the last ten years.  But as I wrote in Backup vs. Archiving, we have to differentiate between backup and archiving. Keeping data for long-terms is the responsibility of an archive, not of the backup. And most if not all professional ERP systems have an integrated archiving system that keeps an unalterable record of all relevant transactions. This means that if you lose your ERP system by an accident, you’ll need to restore the most current backup in order to be able to access all datasets inside the system. Even those that are ten years old. So there’s no need to keep a ten-year-old backup of the ERP.

In most projects I’ve been working in, we found that the size of an incremental backup can be estimated with ca. 15% of the size o a full backup. Of course, this number differs, depending of the type of data and its change rate. But let’s assume, this number also fits your environment.
Let’s also assume that you’re going to do one full (on Friday) and six incremental backups (on all other days) per week.
Then the size of a full week’s backups would be 1×100%q + 6×15%q = 190%q = 1.9q, where “q” is the size of your front end data to protect. This means that the size for the backup needs to be nearly twice as big as the one for the “real” data itself.
Unfortunately, this is not the whole truth. Since any incremental backup relies on “it’s” full backup, you cannot delete the full backup without rendering all incremental backups worthless. The same is true for the incremental backups amongst themselves: You cannot delete any incremental backup without breaking the dependencies of all following incremental backups.

In other words: If we assume that you want to keep your backups for one week, one might think that the full backup of the second’s week Friday would overwrite the one from week 1. But since all incremental backups from week 1 are based on this fist full backup, it cannot be overwritten until all depending incremental backups are allowed to be deleted. And this is also true for the incrementals from week 1’s Saturday to Thursday: They have depending backup sets and can therefore not be deleted.

At the end of the day this means that, in order to keep your backups for one single week, you have to keep the backup sets on disk for at least two weeks.
If you want to keep the backups for two weeks, you’ll have to provide the space for three weeks and so on: