Massive increment file is not reflected in diff

[GenghisChen]

Hello, I'm not sure whether this is an actual bug, but will appreciate any input.

I'm using daily File Backup on my home Windows workstation along with a Windows based VBR repository, and am pretty happy with it. Daily increment files hover around 100MB each. A couple of days ago, a 301GB increment file was created (see image below)

When opening the large file along with the previous increment file using the Restore Point Utility, it shows no significant difference, despite the ~300GB difference in size (see image below).

What am I missing?

Please advise, thanks in advance

[ronnm-veeam]

Interesting. For some reason it appears to have only processed the system reserved partition (Volume0) and not the full OS (though it should have). Can you try browsing the mounted filesystem and explicitly select "Volume1" to run the comparison i.e.

[GenghisChen]

Thanks for your response, I'm running a daily File Backup from two volumes, and so (as far as I understand) Volume0 is my C: and Volume1 is my D:. Still, I compared Volume1 explicitly as you suggested and got the following:

[ronnm-veeam]

Ah ok well if your Volume0 is your OS then never mind. Something definitely changed at the block level to trigger our CBT since apparently the files remained relatively unchanged. Could possibly have been the result of a defrag, XDR agent (refer - https://forums.veeam.com/veeam-agent-for-windows-f33/veeam-agent-backup-large-incremental-backup-size-t90431.html), etc. that triggered block level changes not reflected at the file level?

[GenghisChen]

Sorry for the late response, but if I understand correctly - you say that File Level Backup relies on CBT, just like Volume Level Backup, and so if none of the files changed, but the underlying blocks did, Veeam will back these files up again. I don't have any XDR agent that I know of, but Windows may have defraged the drives (two-way mirrored Storage Space), I couldn't find deviance for the defraging, but that may just be my loose understanding of Windows Event Viewer. If that's the case, and blocks changed, can I assume there's nothing I can do to protect the backup from such occurrences?

[ronnm-veeam]

Honestly it's been a while since I looked into our current change tracking method for file-based agent backup. I thought we had implemented more granular file-level backup but from our current documentation it appears we still back up the entire file if its modified status has changed (see https://helpcenter.veeam.com/docs/agentforwindows/userguide/backup_cbt_default.html?ver=60#cbt-for-file-level-backup). The perplexing thing is that the restore point comparison utility also checks for any difference in the file modification date and should flag any file that has a different modification date between compared restore points. I'm wondering if there is some silent error I'm not catching properly. Was there anything else unusual about the comparison utility run i.e. it took an abnormally long or short amount of time to execute vs. comparing "normal" backup points?