Hello,
I am looking for a possible solution to calculate the space savings with ReFS block cloning per job in a Repository.
I have scripted a solution with a external tool - blockstat.exe. But this takes a huge amount of time even for a medium sized repository with around 30 jobs.
Does Veeam save some statistics about this in the Veeam database?
If yes, how do I get these values?
I'm afraid there isn't a way to obtain this info with our powershell module as it is not being written anywhere in Veeam DB.
So, it is rather a matter of core level implementation. Looks like blockstat is currently the only tool, which might be helpful in your case.
But, as per this thread, we have this feature request noted.
@karsten123, as I checked, we have this feature request for a while now. Currently, it is under consideration, so cannot provide any precise info on when it will be implemented. Thanks!
Feature request: the objects returned by GetAllChildrenStorages() should contain a field which tells the real size on disk for each backup file. It would be logical to place it under Stats along with BackupSize and DataSize. For non-synthetic backups the size would be the same as BackupSize. But for synthetic backups, the field would show the size when counting only actual written blocks, not blocks referencing a previous block in xfs/ReFS block cloning. VBR would accumulate this number while writing the file, either in a normal backup session or when moving the file. Since VBR is aware of block cloning and uses it, it must already have the information. The request is for saving this information instead of discarding it. This would cost next to nothing in time and resources, but be very valuable for billing and reporting purposes. Similar requests have been made before (to no avail), but maybe not in a Powershell context.
I've moved your post to an existing topic on a similar subject about reporting on ReFS. Please see Oleg's answers and the linked threads, this is something that has been requested, but a few points:
1. VBR isn't actually aware of the space savings -- it passes the write to ReFS and it happens transparently for applications writing to ReFS
2. Windows doesn't make it super easy to poll this information, I've not found reliable methods for doing it that don't involve hot-loading a questionable DLL
So the request is noted, but just to prepare you, it's regrettably not as easy as just save some value right now.
David Domask | Product Management: Principal Analyst
All right, too bad. I suppose it's the same with xfs? But in any case, it shouldn't be impossible for VBR to calculate this. It does know that a synthetic is being built and what incrementals are involved. I think it would be worth taking a new look at this for all of us who have to create billing reports. Here we make do with counting only the oldest vbk in a chain and replacing the size of the other (supposedly synthetic) vbk's with the average size of an incremental for that chain. It comes reasonably close to truth.
