Solved

Math behind the sizer

  • 26 October 2023
  • 3 comments
  • 88 views

Userlevel 4

Hi everyone, greetings…

I am not sure the math behind for this settings

 

I seen the default is Forwards Incrementals with Weekly Fulls

So mean Mon-Sat incremental x6, Sun full x1

Daily 30 which keeps 26 incremental, 4 full

Monthly 3 which keeps 3 full

Yearly 3 which keeps 3 full

 

For full I think it’s related to ReFS, but not sure how it become 9.92TB

For incremental backup I calculated as 30TB *5% *30days *50% = 22.5TB (somewhat different)

Weekly 0 because GFS set 0

Monthly 3 copies = (30 + 30.25 + 30.5) * 50% reduction = 45.375 TB if w/o ReFS (but I tested it is 39.24TB if w/o ReFS in sizer)

 - I tried it by index 30+30.24+30.48 *50% = 45.36TB also different

 

Btw, what are the ReFS ~50% compression comes from? any docs for that?

 

And lastly for yearly (30+33+36.3)*50% reduction = 49.65TB w/o ReFS (very close to calculator this time but not exactly)

 

And why the ReFS does not significant in yearly ?

Turning on /off does not affect the yearly sizing much

 

If ReFS turned off

 

icon

Best answer by MicoolPaul 26 October 2023, 08:43

View original

3 comments

Userlevel 7
Badge +20

Hi, the key thing to know with ReFS/XFS is that at a file system level Veeam will leverage block cloning. This means that if you do a weekly synthetic full backup, rather than creating a complete copy of every block that hasn’t changed, for the sake of another full, Veeam will instead “reference” an existing copy of the block within the file system.

In effect this makes your full consume the space of another incremental backup only, because Veeam needs to only write the changes between the last backup and present, any other blocks that haven’t changed are referenced. This means when Veeam deletes an old backup, because the file system handles the referencing, any blocks that are needed by multiple backups are retained, and those no longer needed are purged.

 

ReFS doesn’t have much sway in your yearly backups because of this. Initially it will, because GFS backups simply mark your synthetic/active fulls with “flags” to say they are needed outside of the normal retention period, with a weekly, monthly, and yearly flag potentially set. These flags are assessed and removed as necessary during the retention processing. The reason I mention this is that, say you want a yearly backup retained in October (the current month at time of writing). Your normal backup retention period spans this date range, so you’ll just have your normal retention period but one of your backups will have a “Y” flag against it to say keep it for a year.

At that point in time, no extra space is needed. But your backup job will keep running through the year, and your data changes constantly throughout the year. By next September, there will be a low probability that any blocks haven’t been changed in the past year, so you’d need to track them independently by that point.

 

The calculator is giving you that worst case that each yearly will be basically another full. Then you’ve got your 3 years of growth placed in the calculator, and that has been estimated at 10 percent, so each year’s full backup is sized as (Last Year’s Full Backup Size + 10%) and adds up to how many years you’ve defined.

 

Appreciate this is a wordy answer and there might be questions you’ve got about this, but does this help make any sense of the calculator for you?

Userlevel 7
Badge +22

From what I remember a few years ago you had to really watch these. So for example if you were doing Monthly GFS, the first few Months you would not see much change but depending on what was happening on the file system it could suddenly jump. If for example one Month you did a big cleanup or had some big changes which affected a lot of blocks, then next time the GFS would be created it would no longer be able to reference previous blocks that had changed so these would be new writes effectively to that Monthly GFS file resulting in a large “real” increase in disk usage.

Userlevel 7
Badge +6

Great explanation, @MicoolPaul 

Comment