Thanks, Ahmed.

Space for the VADP mountpoint is not an issue, but I'll pass the disk/LUN information to our VMware admins.

Incidentally, the machines that are failing their VADP backup all had successful VCB backups prior to the NW upgrade.  Of course, it's difficult to work out what has broken things since we upgraded NetWorker and vSphere and moved to VADP at essentially the same time.

B

For SAN mode backups, the VADP proxy requires read access to the SAN LUNs hosting the virtual machines.

Also you have to use the Diskpart utility for SAN and hotadd transport modes , Where an RDM NTFS volume is being used for any of the VMs on the VADP proxy host, Windows will automatically attempt  to mount the volume and assign drive letters to VM disks during backup. This may lead to data corruption on the VMs.To prevent Windows from automatically assigning drive letters to the RDM NTFS, perform the following steps.

Note: Steps 1 and 2 are only applicable in the case of SAN transport mode where SAN fabric zoning is already in place such that the VADP proxy host is already displaying the SAN LUNs in Windows disk management. If this does not apply, skip to Step 3.

1. Shut down the Windows proxy.

2. Disconnect the Windows proxy from the  SAN or mask all the LUNs containing VMFS volumes or RDM for virtual machines.

3. Start the proxy and log into an account with administrator privileges.

4. Open a command prompt and run the diskpart utility by entering the following:

diskpart

The diskpart utility starts and prints its own command prompt.

5. Disable automatic drive letter assignment to newly discovered volumes by entering the following in the diskpart command prompt:

automount disable

6. Clean out entries of previously mounted  volumes in the registry by entering the following in the diskpart command prompt:

automount scrub

Waiting your updates.

Thanks,

Ahmed Bahaa

Hi,

Make sure that your machines are not configured with independent persistent disks as VADP does not support the backup and recovery of these disks, Also make sure that you are not using Dynamic Disks ( You can check that from the Disk management console inside each machine )

There is space considerations and recommendations needed for the VADP mount point (VADP_BACKUPROOT), which is C:\VCB_Backups in your case, The VADP mount point cache requires space equal to at least 5-10% of the total amount of data being backed up in th e case of Windows VMs. This space is required for temporarily storing the VMDK index during the backup, and is cleaned up once the backup completes.  In the case of Linux or FLR-disabled

Windows VMs, minimal space is required as indicated in the note below.

As an example of how much space is required for a Windows VM:

If the proxy client parallelism is set to 5 so that a maximum of 5 Windows VMs are backed up concurrently, then calculate the total used disk space for the 5 largest Windows VMs in the environment. Allocate at least 10% of this total used space for the VADP_BACKUPROOT mount point.

So, if each VM in the above example has around 2 disks and each disk has 40GB used space.

• Total amount of data being backed up=40GB*2*5=400GB

• Total amount needed for mount point=400*10%=40GB

In this case, ensure that the drive specified for VADP_BACKUPROOT has at least 40GB of free space.

Note: This mount point space is only needed when performing FLR-enabled image level backups of Windows VMs. It is otherwise very minimal (in the order of a few MB per VM) when performing image level backups of Linux VMs or FLR-disabled image level backups of Windows VMs.

Thanks,

Ahmed Bahaa

Hi all

I've managed to get the client that was failing its weekly backup backup but not its monthly backup working.  I don't remember doing anything to fix it, but it's working nonetheless...

I've also managed to get VADP to use the nbd transport method as specified in the original error.  However, the backup is still failing with the same issue:

Obtained the virtual disks for the VM.

Change block tracking is disabled for VM: vm_hostname

File level Recovery from Image level backup is enabled.

MORef for the VM is obtained.

Obtained the virtual disks for the VM.

Using 'nbd' as the transport mode for Hard disk 1.

Starting mountvm operation.

Successfully mounted the VM as a file system.

Could not mount required number of volumes. Exiting.

The VADP proxy and the VM client are possible clones of each other or derived from the same parent. Please try by setting the transport mode as nbd.

Has anyone come across this before?

Thanks

B

Hi,

I am using nsr 8.0.2.6 on each machine. I am trying to configure VADP backup for a VM having Windows 2003, 32-bit OS. The proxy and storage node are the same VM machine running on Windows 2008 R2, The networker server is running on 2008 R2.

The backup is failing with "

Could not mount required number of volumes. Exiting.

The VADP proxy and the VM client are possible clones of each other or derived from the same parent. Please try by setting the transport mode as nbd "

https://emc--c.na5.visual.force.com/apex/KB_BreakFix_1?id=kA1700000000WPH is a knowledge article on this issue. I have tried it, ran the nsrvadp_save with debug mode 9 but I did not get the errors as indicated in the KB.

https://community.emc.com/message/685962 , https://community.emc.com/message/617398 also suggests some items to be checked but there is no issue, disks are not independent persistent disks, disks are formatted using NTFS, using English alphabets as the drive letters. Datastore has enough space for mount and snapshot.

Backup is not failing during snapshot rather it fails during mounting the volumes

Please note the error is at the step when volumes are being mounted.

I have checked the 'recommendations and considerations for VADP backup and recovery', it talks of following w.r.t to VixMountApi,

Ensure the path specified in VixDisklib and VixMountAPI config files are enclosed in

double quotes as below:

tempDirectory="C:\Program Files\EMC NetWorker\nsr\plugins\VDDK\tmp"

These files are stored in the following location by default:

\nsr\plugins\VDDK\

         Note: Double quotes should be specified in the path even though the path is already

present.

I have checked and the above holds true in my case. The VADP proxy is also the proxy for other VMs and the backups for other VMs is running fine, something is wrong with this particular VM (remember this is a new configuration).

What are the things that could be checked?

Regards

tech88kur

Dear All,

I gave a try to backup after rebooting the machine, hoping something would change but nothing has. Backup still fails with the same errors.

Did anybody face something similar?

Regards

tech88kur