Encrypted VM Backup and Restore
Starting with vSphere 6.5, customers can take advantage of virtual machine encryption. This section describes how to design backup and restore to handle VM encryption.
Encryption protects sensitive parts of a VM and some or all of its virtual disks. The vCenter Server retrieves keys from a key management server and pushes them to ESXi hosts, which use the keys to encrypt virtual disk data, NVRAM, portions of the VMX file, and so forth. See the vSphere Security manual for details.
To back up encrypted virtual disks, VDDK obtains the encryption keys and decrypts virtual disk data before copying to backup media, so virtual disk data on backup media are in the clear (not encrypted). VMware recommends that backup agents use their own encryption to protect data on backup media.
Backup of encrypted disks is supported with NBDSSL and HotAdd transport modes, but not supported with SAN transport. To back up encrypted virtual disks using HotAdd, the backup proxy VM must have been encrypted as well. Both NBDSSL backup and HotAdd backup require Cryptographer.Access permission, and HotAdd backup mode requires Cryptographer.AddDisk also.
Encrypted Virtual Disks
When customers restore virtual disks that were encrypted at backup time, they likely want them to remain encrypted after restore. If a disk was encrypted when it was backed up, the backup agent can remember the storage policy and apply it to the restored disk. If that storage policy no longer exists in the system, the backup agent could ask the administrator what policy to apply for encrypted disks, or use the sample VM encryption storage policy. Optionally the backup agent can remember a disk’s key ID and provide it at restore time, which will result in the restored disk using the same key as the original disk. If not specified, vCenter Server gets a new key from the key server.
Recommendations for VM Home
When a VM is encrypted, its
VMX configuration file contains portions that are encrypted, and the entire
NVRAM file is encrypted. To completely recover a VM from backups, the NVRAM
file must be restored, and two additional properties from the VirtualMachine
object's configuration must be restored: (1) the encryption key identifier,
found in the VirtualMachine
ConfigInfo.keyId
property, and (2) an encrypted blob
containing VM secrets, called the
encryption.bundle
, found in the VirtualMachine
ConfigInfo.extraConfig
list.
VMware recommends against
directly copying the entire VMX configuration file, but instead using the
PropertyCollector to keep a record of configuration structures as documented
earlier in this chapter. When a VM is saved, the backup agent should include
the
ConfigInfo.keyId
, the
encryption.bundle
from
ConfigInfo.extraConfig
, and the current storage
policy.
Later when the backup is
restored, these values should be provided in the new VirtualMachine
ConfigSpec
. This will ensure that the recovered VM
metadata files are protected with the same key as the original VM. If a VM is
restored to a vCenter Server with key server access, the VM will boot. However
if the vCenter Server lacks key server access, the VM will not power on after
restore, because vCenter Server cannot push encryption keys to its ESXi host.
The NVRAM file can be handled
as it was in previous releases, using HTTP download and upload, but without
saving the additional ConfigInfo properties described above, the NVRAM will be
unusable. This is because it is encrypted with the key that is found in the
encryption.bundle
, which is in turn sealed with the
key identified by
ConfigInfo.keyId
. The recovered VM must be created in
a vCenter Server that has access to the same key server as the original, or a
replicated key server instance with the same cluster name.
What If Something Fails
If the
ConfigInfo.keyId
and
encryption.bundle
were not saved, it will be
impossible to encrypt the recovered VM using its original encryption keys.
However the VM may be encrypted with new keys from the key server. If the NVRAM
file was saved, it is unusable without the original
ConfigInfo.keyId
and
encryption.bundle
information. If the NVRAM file was
not saved, or unusable, a generic one can be used instead. After NVRAM is lost
and regenerated, UEFI enabled VMs may require Secure Boot to be reconfigured,
or the boot disk to be reconfigured.
If the vCenter Server has lost
access to the original keys from the key server, then a restore operation may
remove the
encryption.bundle
from
ConfigInfo.extraConfig
and specify only a VM
encryption storage policy for the VM and its disks. Again this will cause any
data present in the NVRAM to be unusable.