Restore notes and restrictions
This topic is about restores from a NetBackup backup of a VMware virtual machine.
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.
Unless a NetBackup client is installed on the virtual machine, you must do the restore from the NetBackup master server.
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).
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.
Changes to a VM's boot settings reside in the VM's non-volatile random-access memory (the
.nvramfile). Note that NetBackup does not back up the.nvramfile: Changes to a VM's default boot settings are not backed up. When you restore the VM, the changed boot settings are not available, and the VM may be unable to boot.For more details and a workaround, see the following tech note:
If the virtual machine was backed up by its display name or UUID, and the display name differs from the host name, note: You must specify the correct destination client for the restore. Use the Specify NetBackup Machines and Policy Type dialog in the NetBackup Backup, Archive, and Restore interface.
Restore of individual files from a backup of the full virtual machine is not supported if the virtual machine contains Storage Foundation Volume Manager volumes.
To restore Windows NTFS-encrypted files individually, you must install a NetBackup client on the virtual machine.
If the attempt to restore a full virtual machine fails while using the SAN transport type, try the NBD transport type instead.
Restoring a virtual machine with a transport mode of NBD or NBDSSL may be slow in the following cases:
The virtual machine had many small data extents due to heavy fragmentation. (A file system extent is a contiguous storage area defined by block offset and size.)
The restore is from a block-level incremental backup and the changed blocks on the disk were heavily fragmented when the incremental backup occurred.
For faster restores in either of these cases, use the hotadd transport mode instead of NBD or NBDSSL.
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.
For the SAN transport mode, the job may be slow when you restore to a vCenter Server. For greater speed, designate a VMware restore ESX server as the destination for the restore.
For the SAN transport mode and a restore host on Windows 2008 R2 or later, the restore fails if the datastore's LUN is offline. The detailed status log contains messages similar to the following:
5/22/2013 4:10:12 AM - Info tar32(pid=5832) done. status: 24: socket write failed 5/22/2013 4:10:12 AM - Error bpbrm(pid=5792) client restore EXIT STATUS 24: socket write failed
Make sure the status of the SAN disk on the restore host is online (not offline). Disk status can be checked or changed using the Windows diskpart.exe utility or the Disk Management utility (diskmgmt.msc). When the disk status reads online, retry the restore.
If multipathing is enabled, make sure all the paths are online.
A restore by means of the SAN transport mode may be slow in other circumstances. The following Veritas article provides details:
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. The following Veritas tech note contains further information:
Two causes of slow NetBackup for VMware restore performance
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.
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.
With a remote connection from a Windows Java GUI that uses the English locale, the restore of files that have non-ASCII characters may fail.
See the following tech note for further information on how to restore the files:
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.