Veeam Backup Capacity Calculator vs. RPS

[andrie]

Hello everyone,

the official Backup Capacity Calculator (https://calculator.veeam.com/vbr/) is missing quite a few features compared to the unoffical Restore Point Simulator (http://rps.dewin.me/).

There are a few options missing like scheduled active full or synthetic full backups or estimated size of individual restore points.
It was always useful to show to customers how a backup chain looked like with different settings.

One (or both?) of the calculators is wrong.If I use the same values on both calculators, the result is totally different.

For example, I did a calculation with the follwing values:

Source capacity: 12TB
Daily change rate: 5%
Yearly growth: 10%
Scope for growth: 5%
Reduction: 50%
REFS/XFS: off
Restore Points: 31 Daily


New Calculator:
Backup: 55.9TB
Full Backup: 39.41TB
Incremental backup: 10.18TB
Workspace: 6.31TB

Old Calculator:
Backup: 22758GB
Full Backup: 6546GB
Incremental backup: 9861GB
Workspace: 6.31TB

I'm not sure if I missed something but for now I'll stick to the old version.

[Mildur]

Hi Andy

Yes, it doesn't have the same features. But I'm not sure if the developer of the calculator will read this topic. It's not developed by R&D.

There are already other topics about this since last week:

topic78692.html
post440876.html

[andrie]

Hi Fabian,

I haven't seen the other topics but they all point in the same direction.
Maybe you could merge the topics?

[tdewin]

Hi,

It's being read so don't worry. Let me first say thank you guys because as the author of RPS I get a lot of positive feedback (even if it was me saying I'm deprecating the tool). Let me reassure that I don't plan to take it down tomorrow but a lot of people have asked me over the years to keep it up to date and it is just not possible. It's never been a full time job in fact it was more a hobby project for me.

RPS is quite extensive code because it simulates what VBR would do day by day. In fact if you give it 5 years retention, it will guesstimate when the worst case scenario would occur (in the next 6 years) and then runs through it day by day asking itself what VBR would do. This code is great because you can run manually scenario's and dig into the details. However it also makes the code quite difficult to add functionality (as a single developer).

So 1 year ago we went back to the basic question, why are people using RPS? I can say that 95% of people are using it to do a sizing. There are a lot of people unaware that there is such thing as a manual mode. In order to make a more extensive SIZING tool, I've created a new library called RPC. RPC doesn't do any simulation. It just has a clever algorithm that calculates in one pass what the result should be but doesn't have to do the day to simulation. RPS would be more accurate but in the cases I have seen while testing it, giving it the exact same parameters, the calculation should vary maybe 5%. The new calculator uses this RPC code and thus have an internal split on a per file (it just doesn't show it for now).

In order to make such an algorithm, choices had to be made:
Reverse Incremental is dying. I'm not saying this as a Veeam Employee or product manager. I'm not R&D so I don't know these kind of internal details. But I can tell you that Reverse Incremental is only being used in certain corner case at the customer that I personally know (or which I recommended). In terms of sizing, it also sizes exactly the same as Forever Incremental since the full is just at the other end of the chain.
Forever Incremental is almost the same as Forward incremental with ReFS/XFS since "fulls" are consuming the space of incrementals. I do understand that there are corner cases here but in general with the unified GFS retention, you need fulls enabled if you want to have GFS points. So you can simulate Forever Incremental as a Forward incremental with ReFS/XFS enabled in case you don't use GFS.

Doing these assumptions, removes a lot of complexity for most regular users who just want to make a sizing. If you are a Veeam power user, you might think reverse incremental is simple but newer customers do not always grasp always those idea's. This has ended up in a lot of discussions on how to use RPS in the first place.

Now notice that this official tool is a very first version. The goal is to see what is required and to add functionality to it. This is a case where you can't make an omelet without scrambling some eggs. At this point we have 3 calculators, RPS, RPC and VSE (and then some NAS calculators, VBO etc). The goal is to unify all of that in one official calculator. This will take some time. In the meanwhile, it would be great if you share these kind of thoughts and inconsistencies. But personally (although it is letting go of my own project), I believe it is better to have one tool, one website that has everything, then have multiple calculators flying around the internet.

[Mildur]

Thank you Timothy for your work and your statement. The calculator (RPS, RPC) was always a good tool for us.
I have already started to use the new calculator for our projects. It works good for forward incremental chain, which should be a new best practice with hardened repos and object store offloading capabilities.

I shared the link to this post in the veeam community, where people also are discussing the new official calculator.

[JaySt]

RPC was great. very understandable and visual tool. But untill i see understandable results with equal input parameters between RPC and the new calc, i will use the old one.

Either I dont understand the output of the new calculator just yet, or they are wrong.
With 10TB source, 0 yearly growth, 1 year scope, 7 daily, 4 weekly input -> i'm getting "full backup: 1TB" . What's that about?
So basically trying to replicate this : https://rps.dewin.me/rpc/?s=10240&r=7&g ... gr=1&m=3&e

[tdewin]

Hi,

The result is the same but I can indeed see why it is confusing. Due to GFS, the first full is a weekly backup. The "simple chain" only contains a synthetic full. So you should add Full Backup + Weekly + Monthly + Yearly to get the complete full vbk data set. I do see how this is more visible in RPC then in a table. 14.87 TB is the same total sum though

Code: Select all

Backup
14.87 TB
Full backup:
1.01 TB
Incremental backup:
2.78 TB
Weekly:
5.8 TB
Monthly:
0 GB
Yearly:
0 GB
Workspace:
5.28 TB

[JaySt]

yes the sum is the same indeed. Although the idea of the breakdown (weekly, monthly sums etc.) is a nice idea, i'm not that comfortable sharing it (with customers for example) as it would bounce back with (a lot of) questions and result in too much explaining.
i hope some things can be done to improve going forward.

[micoolpaul]

Provided the data is the same I personally would reformat the data myself if it was too verbose, I’d want to as part of any branding/standardisation anyway.

[HansA]

Thanks for this tool, and allowing the "Daily change rate (%)" to finally go below 3%. Can we request allowing 0 weeks in the backup copy policy? I will second wanting to see the breakout as in the RPS/RPC tools.

[tdewin]

Weekly will always be 1 min (its not visible for backup job policy but it is in effect). If you want to size as forever incremental, just enable ReFS/XFS even if you are not planning to use it. In this case the full will take only the place of increment. But I agree the GUI is inconsistent at this point so we need to update that.

As for the split down, please keep posting request in this thread so we can prioritize this with the devs. But this seems a common internal and external request.

[kkemper]

Thanks for the great tool RPS.
What I would like to see in the new RPC is the graphical display of the restore points.
This is simply more understandable for many customers.
And to explain the differences between Activ- and Synthetic-Fullbackup with and without ReFS/XFS, I haven't found anything better yet.
Especially because you can "play" with the real data sets of the customer.

[Sean S]

I also agree that having a graphical display of the restore points is very helpful.

[LeeGC]

Trying to run numbers with the new Veeam Calculator here: https://calculator.veeam.com/vbr/

We could use an option for Restore Points at the hourly mark. On the old tool it was called Interval (https://rps.dewin.me/).

[joachimeberhard]

I have a question.
"Source capacity" it means uncompressed?
And "Reduction" it means compress/dedupe ratio?

[veremin]

I'm not the utility owner, but to me it does sounds like:

- Total size of all VM disks processed by the job
- Size of data after applying compression and deduplication

Thanks!

[teknomage]

I have some questions and would like to offer some feedback to the team that maintains the calculator (calculator.veeam.com/vbr). Does anyone know how to get a hold of them?

Mike

[veremin]

Timothy Dewin is the man you need. Thanks!

[tdewin]

Hi,

What is the question?