@Mike StrueningI found this job on the Job History (on Subclient level).
However, ‘Size of Backup’ column is not present on the Job History view on the Storage Policy / Copy level or Subclient level.
It’s only visible on Media content view.
Depends on which Mount Path I choose the value of ‘Data Written’ and ‘Size of App’ are different but ‘Size of Backup’ is always the same, and it’s exactly the same as ‘Size of Backup’ on tape
The only thing I can think of is if these stats are referring to the overall VSA job size, and each Job ID within is per vm?
I’d advise opening a Support Case for this because I’m not 100% confident in my answer, and even if I am correct, the GUI should be clearer.
Can you share the case number so I can track it? Once you do, I’m going to split your reply (starting on Oct 25) into its own thread. Easier to track that way (and better for posterity, searches, etc.).
Backup Size - The amount of data backed up after eliminating white spaces.
For VMware only, data that was written and deleted still counts as reserved (allocated) space.
Size of Application - The sum of the backup sizes of each VM included in a Virtual Server Agent (VSA) backup job.
However the description should indicate that the size of app should match backup size, which clearly it does not here, which I think is strange - it could be a IndexingV2 difference since the description above seems to be about the entire job not just individual VMs.
In other agents size of application is backup data read before deduplication and compression and I would assume the same here - for tiny sizes it could mean there were no changed blocks and the negligible kilobytes are probably some form of indexing data or just an updated copy of the VMX and other equivalent VM config files (XML for Hyper-V?). VSA is a bit tricky since we are dealing with things like unallocated sectors and white space from a block level backup.
My guess in your example is that backup size is the entire VM size including unallocated blocks. App size is data excluding white space (allocated but empty blocks) - basically data read that was not discarded (white space, e.g a file that was written but then deleted).
I dont think viewing contents on the mounthpath is valid as jobs span mountpaths and that view wont give you a complete picture of the job, just a filtered view as to what was written to that MP.
But, lets let support confirm or dispute those assumptions :)
Based on another thread, I’m sharing this summary (furthering what @Damian Andre said):
I have more information!
What’s happening here is that we no longer discard deleted files during vm backups.
That’s the high level answer; the deeper answer is a bit more detailed:
When vms delete a file, they dirty the disk (i.e. it’s not blank, but there’s no file there).
When we check with CBT, we are told those blocks have changed (because they have) even though no file is there.
To cut down on space, we were looking at the changed list, then seeing what files were actually active, and discarding the ‘deleted’ files.
However, here’s the problem (and why things changed recently): some files can’t be replaced until reboot (drivers, etc.). These files are marked as deleted, and will also not show as active.
This means the backup will not collect these files, nor will they ever….the blocks are marked as skipped.
When you perform a full restore, these files that were never backed up will cause a full system restore to fail.
After conferring with MSFT, we stopped skipping the deleted files. Backups are bigger, but will always work during restores.
Let me know if you have any questions as that is a lot of information!
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.