I’d like to join your conversation.
Is it possible to have a disproportion between ‘Size of App’ and ‘Size of Backup’ like this?
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Possible? Sure, though I’d want tom know more about the job. That’s not a slight discrepancy, either. That’s a MASSIVE difference.
What kind of job is this? Are you viewing, say, one database out of many within a job or is that the whole thing?
Did it stop and start several times? That’s a common cause in the rare case we see this, though that would be a bit unlikely to be the buildup here.
How many files are in the job? It’s not unheard of for the Index to be bigger than the data, though again….VERY rare.
Definitely need to dig some more, though I think we can solve this!
@Mike Struening ,
Sorry for my late reply. I’ve been quiet busy recently.
The job I mentioned before is not availavle any more.
I found a similar two jobs.
Both are Selective Aux Copy jobs (Hyper-V, Copy to tape, Full backups).
Here’s the second one’s details
Does the Aux Copy dedupe or is this hydrated?
@Mike Struening ,
The Aux Copy is hydrated. As I can see the source copy uses deduplication, but then data is copied to tape with no deduplication.
This is likely the reason.
Can you check the sizes for app, data written, etc./ for the sasme job on Primary (deduped) and compare it to the hydrated size?
I admit, I didn’t realize the initial screenshot was an aux copy, not the backup history so that’s on me
@Mike Struening ,
Thanks for your reply and sorry for a delay - there was a bank holiday in Poland yesterday.
I’ll take a look on this and let you know ASAP.
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
I hope, you are not confused. :)
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.).
Sure, no problem at all. :)
Once I open a ticket with support team, I’ll let you know.
Here you go
Late to the conversation but just want to highlight this documentation page which explains each size discriptor:
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!