Replies to This Discussion

Permalink Reply by Jerry Schmidt on January 28, 2015 at 9:36am

Hello Tom,

There was a bug identified at the 3.1.2 version where there was a delay in showing partition in /recover/files after a CBT backup. This was resolved in version 3.2 so the most current version 3.2.1 has this fix as well.

Does this issue happen on any VM that is backed up? If you point to a full backup folder opposed to a CBT backup folder do you see files available for copy?

Also, is vmPRO and the DXI6700 connected to a domain controller? If so are the vmPRO, DXI, ESX server or vCenter, and DC all using the same NTP server? If there is a time difference of 300 seconds or greater, this can cause issues when trying to access the files via /vmpor**/recover/files.

If you are not using a domain controller and just have a work-group defined on the DXi, make sure to add the vmPRO user name and password to the Share Access list on the DXI so vmPRO has rights to access the share.

• ▶ Reply

Permalink Reply by Tom on January 28, 2015 at 12:30pm

A couple updates

1. version 3.2.1

2. dxi,vmpro on a domain

3. I can view \\vmpro**\export\    vm files are visible

need to confirm ntp

• ▶ Reply

Permalink Reply by Jerry Schmidt on January 28, 2015 at 12:43pm

The big difference between /vmpro/export and /vmpro/recover/files is that /export is what vmPRO intends to backup and /recover/files is what vmPRO has backed up.

/recover/files is linking to the share on the DXi. /export is linking to the VMDK files on the VMs that vmPRO saw the last time it ran a discovery job (runs once an hour by default).

• ▶ Reply

Permalink Reply by Tom on January 29, 2015 at 7:37am

I checked the ntp settings that looks good

every time I try to map it I just receive logon prompt but I never get any further

now if I browse to \\vmpro***\recover\images\ dxi\2014-02\esx server\vm1

I see the vmdk files just fine

 

 

• ▶ Reply

Permalink Reply by Jerry Schmidt on January 29, 2015 at 7:49am

Are the VMs in question dynamic volumes?

I asked because per the current vmPRO User guide, these types of volumes are not supported for file level recovery.

Note:File-level recovery for dynamic volumes that span multiple disks is currently not supported.

• ▶ Reply

Permalink Reply by Tom on January 29, 2015 at 9:18am

No dynamic disks

• ▶ Reply

Permalink Reply by Jerry Schmidt on January 29, 2015 at 10:36am

Well I am starting to run out of ideas, but here are two more things to try.

I am unsure if the DXI you have is in production, but if it is not try dis-joining the DXI from the DC and then create a work group, add the vmPRO credentials to the access list and then see if you can see the files for file level recovery when mounting the UNC path via vmPRO.

If you use the DXI in production and it needs to stay connected to the DC, then create a new share on the DXI and use the NFS protocol instead of CIFS. Then reconfigure vmPRO to sent backups to the new NFS share. Once done, use the UNC path and try to mount to the \vmpro**\recover\files and see if the files are available. This will still work because vmPRO host a samba session for the folders.

Either one of these test would bypass the DC, if you can see the files then you will know that some part of the DC configuration is causing the issue. If you still are not able to see the files then most likely we will need to get a support contract set up on your vmPRO and DXI (if you don't already have one) so we can investigate further.

• ▶ Reply

Permalink Reply by Tom on January 29, 2015 at 12:49pm

Thanks for all your support .....

I might have found the issue under primary domain controller it states "dns discovery" on the DXI

not a domain controller

• ▶ Reply

Permalink Reply by Tom on January 30, 2015 at 1:55pm

Just wanted to follow up and thank you for the suggestions

so I downloaded latest vmpro and set up a nfs share and performed a back up successfully. Then I was able to access the file as mentioned \\vmpro\recover\files

so I tested it on the other vmpro I have in my environment using the local sysadmin account and that worked so the issue is AD authentication

• ▶ Reply