Feature Request: VBR SureBackup support for vTPM's

[STGdb]

It would be very helpful if VEEAM could implement support for VBR SureBackup jobs to make use of the new native VMware KMS feature. Our VMware VM’s have virtual TPM modules (vTPM) on them and for our Windows VM’s, they have BitLocker enabled (security is important). This combination basically renders VEEAM SureBackup (automation) useless. The only way a SureBackup job works for a VM with a vTPM is to manually enter the BitLocker key in the console when the SureBackup job starts up. And doing this still produces a mount error in the VBR SureBackup job startup. We’ve never been able to figure out a way to automatically unlock a BitLocker-enabled VM in a SureBackup job. We use SureBackups for verification and sandboxing and doing this manually is a real PIA.


Thank you

[Egor Yakovlev]

An interesting case, noted for investigation.
I have a feeling that vPowerNFS-mounted backup datastore will not fit existing encryption policies...will see.

/Thanks!

[evilaliv3]

Very good points.

What is not clear from VMWARE documentation is where the main keys of the VTPM leave (i think in the VCSA) and how those are protected.
If i understand it correctly and the keys are in plaintext, they would be stored by VEAM in plaintext in the backups along with the copy of the encrypted VMs and that would completely vanish any encryption effort.

What am i missing?

[STGdb]

With BitLocker-enabled VM's, SureBackups and guest file restores from Windows Servers don't work for us. We end up with errors in the VEEAM GUI like:

SERVERNAME - Registering
SERVERNAME - Configuring DC
Warning Failed to mount volume C:\Windows\TEMP\e55isjzm.vhh Details: Failed to call RPC function 'FcCheckFilesystemIsAccessible': The volume does not contain a recognized file system. Please make sure that all required file system drivers are loaded and that the volume is not corrupted.
SERVERNAME - Powering on

If we don't enter the BitLocker key manually for the VM, the SureBackup job fails. We have to also use SureBackup for guest file restores b/c the ability to restore guest files fails due to BitLocker. To get SureBackup and guest file restores to work, after we start the VEEAM SureBackup job, we have to be fast enough to switch to the VMware GUI for the vSphere host that has the SureBackup job and after the VM is registered with VMware and powered on, we can open a console from the VMware GUI itself and manually enter the BitLocker key using VMRC, then the VM will continue to boot and VEEAM SureBackup will continue processing (but still has the error shown above). If we aren't fast enough to enter the BitLocker key, the SureBackup job fails and we have to start over.

For guest file restores, we do the same thing as above but once the SureBackup VM's are up and running (i.e., Domain Controller and NTFS file server), then we have to RDP into the file server from the VBR system, manually copy the files out of the SureBackup VM to the VBR server via RDP and restore them back to the requested location.

Definitely a pain but at least a work around

[HannesK]

Hello,
I know, the topic is old, but I would like to clarify a few things

1) SureBackup works fine with vTPMs
2) SureBackup can also be used with vTPMs if virtualization based security (VBS) is enabled. That requires a registry key, because VBS is nested virtualization (Hyper-V running inside VMware). The registry key is marked internally, so I don't post it here. It can be obtained via support (refer to case #05536199 should speed up things). The error message is something like this

Code: Select all

Error: An error occurred while taking a snapshot: Invalid change tracker error code. (An error occurred while taking a snapshot: Invalid change tracker error code.)

3) The scenario of this thread is in-guest encryption that relies on a virtual TPM (bitlocker). And the workaround you mention is how it is supposed to work. If we would be able to automatically fix the problem, then security would be broken.

If one wants to use in-guest encryption (actually double encryption, because VMware also encrypts the VM as requirement for the the vTPM), then the consequences for VM-based backup are that things like file-level restore don't work anymore. That's "per design". An alternative solution can be agent-based backup, which is getting the unencrypted data.

Best regards,
Hannes