If you run the simulation, you can actually see the dependency. I had countless discussions with customers arguing that Veeam did (does) not respect their rps policy, when in fact it does its absolute best to respect your policy. For example, if you configure a forward incremental with weekly full and 2 restore points (rps), you can expect up to 9 rps, because of dependencies. Even Veeam users do not always understand the effect of a certain policy. However when you talk about weekly synthetics or active fulls, the number is rather difficult to calculate. With reverse incremental / forever incremental, that is quite easy to calculate, you'll have F = 1 and R = rps - F. These values define how much full backups you will need or how many incrementals you need.

First of all the (C)ompression ratio and the (D)elta are difficult parameters to estimate but it does give you some hints what we at Veeam use inside and a fairly good explanation why these values are chosen. Reportedly for most VMs it is just 1-2%, but active Exchange and SQL canīe up to 10-20% due to transaction logs activity - so 5% seems to be = average amount of VM disk changes between cycles in percent (we useġ0% right now, but will change it to 5% in v5 based on feedback. R = number of rollbacks (or increments) according to retention policy (14 by default) = average compression/dedupe ratio (depends on too many factors,Ĭompression and dedupe can be very high, but we use 50% - worst case)į = number of full backups in retention policy (1, unless backup mode with periodic fulls is used) Many Veeam SEs had there own excel configuration sheet to quickly spit out some numbers, some more pretty than others.ĭata = sum of processed VMs size by the specific job (actually used, not provisioned)

I'll quote it here because it is still the main idea behind RPS. In the beginning there was nothing, just our famous formula to calculate repository spaces.

Restore point simulator veeam