Replica to DR converts thin disk to full size

[itdirector]

We went through the following steps to begin replication from our primary sites to our DR site:
- Copied the local primary site VBR backup to external drive & took it to our DR site
- Used our DR site VBR to import in the VBR backup from external drive. Then restored all of the VMs to our DR site using same as original disk (thin). All imported in fine using thin disk.
- On our primary site VBR, we created a replication job from primary to DR, using seeding via replica mapping; the job was set to 3 restore points
- After this replica job ran 4 times, & retention started to apply, the DR thin disks were converted to full size by VBR & vSphere.
- Example: on the primary site, VM1 has one thin 34GB vmdk, with a provisioned size of 104GB. On the DR site, after the restore from external drive, the same exact structure was setup (34GB vmdk, provisioned size of 104GB). After a few replication jobs from primary to DR, primary site stayed at 34GB vmdk, & 104GB provisioned; the DR site changed to 104GB vmdk & 104GB provisioned.
- This happened to all 20 VMs we initially started replicating.

Obviously, this is a big issue for us as we are replicating 70+ VMs from 5 sites to one DR site & we will run out of datastore space. Is the above normal behavior & is there another method we should use?
- Local Primary site to Primary site replication (no seeding nor replica mapping) does not cause the above issue.

VBR 6.1.0.204 at primary & DR sites
vSphere 5 at primary & DR sites

Thank you.

[Vitaliy S.]

Hello friedman,

I have just mapped one of my production VMs to its replica and my target VM disks didn't change their type, they stayed thin provisioned. The only reason why VM disks might be reported as thick, even though they are still thin, is snapshot creation on vSphere v4 hosts , which is not the case in your situation.

Could you please open a support ticket and let our technical team take a look at your job log files?

Thank you!

[tsightler]

Any chance that the remote site is still VMFS3 volumes that were upgraded to VMFS5? I think I've seen such volumes report thick when snapshots are on the volume just like vSphere 4, although the underlying disks were still actually thin. I know I've seen this in one other client environment and it was something like that.

[itdirector]

Thank you for the replies. I think there is a confusion about my post. The disks aren't changing from Thin to thick. They remain thin & are simply inflated to the provisioned size.
All of our servers are vSphere 5, with VMFS5 installed from scratch. They were never upgraded from any other version.

[tsightler]

I have never seen this behavior, or anything like it. As suggested I would open a support case and provide full logs for investigation.

[itdirector]

Quick question: with replica mapping, should the first veeam snapshot on the target be the same size as the restored vmdk after the first replication; or should the 1st target snapshot vmdk be only the changes (much smaller than the restored vmdk)?

[tsightler]

With replica mapping the first snapshot should be only the changes and thus much smaller than the restored VMDK. The initial replication after seeding will show how much data was read/transferred which can be used to estimate the size of the snapshot VMDK.

[itdirector]

Thx for the info tsightler. Maybe I am just setting up the seeding incorrectly then, because the 1st snapshot vmdk is the same size as the original vmdk (large) - on the 3rd replication when retention kicks in, snapshot1 gets deleted as normal & the original vmdk balloons to the provioned max.

On our DR VBR, I restored the individual VM's, then on the main site VBR I setup replication to "replica mapping" on the seeding page; howerver, i am not checking on "get seed from the following backup repository", because obviously, that repository doesn't exist on our main site VBR. Shouldn't that work? or do I have to go through the process of adding the DR repository to the main VBR, then do replica mapping & "get seed from the following backup repository"?

Thx

[tsightler]

The process you are using should work, as long as you are selecting the correct VMs to map each replica to. I have to assume that you are doing something wrong with this step. Are all of your hosts connected to vCenter?

Since you're having problems with this method you might want to try letting Veeam perform the seeding itself. Basically, instead of manually restoring the VMs, you add the remote repository to the "main" VBR server and select that as the source of the seed. With this option it will automatically restore the VM and then perform the first replication pass.

[itdirector]

This just happened again on a different Veeam install in another one of our offices, with a completely different scenario. We were forced to reset CBT using KB1113. On the first replication job (this one being local replication, not DR), the first snapshot's VMDK is the full provisioned size for all replicated VM's!
Example: a 100GB provisioned vmdk is utilizing the full 100GB size, instead just using 14GB of the 100GB size that data is filled with. The source is only utilizing 14GB. This is definitely a bug within Veeam 6.1.0.204. I will open up a case. I am really surprised no one else has ran into this issue (or maybe the majority don't using thin provisioned disks?)
Again, this is on two different installs of Veeam with two different scenarios, with two different installs of vSphere. I can replicate this issue with a brand new replication job, just one VM, reset CBT, then re-run replication; fills to the entire provisioned size for the first veeam snapshot on the target.

Veeam 6.1.0.204
vSphere esxi 5.0.0, 702118
DAS
Both installed from scratch, including the datastores

[Vitaliy S.]

Please post your support ticket number so I could update this topic with the resolution for the future readers. Thanks!

[itdirector]

Thx.

Support ID#5217555 - It is being escalated to Tier 2.

[tsightler]

I'm currently attempting to reproduce this in my lab as I believe I may have a couple of other clients seeing this issue, or something very similar.

[tsightler]

Again, this is on two different installs of Veeam with two different scenarios, with two different installs of vSphere. I can replicate this issue with a brand new replication job, just one VM, reset CBT, then re-run replication; fills to the entire provisioned size for the first veeam snapshot on the target.

Veeam 6.1.0.204
vSphere esxi 5.0.0, 702118
DAS
Both installed from scratch, including the datastores

I am unable to reproduce this. I'm curious, what transfer modes are your proxies using? Hotadd, Network, etc.? Thanks.

[itdirector]

In one scenario:
Source Proxy: Hotadd
Target Proxy: network

In another scenario:
Source Proxy: Hotadd
Target Proxy: Hotadd

Thx

[tsightler]

I have been able to reproduce the issue you are seeing with the CBT reset so hopefully support can easily reproduce this issue as well. I'm not sure if the two issues you are seeing are related, but I'm continuing to test.

[itdirector]

Thx tsightler. Yes, Veeam support was able to reproduce the same issue at their lab & have passed it up to Tier 3.