Replication of Thin VM results in a Thick VM replica?

[CraigConstable]

Well I must say I haven't had the best results using Veeam Backup and FastSCP 4.1.1
Running 2 x ESXi 4.0.0 build 208167 servers (Paid Version)

I have tried to simply create a copy of a VM (Thin Provisioned) on the same server. Now i would expect this to run pretty quickly as it is just a local copy however it was running at 3MB/s (VM was 50GB provisioned with 20GB used) took about 3 Hours. Very disappointing. (not only did it take ages the copy was also thick!)
I did a bit of research and found that ESXi has a command line and found a tool called vmkfstools I cloned the VM in this way and it took 7min!
My question is what the heck is Veeam doing in this scenario?
(It's not going over the network, I pulled the network cable out to make sure and it continued)

I then started a replica job in Veeam for the same VM. This was from one server to the other over a 1Gbps network.
I was much happier with the time. It took 19mins to complete which suggests that it did indeed only copy the 20GB of used data. However I looked at the replica VM on the other server and surprise surprise it was 50GB (Thick).

Why does Veeam do this?
I have yet to be able to replicate a thin provisioned VM to a thin provisioned replica.

Also how do I see how much data has been transferred after a replication?
I mean it's all well and good to see it processes at 800MB/s but I need to know how much data was transferred.

Surely these are all basic things, why does this program not function the way one would expect?

[Vitaliy S.]

Hello Craig,

Welcome to Veeam Community forums and thank you for your feedback! Currently all thin disks are replicated as thick, this is a known limitation mentioned in the Release Notes document, but this is resolved in our upcoming release of 5.0

I believe that is the reason why you saw such a big time difference while performing your experiments.

You may have a look at how much data was transferred during the latest incremental replication cycle by browsing to your target datastore and checking the size of the VRB files.

Thank you!

[CraigConstable]

Thank you for your reply.

If I convert (using vmkfstools) the replica VM to thin will the replication still work and will it stay thin?

Does my license for 4.1.1 allow me to upgrade to 5.0 when it is out?

I have replication running every 30min, I would like to know how much data is transferred with each one surely this is recorded?
Are the VRB files created for every replication cycle?
Is there maybe a script I can also run that will give me this info?

[Gostev]

If I convert (using vmkfstools) the replica VM to thin will the replication still work and will it stay thin?

No, you cannot be modifying replica disk files.

Does my license for 4.1.1 allow me to upgrade to 5.0 when it is out?

Yes, if your maintenance agreement is still active at the time of 5.0 release.

I have replication running every 30min, I would like to know how much data is transferred with each one surely this is recorded?

This is not currently recorded, but can be estimated from VRB file sizes. VRB file size contains all data blocks substituted in the replica VMDKs during the corresponding incremental run.

Are the VRB files created for every replication cycle?

Yes

Is there maybe a script I can also run that will give me this info?

No, such information is not currently stored in the sessions' history.