cancel
Showing results for 
Search instead for 
Did you mean: 

Restore and Backups of VM are slow

Rob_Dullaart
Level 5

Hello,

I have a question about Netbackup and VMware. I configured VADP backups for some VM's. All these VM's are on the same ESX server. The first initial backup went very slow, about 150kb/sec. All finished succesfull, and the next backups went smooth and looked fast, probably because of accelerator. 
But now we want to do a test restore. I have initiated three test resores of three VM's. I've done this before in other VM clusters in my company, there it went fast. But now in this setup it is going as slow as the first initial backup. 150kb/sec. This is unacceptable for my company. It should finish within an hour or so, but now it has been running for day and it is still not finished. 

What I think is that the backup and restore run through the management network interface of the ESX server. But how can I determine this? Where can I find the address where the data flow is going?
Regards,
Rob

2 REPLIES 2

X2
Moderator
Moderator
   VIP   

You have not provided any details of your setup. At least copy the Job Details of one of your VMware backup as a starting point. It will definitely show how the transport is taking place.

This might help: http://www.veritas.com/docs/100030882

https://vox.veritas.com/t5/Netting-Out-NetBackup/Nuts-and-bolts-in-NetBackup-for-VMware-Transport-me...

zach1
Level 3

How to determine the ESX network that NetBackup used for the backup or restore

If a virtual machine's disks are accessible to multiple ESX hosts, the disks can be accessed through any of the ESX hosts. The ESX host that is used for the access may or may not be the ESX host where the virtual machine is running or registered. All of the following must be accessible to each other and should have DNS configured:

  • The vCenter server.

  • All ESX hosts under the vCenter that have access to the virtual machine's vmdk files.

  • The backup host.

If all hosts are not accessible to each other, the backup or restore may not succeed. In that case, you must determine which network NetBackup used for the backup or restore.

Note: For an NBD transport mode backup through vCenter, NetBackup uses the ESX network over which the ESX host was added or registered to the vCenter. For an NBD transport mode backup directly from the ESX host, NetBackup uses the ESX host's DNS/IP network.

The VxMS provider logs contain information on the network that NetBackup used.

See Configuring VxMS logging.

Check the VxMS provider logs for messages similar to those in this example:

10:49:21.0926 : g_vixInterfaceLogger:libvix.cpp:1811 <INFO> : Opening file
[MYDATASTORE] TestVM/TestVM-000001.vmdk (vpxa-nfc://[MYDATASTORE]
TestVM/TestVM-000001.vmdk@MyESX.xxx.xxx.com:902)

   10:49:22.0301 : g_vixInterfaceLogger:libvix.cpp:1811 <INFO> : DISKLIB-LINK  :
Opened 'vpxa-nfc://[MYDATASTORE]
TestVM/TestVM-000001.vmdk@MyESX.xxx.xxx.com:902' (0x1e): custom, 41943040
sectors / 20 GB.

   10:49:22.0301 : g_vixInterfaceLogger:libvix.cpp:1811 <INFO> : DISKLIB-LIB   :
Opened "vpxa-nfc://[MYDATASTORE]
TestVM/TestVM-000001.vmdk@MyESX.xxx.xxx.com:902" (flags 0x1e, type custom).

   10:49:22.0301 : vdOpen:VixInterface.cpp:480 <DEBUG> : Done with
VixDiskLib_Open(): 200346144
   10:49:22.0301 : openLeafSnapshotDisks:VixGuest.cpp:475 <DEBUG> : vdOpen()
succeess
   10:49:22.0301 : openLeafSnapshotDisks:VixGuest.cpp:476 <INFO> : Transport
mode in effect = nbd

VMware logs the messages starting with g_vixInterfaceLogger. Such messages in the example indicate that TestVM-000001.vmdk is opened over the ESX host network MyESX.xxx.xxx.com.

 

Moreover, you can run the third party utilities to check the write speed on the disk as mentioned in the technote.
https://www.veritas.com/support/en_US/article.TECH169860

M
oreover as mentioned in the vmware 8.0 admin guide.



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.