NVP-vProxy: Data Protection Restore Client Does Not List SQL VM Backups

• The Data Protection Restore Client (DPRC) is accessed from a web browser: https://NetWorker_Server_Address:9090/flr
• The Admin and App options are selected and the user authenticates successfully.
• The source vCenter and a time range are specified, the SQL VM is selected but no backups are displayed:
   
• The environment consists of multiple vCenter servers. The SQL VM selected for restore was copied (or replicated) to the new vCenter. The VM exists (or existed) in both vCenter environments. The replication method used was external to NetWorker.

The VM was replicated using a method which resulted in a "copied" VMware Universally Unique Identifier (UUID). The NetWorker media database lists the same UUID under two different vCenters. For example:

[root@nsr ~]# mminfo -avot -q vmname=SQLVM02 -r name | sort | uniq
vm:503df65c-90cd-e729-13a4-2f5711ba5b85:MyOldvCente.amer.lan
vm:503df65c-90cd-e729-13a4-2f5711ba5b85:MyNewvCenter.amer.lan

The DPRC uses REST API to connect to the NetWorker server and list backups. It uses a global REST API GET request to find the VM using global/vmware/vms?q=Uuid:UUID. The following is seen in the flr-server.log.

• Linux: /nsr/authc/logs/flr-server.log
• Windows (Default): C:\Program Files\EMC NetWorker\nsr\authc-server\tomcat\logs\flr-server.log

2026-04-08 13:43:42,855 [https-jsse-nio-9090-exec-4] INFO  c.e.n.c.n.i.NwRestApiBase.buildWebResourceFromUri 171 - Call NW: [https://NETWORKER_SERVER_ADDRESS:9090/nwrestapi/v3/global/vmware/vms?q=Uuid:VM_UUID]

The DPRC is not able to present the backups because the conflict appears due to the unique identifier appearing in multiple vCenters. The same REST API call returns both vCenters:
Linux:

curl -k --user Administrator "https://localhost:9090/nwrestapi/v3/global/vmware/vms?q=Uuid:UUID"

Windows:

curl.exe -k --user Administrator "https://localhost:9090/nwrestapi/v3/global/vmware/vms?q=Uuid:UUID"

Example:

[root@nsr ~]#  curl -k --user Administrator:'!Password1' "https://localhost:9090/nwrestapi/v3/global/vmware/vms?q=Uuid:503df65c-90cd-e729-13a4-2f5711ba5b85" | jq                                                                                
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1213    0  1213    0     0  17328      0 --:--:-- --:--:-- --:--:-- 17328
{
  "count": 2,
  "vms": [
    {
      "annotation": "",
      "connectionState": "connected",
      "hostname": "SQLVM02",
      "ipAddress": "192.168.9.10",
      "ipAddresses": [
        "192.168.9.10"
      ],
      "links": [
        {
          "href": "https://localhost:9090/nwrestapi/v3/global/vmware/vcenters/MyNewvCenter.amer.lan/vms/503df65c-90cd-e729-13a4-2f5711ba5b85",
          "rel": "item"
        }
      ],
      "morefId": "vm-1364",
      "name": "SQLVM02",
      "osId": "windows2019srv_64Guest",
      "osName": "Microsoft Windows Server 2019 (64-bit)",
      "powerState": "on",
      "state": "running",
      "status": "green",
      "type": "VirtualMachine",
      "uuid": "503df65c-90cd-e729-13a4-2f5711ba5b85",
      "vCenterHostname": "MyNewvCenter.amer.lan",
      "version": "vmx-18"
    },
    {
      "annotation": "",
      "connectionState": "connected",
      "hostname": "",
      "ipAddress": "",
      "ipAddresses": [],
      "links": [
        {
          "href": "https://localhost:9090/nwrestapi/v3/global/vmware/vcenters/MyOldvCenter.amer.lan/vms/503df65c-90cd-e729-13a4-2f5711ba5b85",
          "rel": "item"
        }
      ],
      "morefId": "vm-15697",
      "name": "SQLVM02",
      "osId": "windows9Server64Guest",
      "osName": "Microsoft Windows Server 2016 (64-bit)",
      "powerState": "off",
      "state": "notRunning",
      "status": "gray",
      "type": "VirtualMachine",
      "uuid": "503df65c-90cd-e729-13a4-2f5711ba5b85",
      "vCenterHostname": "MyOldvCenter.amer.lan",
      "version": "vmx-18"
    }
  ]
}

This is not expected behavior. The inherent expectation with a UUID is that it is unique. When querying for a VM UUID, only the results for one VM in one vCenter are expected.

It is not possible to recover the data from DPRC due to the UUID conflict in VMware environments. See the Additional Info section for a workaround.

The following steps can correct the duplicate UUID; however, this does not make the existing backup data recoverable. This below change is a corrective action for backups taken after the change and onward. Once the backups using the duplicate UUID have expired from NetWorker, the recover UI correctly finds the VM backups using their Universally Unique ID (UUID).

1. For the duplicate VM, remove it from any NetWorker protection groups where it is currently backed up.
2. Power of the new VM in VMware.
3. Unregister the VM from the vCenter inventory (select "Remove from Inventory"). Do not delete the VM.
4. Reregister the VM: Browse the datastore, right-click the .vmx file, and select "Register VM."
5. Power on the VM. When prompted by vCenter, select "I copied it." This forces vSphere to generate a brand-new, unique BIOS and Instance UUID.
6. Add the Virtual Machine (VM) back to the protection groups from which it was removed in step 1.

See the following VMware documentation regarding the impacts of duplicate UUID: Changing or keeping a UUID for a moved virtual machine 

Prerequisite:

• The save set required for restore must be a database save set, not a txnlog backup. This can be identified using the NetWorker server mminfo command:

mminfo -avot -q vmname=SQL_VM-NAME

Example:

[root@nsr ~]# mminfo -avot -q vmname=win-sql01.amer.lan
 volume        type   client           date     time         size ssid      fl   lvl name
...
VMBackupPool.002 Data Domain vcsa.amer.lan 04/11/2026 11:38:14 AM 104 GB 4124732135 cr full vm:503ea434-0331-8ed6-8b19-b9cd408cce7a:vcsa.amer.lan
VMBackupPool.002 Data Domain vcsa.amer.lan 04/11/2026 12:30:09 PM 2341 KB 4107958035 cr txnlog vm:503ea434-0331-8ed6-8b19-b9cd408cce7a:vcsa.amer.lan

The full backup is a full database backup including the Virtual Machine Disk (VMDK). The txnlog backup only contains the transaction logs and does not include the databases.

• The VM backup must reside on a Data Domain, if it is on another media type (Tape, CloudBoost, AFTD), clone the backup from tape to a Data Domain that is accessible to the vCenter: NVP vProxy: How to manually clone a VM save set from a non-Data Domain device to a Data Domain clone device
• The process for creating the NFS export and mounting it to VMware and the target VM is documented in the following article: NetWorker: Manually Mounting Windows VM Save Set Disk For FLR Process Without vProxy Appliance

Data Recovery:

After performing the pre-requisite steps, the VM disk containing the SQL data should be mounted to the SQL VM with a random drive letter. Perform the following steps:

1. Copy the SQL database .mdf and .ldf files from the attached disk to another location on the VM. For example, the following databases are found in the attached disk:

PS R:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA> dir


    Directory: R:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
...
-a----         4/10/2026  11:46 AM        8388608 NetWorkerSupport.mdf
-a----         4/10/2026  11:32 AM        8388608 NetWorkerSupport_log.ldf
...

PS C:\tmp\RecoveredSQLdata> dir


    Directory: C:\tmp\RecoveredSQLdata


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         4/10/2026  11:46 AM        8388608 NetWorkerSupport.mdf
-a----         4/10/2026  11:32 AM        8388608 NetWorkerSupport_log.ldf

2. Ensure that the files are and folders are not "Read Only." Right-click the folder path to the data and ensure "Read Only" is not checked. The files must also not have "Read Only" selected:
    
3. Log in to SQL Server Management Studio (SSMS) with an administrative user account.
4. Right click Databases, then click Attach.
5. In the Databases to attach window, click Add. Browse to the location the .mdf file was copied to and select it.
6. If the SQL server contains a database with the same name as the original database, you must rename the database you are importing. Select the Attach As field and rename the database, for example add _OLD.

7. Click OK, the database imports into the SQL Server Management Studio.
   WARNING: Any permissions or OS-based import errors must be resolved by the system or database administrator.
   
   In this example, the original database NetWorkerSupport exists and the backup copy "NetWorkerSupport_OLD" is imported.

The database table contains content from the original database at the time of backup:

The SQL data is recovered to the system and is manageable by the SQL Database Administrator. Once the data is recovered and no further data is required from the backup media, the disk can be detached from VMware. The temporary NFS datastore can also be detached from VMware, and the NFS export on the Data Domain can be removed. These cleanup steps are detailed in the Cleaning Up After Restore Operations section of:  NetWorker: Manually Mounting Windows VM Save Set Disk For FLR Process Without vProxy Appliance