Hot snapshots reside on CloudCache for a period that you specified at the time of configuring CloudCache.

If you are a group administrator, you can only restore data to a virtual machine that belongs to an administrative group that you manage. Cloud administrators and data protection officers can restore virtual machines across groups.

In the event of a network connection failure at the time of restores, backup proxies attempt to connect to Druva Cloud. After the restoration of connectivity, backup proxies restart restores from the state in which they were interrupted.

If you restart or reboot backup proxy during a restore, the restore operation changes to scheduled state and resumes after the virtual machine is up and running.

When creating a virtual machine, you can add a Virtual Trusted Platform Module ( vTPM ) to provide enhanced security to the guest operating system. You must create a key provider before you can add a vTPM. You can back up these vTPM-enabled VMs. However, v-TPM settings will not be copied in the recovery points during backup. Therefore, whenever you are doing a restore of these VMs, you will have to manually add the vTPM settings later.

Although Druva backs up VMX files along with the VMDK files, you can restore the VMDK files only.

The Restore Points follow the backup proxy pool time zone.

If you choose to restore a virtual disk, Druva creates a new virtual machine with minimum configuration and associates the VMDK files that you selected to it.

Druva supports restore of virtual machines to a different ESXi hypervisor, as well as the source hypervisor associated with a vCenter Server on which you installed the backup proxy.

A Thick Provisioned Lazy Zeroed disk is restored as a Thick Provisioned Lazy Zeroed disk.

A Thick Provisioned Eager Zeroed disk is restored as a Thick Provisioned Eager Zeroed disk.

Thin provisioned VMDK files are restored as Thin disks.

CBT status remains unchanged if a virtual machine is restored to the original location. If a virtual machine is restored to an alternate location, CBT is disabled.

Druva supports restore of RDM virtual mode disks (vRDM) as VMDK files.

If a virtual machine is associated with disks that are configured in different modes, for example, Independent Persistent, Druva restores only those disks for which the mode is supported.

In case of virtual machine restore to the original location, Druva restores the virtual machine to its original network configuration. However, for a virtual disk restore or restore to an alternate location, Druva restores the virtual to the default network configuration of the ESXi where it is restored.

If a restore fails, the newly created virtual machine is deleted.

After a restore, the virtual machine is always powered off. You must manually power on the virtual machine.

During an ongoing restore and scheduled backup, if the client machine is restarted then jobs request may not be resent to the client machine.

In case of virtual machine restore to the original location, as a backup and restore cannot run in parallel on the same virtual machine, you can cancel the ongoing backup and trigger the restore request.

In case of virtual machine restore to the original location, two restore requests cannot run in parallel on the same virtual machine.

In case of virtual machine restore to the original location, if a backup is triggered while a restore is in progress, the backup will be queued until the restore is complete.

In case of virtual machine restore to the alternate location, if a backup is triggered while a restore is in progress, and if backup goes to same backup proxy where restore is running, the backup will be queued until the restore is complete.

VMware introduced support for NVMe controllers and NVMe disks from vCenter version 6.5 and hardware version 13. With version 6.0.3-178504 of the VMware Backup proxy you can backup and restore virtual machines with NVMe disks or controllers using the HotAdd transport mode. The backup of virtual machines with NVMe disks or controllers falls back to the NBDSSL mode if the VMware Backup proxy does not have an NVMe controller.
The following table explains the steps you need to perform if you want to protect virtual machines with NVMe disks or controllers.

Phoenix.cfg file (for VMware backup proxy version prior to 7.0.0), you need to stop the Phoenix service, add the parameter and then restart the Phoenix service again.

VMwareConfig.yaml file (for VMware backup proxy version 7.0.0 and later) at /etc/Druva/EnterpriseWorkloads/vmware/ , you need to stop the Druva-EnterpriseWorkloads service, add the parameter and then restart the Druva-EnterpriseWorkloads service again.

If the virtual machine has new VMDKS attached at the time of restore and if they were not backed up, then all those VMDKS will be detached from the virtual machine.

If the virtual machine has independent disks attached, then they will be detached after the original restore.

If the virtual machine has detached backed up disks, then they will be renamed as ‘<original_vmdk_name>_phoenix_ <timestamp>.vmdk’.

If the old controllers are detached from the target virtual machine , then after restore they will be attached again but if the target virtual machine has new controllers attached then will remain the same.

If the type of the controllers is changed it will remain the same after restore.

All the user snapshots will be deleted after the original restore.

For vRDM disks:

If the virtual machine has added pRDM disks then it will not be detached after restore.

The CBT state of the virtual machine will not change.

Other devices of the virtual machine such as memory, CPUs, and CDROM device are not restored. Only the data on the virtual machine is restored.

The restore request to the original location is queued if there is an active backup running for the same agent on the same proxy.

If you have CloudCache in your setup, make sure it is connected to the backup proxy.

The original drive names for Windows partitions and mount points for Linux partitions will not be preserved. The partition will be shown as volume0, volume1 and so on.

Partitions with a corrupted file system, partition table, or incorrect partition boundaries cannot be browsed or restored.

Symbolic links will not be recovered.

Sparse files on original disks will be recovered as Thick files.

On Linux partitions, the “/dev”, "/var/spool", "/var/run" “/proc” , /tmp, and, “/sys” folders will be excluded, if selected from the restore set.

On Windows partition, "CryptnetUrlCache" will be excluded if selected from restore set.

Encrypted volumes and files are not supported for File-level restore.

File-level restore may fail for the guest Windows virtual machines, if the destination folder name contains consecutive special characters. For example “A%%B”.

Druva does not store guest OS credential.

If some files are not restored, the progress log will show the number of files missed and the detailed log will list the names of the files missed.

File-level restore is not supported on spanned volumes if the volume is created using two disks, and one of the disk is excluded from the backup. To browse and restore from such volumes, a staging VM is required. For more information, see Required prerequisites for File Level Restores (FLR) for GPT Dynamic Disks. For more information on Dynamic GPT FLR support, see Support Matrix.

For restoring files from Dynamic GPT disk partition/volumes, you need a staging VM.