NetBackup™ for VMware Administrator's Guide

Restore fails because the datastore did not have enough space for the .vmdk files.

This issue can occur when a virtual machine is configured on multiple datastores and a leftover snapshot that existed on the virtual machine when it was backed up. NetBackup tries to restore all .vmdk files to the snapshot datastore.

Alternatively, you can restore the virtual machine to an alternate location.

File recovery from a VM backup is unsuccessful.

For a Linux virtual machine, if unsupported special characters are in the volume name, the Enable file recovery from VM backup option does not work. As a result, you cannot restore individual files from that volume. The following topic for supported characters.

See Optimizations options (VMware).

If a VM is configured on a logical volume (LVM or LDM): Individual file recovery does not work if the volume disk set contains a mixture of disk types:

The backup job succeeds but files cannot be individually restored from the file systems that reside on the disk set (LVM or LDM). To be able to restore files individually, reconfigure the VM's logical volumes to reside on regular virtual disks (vmdk) only. Note that VMware does not make snapshots of independent disks or RDM disks.

An incremental backup does not back up files and the individual files cannot be restored from the incremental backup.

Any files that are moved or renamed or not backed up. However, when you restore the entire VM from a block-level incremental backup, note: the file metadata is updated and the moved or renamed files in the restored VM reflect the updated metadata.

The restore fails when you restore individual files to a virtual machine that has NetBackup client software.

When you restore individual files to a virtual machine that has a NetBackup client, make sure that a firewall does not interfere with the restore. If a firewall stops the restore, turn off the firewall and retry the restore.

Mount point missing on a restored Windows virtual machine.

A Windows virtual machine may fail to write its mount point configuration to disk (the mount point configuration remains in RAM). In that case, the mount point information cannot be backed up. When the virtual machine is restored, the data from the mounted volume is restored, but the mount point is absent from the restored virtual machine.

Reassign the mount point on the restored virtual machine. To make sure the mount point is correctly configured, restart the virtual machine.

Recovery of individual files or folders is not available and requires "Switch to Instant Access".

In some cases you may find you cannot access or recover certain files with an individual file restore from a VMware backup. However, it may be possible to recover these files with the "Switch to Instant Access" feature in the web UI. Some examples of these files include files from unsupported file systems (for example, btrfs or thin-provisioned LVM volumes) or unsupported file system features (for example, files with XFS reflinks or shared extents). Additionally, if certain mount points do not display in the browse tree or list view, you may have to click "Switch to Instant Access" to view these mount points.

See Recover files and folders with VMware agentless restore.

Mount points are not available when restoring files from a Linux virtual machine.

For Linux virtual machines, only the ext2, ext3, ext4, and XFS file systems are supported for individual file restore. If a partition is formatted with some other file system, the backup succeeds but NetBackup cannot map the file system addresses of the files. As a result, NetBackup cannot restore individual files from that partition. Only the files that were on ext2, ext3, ext4, or XFS partitions can be individually restored.

Invalid client error when you restore files using the BAR interface that is installed on the virtual machine.

If the virtual machine was backed up by display name or UUID, and the display name is not the same as the host name, note: You cannot restore individual files by means of the Backup, Archive, and Restore (BAR) interface if the interface is installed on the virtual machine itself. The files can be restored if BAR is installed on the primary server or media server. In this case, BAR must not be installed on the virtual machine that you want to restore to.

To restore files, the Destination client for restores field in the BAR interface must have a valid host name or IP address.

An attempt to restore a full virtual machine fails with the SAN transport type.

Recommended action: Try the NBD transport type instead.

Restoring a virtual machine with a transport mode of NBD or NBDSSL is slow.

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

Recommended action: Use the hotadd transport mode.

The restore is from a block-level incremental backup and the changed blocks on the disk were heavily fragmented when the incremental backup occurred.

Recommended action: Use the hotadd transport mode.

For the SAN transport mode, the job is slow.

This issue can occur when you restore to a vCenter Server.

Recommended action: For greater speed, designate a VMware restore ESX server as the destination for the restore.

See Add VMware servers.

For other circumstances, see the following article:

VMware Transport Modes: Best practices and troubleshooting

For the SAN transport mode and a restore host on Windows, the restore fail.

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     

Restores that use the hotadd or SAN transport modes do not include the VM's metadata changes in the restore.

The status log of the NetBackup job contains messages similar to the following:

07/25/2013 12:37:29 - Info tar (pid=16257) INF - Transport Type
= hotadd
07/25/2013 12:42:41 - Warning bpbrm (pid=20895) from client
<client_address>: WRN - Cannot set metadata (key:geometry.
biosSectors, value:62) when using san or hotadd transport.

Recommended action: Retry the restore with a different transport mode (nbd or nbdssl).

This problem is a known VMware issue.

You cannot restore individual VMware files onto the virtual machine itself, except under certain conditions.

Make sure that the VMware Tools are installed and up to date on each virtual machine.