Restore notes and restrictions
Before you begin the restore, note the following:
Cross-platform restore of individual files is not supported. You can restore Windows files to Windows guest operating systems but not to Linux. You can restore Linux files to supported Linux guest operating systems but not to Windows. In other words, the restore host must be the same platform as the files that you want to restore.
If you have back-level hosts in your environment, note the following about mixed-level backups and restores: The recovery host must be at the same or a later NetBackup release level as the backup host. For example, you cannot use a NetBackup 11.x recovery host to restore a virtual machine that was backed up by a NetBackup 10.x backup host.
Unless a NetBackup client is installed on the virtual machine, you must do the restore from the NetBackup primary server. Or, perform a VMware agentless restore or create an instant access VM for the restore.
To restore files to the original virtual machine location, the destination must be specified as the virtual machine's host name (not display name or UUID).
To restore directly to an ESX server, the name that is specified for the restore must match the ESX server's official host name. The name must be in the same format in which it is registered in DNS and in the VMware server (whether short or fully-qualified).
See Add VMware servers.
If the VM's display name was changed after the VM was backed up, the pre-recovery check may fail when you click :
VM exists overwrite -Failed. Vmxdir for VM exists
You can ignore the error and click , but note: The restore may succeed but the folder that contains the vmx file for the newly restored VM has a different name than the vmx folder of the existing VM. VMware does not rename this folder when the VM is renamed, but continues to use the existing folder.
As an alternative, restore the VM to a different location.
A virtual machine template cannot be restored to a standalone ESX server. Because templates are a feature of vCenter servers, you must restore the template through vCenter. If you restore a template to a standalone ESX server, the template is converted to a normal virtual machine and is no longer a template.
NetBackup supports backup and recovery of VMware NVRAM files and the vTPM devices that are associated with virtual machines.
Supported recovery methods for NVRAM and vTPM protection include Full VM recovery and VMware Instant Recovery.
NetBackup does not support the backup or restore of NVRAM and vTPM for the virtual machines whose display names begin with a period ('.'). An existing VMware limitation prevents downloading or uploading data store files beginning with a period ('.') to a virtual machine's working directory as these appear as hidden files.
Restore of individual files from a backup of the full virtual machine is not supported if the virtual machine contains Arctera InfoScale volumes.
To restore Windows NTFS-encrypted files individually, you must install a NetBackup client on the virtual machine.
VMware does not support the restore of virtual machines directly to an ESX 5.x server that vCenter manages. To restore the virtual machine, select the vCenter server as the destination.
As an alternative, you can set up an independent ESX server to be used for restores. You must add NetBackup restore credentials for that ESX server by means of the VMware restore ESX server server type.
See Add VMware servers.
The APIs in VMware's Virtual Disk Development Kit (VDDK) contain the following limitation: The maximum write speed during virtual machine restore is roughly one third of the hardware's maximum speed.
If a virtual machine had vmdk files in different directories in the same datastore, note: When the virtual machine is restored to the original location its vmdk files are restored to a single directory, not to the original directories. (This behavior follows current VMware design.)
As a workaround, do the following: Remove the vmdk files from the restored virtual machine, move the files to their respective directories, then re-attach the moved files to the virtual machine.
If the original VM contains encrypted vmdk files, after restoring the full VMware virtual machine to the original location or after an in-place disk restore, the restored disks may not be compliant to the VM encryption policy. Therefore, the restored VM must be reconfigured manually to comply with the policy. Otherwise, the virtual disks of the restored VM might be left in an unencrypted state.
When restoring large files, make sure that no snapshots are active on the destination virtual machine. Otherwise, the files are restored to the VMware configuration datastore, which may be too small to contain the files you want to restore. In that case, the restore fails.
The configuration datastore (sometimes called the vmx directory) contains the configuration files that describe the virtual machine, such as
*.vmxfiles. Note that active snapshots of vmdk files are also stored on the configuration datastore.If you cancel the virtual machine restore before it completes, the not-fully-restored virtual machine remains at the target location. NetBackup does not delete the incomplete virtual machine when the restore job is canceled. You must manually remove the incomplete virtual machine.
If the virtual machine display name contains unsupported characters, the backup may succeed but the restore fail. To restore the virtual machine, you must change the display name to contain supported characters only and retry the restore.
See NetBackup character restrictions for the Primary VM identifier.
NetBackup for VMware does not support individual file restore by means of client-direct restore.
On a restore, NetBackup recreates the linking between a hard link and its original file only in this case: The link file and its target file are restored in the same job. If each file is restored individually in separate restore jobs, they are restored as separate files and the link is not re-established.
If you restore a VM in vCloud to an expired vApp, the vApp is automatically renewed and added back into the vCloud organization. If the expired vApp contained other VMs, all those VMs are also removed from the expired list and added to the organization.
Note that in vCloud Director, an expired vApp must be renewed before you can import a VM into that vApp.
In VMware vSphere 6.0 U1b and later, a full restore of a virtual machine may trigger an alarm if the original VM was not deleted. The alarm is a VM MAC address conflict alarm. This VMware alarm behavior is by design. If there is a MAC address conflict, VMware eventually changes the MAC address of the new VM. If you do not want to receive alarms, disable the VM MAC address conflict alarms in vCenter.