REFS Size on Disk

[billcouper]

Hi,

I need to be able to find out how much actual disk space each backup copy job is using. Perhaps it's just us, but we don't charge people for space they aren't using, even if those savings are from trickery like dedup or refs. Billing reports in Veeam ONE don't support REFS block cloning and only show the reported size on disk, not the actual size. How did REFS even make it to release at all? Considering it's been totally broken until recently and Veeam can't even tell how much space a backup is using.

I now need to get these figures myself some how. I have been messing around with a utility called blockstats, http://dewin.me/refs/
The numbers I am getting out of it are out by up to 50%. This is probably due to a mis-understanding on my part about how the process works when creating synthetic fulls, and that is what I am posting about today.

I have 42 backups jobs creating per-VM chains onto 6 extents in a scale-out repo. The way I understand it is: Synthetic fulls will block-clone the files for a single VM, per extent.

So I am grabbing all files (VBK/VIB) for each single VM on a single extent, and running blockstats against those files (per-VM separately) to give an "Actual disk space used by X VM on Y extent". I grab the blockstats totals for every VM on an extent, sum them together and compare to Disk Management. The numbers for some extents are pretty close but others are out by up to 50%.

Does anybody know if I am just doing it wrong, or if there is a more accurate way to measure actual disk usage per job?

Related to case # 02641685

[tdewin]

Well I can tell you that blockstat was a long shot in trying to figure out the how blocks are shared. Inaccuracy is expected because it can not account for the meta data that is being generated. From most users the feedback is (including my own tests) of upto ~10% inaccuracy. So it was deemed good enough. I'm a bit surprised about the 50% gap.

The calculation for the savings is the following. Imagine you get the following result:
1*6620 shared
2*3152 shared
3*12054 shared

Basically if a block is shared 1 time, it is not shared, but unique to a file. If a block is 2x time shared, it is shared between 2 files. Your gain is not 2x, but rather 1x because the first file need to store the data, the second can just refer to it. With 3x shared, 2 files profit, one has to actually store it and so on..

(1-1)*6620=0
(2-1)*3152=3152
(3-1)*12054=24108
...
(t-1)*shared

So the total savings is :
0+3152+24108=27260

[billcouper]

Thanks tdewin

You confirmed I was doing it wrong.
If I can get all the numbers within 10% I will be happy enough for now.

Still pretty disappointing that Veeam can't work this stuff out for itself. REFS feels SO beta. Why is it in the release version? Anyway - you don't have to answer that. It's more a rhetorical question than anything else.
REFS is BY FAR the weakest link when it comes to Veeam. I don't think Veeam should push it so hard until it is correctly supported.

[Delo123]

What exactly are you complaining about? ReFS isn't a Veeam product... And it's fully supported, support has nothing to do with how much space your backups use...