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. HotAdd backup requires Cryptographer.AddDisk
also. Application quiesced snapshots are not
supported for encrypted VMs. Use file-system quiescing instead. The snapshot manifest
file will contain only a dummy
backup.xml
file.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.