Should seeding a bitlocker drive work?

[averylarry]

I created a blank new 1Tb virtual disk on my server (guest VM) and encrypted it with bitlocker. I then removed the drive from the VM and copied it to a USB hard drive (using vSphere client). I took that hard drive out to my replication site. I copied that virtual disk to the replication environment.

At this point, the new virtual disk had not been backed up as I was preparing and seeding.

Now I add the virtual disk to both the production and the replicated VM (after removing all snapshots on the replicated VM). I include the disk in the backup and the replication. The backup runs and takes quite a while (as expected -- no compression or deduplication on encrypted disks). The replication runs and calculates the digests.

At this point I expect little or no data that needs to be replicated on the new 1Tb virtual disk since I seeded an exact copy of the virtual disk. However, I got up to maybe 75Gb replicated with no end in sight, so I re-did most of the process with the same outcome.

My question is if I did something wrong, or if Veeam has a problem with replicating a virtual disk that is encrypted (in the guest VM) with bitlocker.

[PTide]

Hi Ted,

I'd like to get a little bit more of details please.

You said

"I then removed the drive from the VM and copied it to a USB hard drive..."

Did you copy the .vmdk file or performed a backup thereby creating a .vbk file?

[averylarry]

I use the vSphere client to browse the datastore where I download the 3 files that make up the virtual disk (the .vmdk, the -ctk.vmdk (which is pretty pointless), and the -flat.vmdk).

[foggy]

Ted, have you mapped the job to its replica prior to the first job run after attaching the disks?

[averylarry]

Yes -- I mapped the replica VM. It works properly -- discovering the VM and then (re-)calculating the digests on all the virtual disks. It only transfers a small amount of data for the other virtual disks (not encrypted with bitlocker), as expected.

I guess I must be doing something wrong. I think I'll troubleshoot by creating a much smaller virtual disk that I can copy across the WAN directly instead of transporting via USB hard drive.

[foggy]

Have you added the disk at the same SCSI slot on both VMs?

[averylarry]

Have you added the disk at the same SCSI slot on both VMs?

I wouldn't make that rookie mistake.

[PTide]

Ted,

I need to clarify something, if you don't mind.

This is how I understood what happened:

1. Creation of a full replica of your VM
2. Added a 1Tb drive to source VM and encrypted it with a Bitlocker.
3. Switched off the source VM, removed the drive, copied .vmdk to usb drive, placed the copy to another host.
4. Added copied hard drive on both source and replica VM
6. Powerd on the source.
8. Started synchronization.

As a result, replication process started to synchronize the whole 1Tb drive despite the fact that .vmdk had been copied.

Is that correct?

Thank you.

[averylarry]

1. Full backup/replication of VM.
2. Added 1Tb virtual disk and encrypted with Bitlocker.
3. Full backup of source VM.
4. Disconnected virtual disk from source VM.
5. Copied .vmdk to usb drive.
6. Copied .vmdk from usb drive to destination replica VM.
7. Added 1Tb virtual disk to source VM and destination replica VM. Made sure the scsi ID was the same for both and the same as when I encrypted the drive.
8. Ran a backup. The .vrb file is small, indicating that the 1Tb disk did not have significant changes.
9. Ran the replication (which uses the backup job as the source). It re-calculated all the metadata as expected and then it seemed like it was going to transfer the entire 1Tb instead of maybe a tiny amount of changed blocks.

[Vitaliy S.]

Is this job still running? What do the processed and transferred data counters show for this job?

[averylarry]

It's not running. But the read and transferred counters were almost identical. I think the processed counter was the same also. Which makes sense with encrypted data (no compression and I think no dedupe).

[Vitaliy S.]

Try not to attach/remove disk from the source VM, but rather do the backup locally and then do seeding as per our documentation. The only explanation I have for this behavior is that the ID of the disks or something similar has affected change block tracking engine, bitlocker should not be the issue here.