Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. NetBackup™ for VMware Administrator's Guide
  3. Troubleshooting VMware operations
  4. Troubleshooting the restore of VMware and restores of files
NetBackup™ for VMware Administrator's Guide

Troubleshooting the restore of VMware and restores of files

The following table describes the issues that may occur when you perform VMware restores.

Table: Errors with VMware restores and file restores

Issue

Explanation

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:

  • Some of the logical volume disks are regular virtual disks (normal VMDKs).

  • Some of the disks in the same volume are independent disks or are physical disks in raw device mapping mode (RDM).

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.

Note:

To restore individual files from their original mount points, the "/" (root) partition must be formatted as ext2, ext3, ext4, or XFS. If the "/" (root) partition is formatted with a different file system (such as ReiserFS), the mount points cannot be resolved. In that case, you can restore ext2, ext3, ext4, or XFS files from the /dev level (such as /dev/sda1). You cannot restore the files from their original mount point level.

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     

Recommended action:

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

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.

Feedback

Was this page helpful?
Previous

Troubleshooting VMware backups

Next

Troubleshooting the adding of VMware servers

Feedback

Was this page helpful?