Forum Discussion

Hamza_H's avatar
Hamza_H
Moderator
6 years ago

Vmware indiviual file restore fails

Hi Guys,

I am having a problem with a vmware backup of a WS2008 R2 (64 bits) for which the backup is successfull, and the restore of the full VM is working, but when we select to restore individual files we get error "Unable to obtain list of files using specified search criteria".

I did a lot of digging (on veritas, vox,vmware and microsoft forums and sites) but nothing.

This is an old problem that we used to have since 7.7.3 for the same VM, a case was open and then closed, the solution from the guy was to update to 8.1.2.

the update is done and we have the same problem for the same VM.

yesterday we updated to 8.2 and the problem persists.

I knew this is a backup problem so I collected vxms logs and did a lot of tests and the vxms is widely saying :

 

" 12/12/2019 19:19:32 : rvpMapClose:RvpNtfsCoordinator.cpp:220 <TRACE> : Object: unnamed ntfs file
12/12/2019 19:19:32 : log:Error.cpp:249 <WARN> : Error: 0x00000001 occured in file ../RvpWinFile.cpp, at line 82
12/12/2019 19:19:32 : log:Error.cpp:249 <WARN> : Error: 0x00000001 occured in file ../RvpWinFile.cpp, at line 82
12/12/2019 19:19:32 : rvpMapResolveVolumes:RvpWinCoordinator.cpp:770 <WARN> : Returning: 1
12/12/2019 19:19:32 : rvp_map_resolve_volumes:libos_win.cpp:806 <WARN> : Returning: 1
12/12/2019 19:19:32 : resolveVolumesUsingOs:VixGuest.cpp:2531 <ERROR> : Virtual volume resolution failed.
12/12/2019 19:19:32 : rvpMapClose:RvpNtfsCoordinator.cpp:220 <TRACE> : Object: WinFileSystem"

 

as you can see, error " Error: 0x00000001 occured in file ../RvpWinFile.cpp" and  <ERROR> : Virtual volume resolution failed lead to those TNs: 

https://www.veritas.com/support/en_US/article.100033681 

and https://www.veritas.com/support/en_US/article.100032460.

But those TNs are for Linux and we don't have LVM and disks are not independent as Vxms says it clearly :

12/12/2019 19:19:26 : parseAndLoadDrives:VixGuest.cpp:1756 <INFO> : Number of VirtualDisks (excluding Independent disks) = 3
12/12/2019 19:19:26 : parseAndLoadDrives:VixGuest.cpp:1757 <INFO> : Number of Independent disks = 0

more information:

Type of table: GPT

File system: NTFS

3 Disks (C for system which is basic, D which is dynamic and fractioned to two partitions).

VMtools are updated.

As per "Support for Netbackup in virtual environnement" it is clearly saying :

Supports these partition tables:
■ Master Boot Record (MBR)
■ Extended Boot Record (EBR)
■ GUID Partition Table (GPT)
■ Logical Disk Manager - dynamic (LDM)
Note: Availability of the partition table type depends
on the particular Windows OS. Check your Microsoft
documentation.

 

I suspect this is a Vmware problem, mapping and things, but as veritas posted and created an eeb for linux distribution, maybe it could be the same for windows?

so please anyhelp? am I missing something?

 

8.1.2
Linux
  • sdo's avatar
    sdo
    Moderator
    6 years ago

    I also googled this "VixGuest.cpp:2531" and nothing found, so you definitely have an unusual log file entry.

    Seems to me that you have a good grasp of the debugging (well done!), and that you have enough evidence to open a support case with VMware.

    .

    1) Not that it should matter for individual file restore purposes, I'm just curious, is/was the source VM residing upon a VVOL or a VMFS datastore ?

    2) Is the problem volume NTFS ?

    3) If the original VM still exists, does the problem volume pass a "chkdsk" test ?

    4) Is the problem volume using NTFS compression ?

    HTH

    • Hamza_H's avatar
      Hamza_H
      Moderator
      6 years ago

      Dear sdo ,

      Thank you for your reply (always helping, appreciate it)

      So regarding your questions:

      1) Not that it should matter for individual file restore purposes, I'm just curious, is/was the source VM residing upon a VVOL or a VMFS datastore ?

      I actually don't have the answer to this, I will ask the end customer.

      2) Is the problem volume NTFS ?

      yes its NTFS

      3) If the original VM still exists, does the problem volume pass a "chkdsk" test ?

      I assume it does, I will confirm

      4) Is the problem volume using NTFS compression ?

      No there is not compression.

      So as I assumed, it is a Vmware problem, mapping maybe?

      I'm just asking if its worthy to log a veritas call to investigate on this, because it was the same problem but for Linux OS.. nad there was an eeb for it..

       

      Thanks 

       

      BR,

      • sdo's avatar
        sdo
        Moderator
        6 years ago

        There's no reason not to open a case with Veritas Support.  You have looked in detail at the logs and found an unusual unhandled (by the API) error.  See if Veritas Support want / need you to also open a support case with VMware, too ?

        5) Just curious, whether there are any other NTFS volumes inside the VM for which individual file restores do work, or is it that case that all volumes inside the VM suffer the same problem ?

        6) Maybe, if you are able, if you have time, maybe add a new say 5GB volume to the VM, just on a temporary basis, put one folder with one file in it, take a VM backup, and try an individual file restore of that file to a different known to be working backup/restore client.

  • sdo's avatar
    sdo
    Moderator
    6 years ago

    Also, looking at this:

    "Object: unnamed ntfs file"

    ...and...

    "log:Error.cpp:249 <WARN> : Error: 0x00000001 occured in file ../RvpWinFile.cpp, at line 82"

    ...if I google Win32 status code 0x1, I find page :

    https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

    ...which shows that 0x1 is :

    ERROR_INVALID_FUNCTION - 1 (0x1) - Incorrect function.

    ...which strikes me as quite a functionally unsual error for an API such as VMware VDDK to be unable to handle.