Understanding Backup Job Metadata

[BackupBytesTim]

Case #06041477

So, I'm back, again. Just looking to clarify something, nothing wrong with the support I've received lately, but I'm looking for a more technical explanation of what data is transferred from the repository to an agent in order for the agent to know what data on the computer needs to be backed up. Per my support case the main issue I'm having seems to be caused by a heavily fragmented backup file, which I can accept as a decent explanation for the incremental VIB files taking significantly more space on the server than the corresponding data did on the source computer. However I don't understand how that causes the file metadata in transit to take up more space. Since it's a file backup on macOS, it just records and sends file modified dates, doesn't it? Is there more to it than that?

I just can't come up with a technical explanation for how modified dates for any number of files would take up more or less space depending on the level of fragmentation on the hard drive. The timestamps for dates are still the same number of bytes aren't they? Since it's modified dates for files on the client side, not modified dates for blocks of parts of files on the repository side.

Again, not saying the support rep is wrong or anything, especially if this is now a known issue that may be resolved in an undetermined future update, just looking for a more technical explanation for my own curiosity. And my boss if I ever need to explain this to any level beyond "Veeam says...". Which I will need to explain, because the solution of regular active full backups will put extra load on our servers that wasn't supposed to be needed due to Veeam's "forever forward incremental" backup format, which was one of the reasons for using Veeam.

[HannesK]

Hello,
just by chance, I have a similar issue with the MAC agent that is connected to your case.

There are still investigations ongoing. I'm not sure, how an explanation which part of the code caused which side-effect would help your boss. In the end, it's a bug on our side that we plan to fix. Doing active-full backups is a workaround, but not a permanent solution (for the space-usage reasons you mentioned.

Best regards,
Hannes

[BackupBytesTim]

Fair enough, mostly it's because I'm curious how the software works. And like most company management I imagine, whether it actually helps anything to know or not, a sufficiently detailed technical explanation is usually enough to "explain away" a problem such that it no longer needs attention from our staff, at least until the software vendor, Veeam in this case, releases an update.

For now we're good with "Veeam is working on it", but I figure it doesn't hurt to ask if there's a more detailed explanation available.