Comprehensive data protection for all workloads
Post Reply
VladV
Expert
Posts: 224
Liked: 25 times
Joined: Apr 30, 2013 7:38 am
Full Name: Vlad Valeriu Velciu
Contact:

Job summary transferred bug?

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Job summary transferred bug?

Post by foggy »

Vlad, do you probably have both source and target agents installed on the same machine?
VladV
Expert
Posts: 224
Liked: 25 times
Joined: Apr 30, 2013 7:38 am
Full Name: Vlad Valeriu Velciu
Contact:

Re: Job summary transferred bug?

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Job summary transferred bug?

Post by 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
Expert
Posts: 224
Liked: 25 times
Joined: Apr 30, 2013 7:38 am
Full Name: Vlad Valeriu Velciu
Contact:

Re: Job summary transferred bug?

Post by 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
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Job summary transferred bug?

Post by tsightler » 1 person likes this post

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
Expert
Posts: 179
Liked: 8 times
Joined: Jul 02, 2013 7:48 pm
Full Name: Koen Teugels
Contact:

Re: Job summary transferred bug?

Post by 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
Expert
Posts: 224
Liked: 25 times
Joined: Apr 30, 2013 7:38 am
Full Name: Vlad Valeriu Velciu
Contact:

Re: Job summary transferred bug?

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Job summary transferred bug?

Post by 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
Novice
Posts: 5
Liked: never
Joined: Jun 25, 2009 11:41 am
Contact:

[MERGED] Transferred data size in 7.0.0.764

Post by 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
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Job summary transferred bug?

Post by foggy »

Simon, seems that you're referring to the known behavior with R2 release, please review this topic above.
Simon
Novice
Posts: 5
Liked: never
Joined: Jun 25, 2009 11:41 am
Contact:

Re: Job summary transferred bug?

Post by Simon »

Thank you for your answer.

Simon
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Ivan239, Paul.Loewenkamp and 159 guests