Job summary transferred bug?

[VladV]

I am preparing to migrate our environment to vsphere 5.5 and VBR R2 on Windows 2012 R2 so I decided to reinstall everything from scratch (VBR, vCenter). I now have a test vsphere 5.5 (esxi5.5, vcenter 5.5) and VBR R2 for testing purposes.

I migrated some unimportant VMs from 5.1 to 5.5 and created a backup job for them. Immediately I noticed that in the throughput graph everything was red and in the Data tab, Read=Transferred. The settings for the job are: Inline dedup active, compression optimal, local target.

Checking the report I can see that Transferred=Read but Backup size was about 60% of the transferred value. This made me think that there is a bug in reporting and that compression and dedup are working fine.

Can someone else confirm this behavior?

[foggy]

Vlad, do you probably have both source and target agents installed on the same machine?

[VladV]

Could you please elaborate a bit? On the backup server I have the WAN, proxy and repository roles installed like in the old server.

[foggy]

That's what I meant. You have both proxy and repository roles on the same server. In this case compression is performed by the target agent (repository), while data is transferred between agents uncompressed, hence, read=transferred equation. This is a known behavior that should be addressed later down the road to reflect correct numbers in the stats/reports.

[VladV]

OK, but on my old VBR server I have the same config on v7 patch 1 and this doesn't happen so just to confirm it I have upgraded this server too to R2 and it started to have the same behavior. Can you also confirm that this "issue" started with R2 and was not present in patch 1?

[tsightler]

I think it's simply a side effect of this change:

• Removed unintentional compression (and further uncompression) of data transferred between source and target data movers when both are running on the same server, and compression is disabled in the job settings.

Prior to R2 if a backup job had compression disabled (for example when writing to a dedupe target), the proxy agent would compress the data and the target agent would decompress the data, even if they were both running on the same machine, wasting some CPU resources. To resolve this in R2 it appears that if both the source and target agents are running on the same machine, the target agent always does the compression so the data "transferred" between the agents is not compressed, and that's what this number represents. I would have thought this would have only applied to jobs that have compression disabled, but it appears it applies to all of them, however, since both agents are running on the same system it's largely just a cosmetic issue as the transfer is happening internally to the system.

[kte]

I see this also in the backup summary the read and transfered is the same (no compression ) but on disk the file is alot smaller
K

[VladV]

Thanks for clarifying Tom. I wanted to be sure that it was not an environment specific issue. Now I understand what is in fact happening.

Regards

[foggy]

Tom is absolutely correct - this is a side effect of the described fix (so, yes, the issue is actually infused by the R2 release).

[Simon]

Hello

Since I upgraded to Version 764 my backup to disk job reports a higher volume of transferred data. In the log and mail of the job I currently have 156gb for my daily incremental job but the file size of the vib file is only 43gb. In the previous version these sizes were the same. The disk to tape job which copies the incremental to tape, reports the correct size of 43gb and this is in my opinion the correct size of the backup.

Why the disk job reports a higher transferred size in the 764 version?

Regards
Simon

[foggy]

Simon, seems that you're referring to the known behavior with R2 release, please review this topic above.

[Simon]

Thank you for your answer.

Simon