Skip to main content
Druva Documentation

Restore prerequisites and considerations

 

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

Considerations for restoring a virtual machine

  • Hot snapshots reside on Phoenix CloudCache for a period that you specified at the time of configuring Phoenix 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 Phoenix 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.

  • Although Phoenix 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, Phoenix creates a new virtual machine with minimum configuration and associates the VMDK files that you selected to it.

  • Phoenix 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. 

  • Phoenix 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, Phoenix restores only those disks for which the mode is supported.

  • In case of virtual machine restore to the original location, Phoenix restores the virtual machine to its original network configuration. However, for a virtual disk restore or restore to an alternate location, Phoenix 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.

Considerations for full virtual machine restore to the original location

  • 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:

    • For the backup proxy registered as VC, if vRDM detached at the time of restore then the thick disk with a new name as ‘<original_vmdk_name>_phoenix_ <timestamp>.vmdk’ will be created and vRDM disk will remain same.

    • For backup proxy registered as standalone ESX, the detached vRDM disk will be renamed as ‘<original_vmdk_name>_phoenix_ <timestamp>.vmdk’  and new thick disk will be created instead of detached vRDM disk.

Note: Restore to original location for virtual machines that have vRDM disk is supported. If vRDM disks are not detached before the restore then they are restored as vRDM.

  • 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.

Considerations for file and folders restore

  • 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 the corrupted file system, partition table or incorrect partition boundaries may not get mounted.

  • Symbolic links will not be recovered.

  • File-level restore is not supported on GPT partitioned dynamic disk on Windows.

  • 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.

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

  • 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”.

  • Phoenix 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 disks is excluded from the backup. 

Restore Virtual Machines