NVP-vProxy: Data Protection Restore Client no enumera los respaldos de VM de SQL

Resumen: El vProxy de NetWorker VMware Protection (NVP) se utiliza para respaldar máquinas virtuales (VM) de Microsoft SQL. El entorno consta de varios entornos de vCenter y la VM de SQL se copió en otro vCenter fuera de las prácticas de NetWorker. Las restauraciones de VM de SQL se realizan desde Data Protection Restore Client (DPRC). El asistente de DPRC no muestra respaldos de SQL para una VM, no se muestra ningún error. ...

Este artículo se aplica a Este artículo no se aplica a Este artículo no está vinculado a ningún producto específico. No se identifican todas las versiones del producto en este artículo.

Síntomas

  • Se accede a Data Protection Restore Client (DPRC) desde un navegador web: https://NetWorker_Server_Address:9090/flr
  • Se seleccionan las opciones Admin y App y el usuario se autentica correctamente.
  • Se especifican el vCenter de origen y un rango de tiempo, se selecciona la VM de SQL, pero no se muestran respaldos:
    Data Protection Restore Client no muestra respaldos 
  • El entorno consta de varios servidores vCenter. La VM de SQL seleccionada para la restauración se copió (o replicó) en el nuevo vCenter. La VM existe (o existió) en ambos entornos de vCenter. El método de replicación utilizado fue externo a NetWorker.

Causa

La VM se replicó mediante un método que dio como resultado un identificador único universal (UUID) de VMware "copiado". La base de datos de medios de NetWorker enumera el mismo UUID en dos vCenters diferentes. Por ejemplo:

[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

El DPRC utiliza la API REST para conectarse a NetWorker Server y enumerar los respaldos. Utiliza una solicitud GET de la API REST global para encontrar la VM mediante global/vmware/vms?q=Uuid:UUID. Lo siguiente se ve en el flr-server.log.

  • Linux: /nsr/authc/logs/flr-server.log
  • Windows (valor predeterminado): 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]

DPRC no puede presentar los respaldos porque el conflicto aparece debido al identificador único que aparece en varios vCenter. La misma llamada a la API REST devuelve ambos 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

Ejemplo:

[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"
    }
  ]
}

Este no es un comportamiento esperado. La expectativa inherente a un UUID es que sea único. Cuando se consulta por un UUID de VM, solo se esperan los resultados de una VM en un vCenter.

NOTA: Este mismo problema se observa cuando se intentan operaciones de restauración a nivel de archivos (FLR) desde DRPC.

Resolución

No es posible recuperar los datos de DPRC debido al conflicto de UUID en entornos VMware. Consulte la sección Información adicional para obtener una solución alternativa.

Los siguientes pasos pueden corregir el UUID duplicado; Sin embargo, esto no hace que los datos de respaldo existentes sean recuperables. El siguiente cambio es una acción correctiva para los respaldos realizados después del cambio y en adelante. Una vez que los respaldos que utilizan el UUID duplicado vencieron de NetWorker, la interfaz de usuario de recuperación encuentra correctamente los respaldos de VM mediante su ID único universal (UUID).

  1. En el caso de la VM duplicada, elimínela de cualquier grupo de protección de NetWorker en el que esté respaldada actualmente.
  2. Potencia de la nueva VM en VMware.
  3. Cancele el registro de la VM del inventario de vCenter (seleccione "Eliminar del inventario"). No elimine la máquina virtual.
  4. Vuelva a registrar la máquina virtual: Navegue por el almacén de datos y haga clic con el botón secundario en el .vmx y seleccione "Register VM".
  5. Encienda la VM. Cuando vCenter se lo solicite, seleccione "Lo copié". Esto obliga a vSphere a generar un UUID de instancia y un BIOS únicos y completamente nuevos.
  6. Vuelva a agregar la máquina virtual (VM) a los grupos de protección de los que se eliminó en el paso 1.
NOTA: La máquina virtual se elimina del grupo y se vuelve a agregar para evitar que el UUID antiguo quede en la lista de elementos de trabajo después de que el UUID cambie en VMware. Consulte: NVP vProxy: Si no se puede encontrar el elemento de trabajo de VM seleccionado con el UUID "UUID" en vCenter, se omitirá el elemento de trabajo.

Consulte la siguiente documentación de VMware sobre los impactos del UUID duplicado: Cambio o mantenimiento de un UUID para una máquina virtual transferida Este hipervínculo lo redirige a un sitio web fuera de Dell Technologies.

 

Información adicional

NOTA: El siguiente enfoque se puede utilizar para recuperar los datos de SQL en la VM sin la participación de NetWorker Server, vProxy o DPRC. Este enfoque implica la creación de una exportación de NFS en Data Domain mediante la carpeta del saveset del respaldo. La exportación NFS se monta como un almacén de datos NFS en VMware. El disco de VM del almacén de datos NFS está conectado a una VM de SQL en el entorno VMware. SQL .mdf y .ldf los archivos se copian del disco a otra ubicación en la VM y se importan a SQL Server Management Studio (SSMS).
PRECAUCIÓN: Esta es la mejor solución alternativa posible para intentar recuperar datos en una situación en la que las condiciones del entorno impidieron que la interfaz del usuario de restauración encontrara los respaldos correctos. El soporte de NetWorker ayuda con elementos como la selección de la ruta correcta del saveset en Data Domain, mientras que las tareas de VMware, SO y SQL se manejan a través de sus respectivos administradores. Todas estas son operaciones externas de NetWorker que deben realizar los administradores de bases de datos, del sistema y de VMware. El éxito de esta solución alternativa depende en gran medida del estado de la base de datos en el momento del respaldo. Si la base de datos SQL tenía mucha actividad o cambios, es posible que los datos esperados no estén disponibles en la recuperación. Si la base de datos de SQL estaba casi inactiva, el siguiente proceso puede funcionar por completo. 

Requisitos previos:

  • El saveset necesario para la restauración debe ser un saveset de base de datos, no un txnlog copia de seguridad. Esto se puede identificar mediante NetWorker Server mminfo el comando:
mminfo -avot -q vmname=SQL_VM-NAME

Ejemplo:

[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

La variable full backup es un respaldo completo de la base de datos, incluido el disco de máquina virtual (VMDK). La variable txnlog El respaldo solo contiene los registros de transacciones y no incluye las bases de datos.

Recuperación de datos:

Después de realizar los pasos de requisitos previos, el disco de la VM que contiene los datos de SQL se debe montar en la VM de SQL con una letra de unidad aleatoria. Siga los siguientes pasos:

  1. Copie la base de datos de SQL .mdf y .ldf archivos del disco conectado a otra ubicación en la máquina virtual. Por ejemplo, las siguientes bases de datos se encuentran en el disco conectado:
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
...
Los archivos se copian en una carpeta creada por el usuario C:\tmp\RecoveredSQLdata:
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
  1. Asegúrese de que los archivos y las carpetas no sean de "Solo lectura". Haga clic con el botón secundario en la ruta de la carpeta a los datos y asegúrese de que la opción "Solo lectura" no esté seleccionada. Los archivos tampoco deben tener seleccionada la opción "Solo lectura":
    El atributo de solo lectura no está seleccionado en los archivos de base de datos 
  2. Inicie sesión en SQL Server Management Studio (SSMS) con una cuenta de usuario administrativa.
  3. Haga clic con el botón secundario en Databases y, a continuación, haga clic en Attach.
  4. En la ventana Databases to attachment , haga clic en Add. Navegue hasta la ubicación en .mdf archivo se copió en y selecciónelo.
  5. Si SQL Server contiene una base de datos con el mismo nombre que la base de datos original, debe cambiar el nombre de la base de datos que está importando. Seleccione el campo Conectar como y cambie el nombre de la base de datos, por ejemplo, agregar _OLD.

Importación de una base de datos SQL como una base de datos nueva

  1. Haga clic en OK, la base de datos se importará a SQL Server Management Studio.
    PRECAUCIÓN: El administrador del sistema o de la base de datos debe resolver los permisos o errores de importación basados en el sistema operativo.

    En este ejemplo, la base de datos original NetWorkerSupport existe y se importa la copia de respaldo "NetWorkerSupport_OLD".

Se importa la base de datos

La tabla de la base de datos contiene contenido de la base de datos original en el momento del respaldo:

Base de datos SQL recuperada

Los datos de SQL se recuperan en el sistema y el administrador de bases de datos de SQL los puede administrar. Una vez que se recuperan los datos y no se requieren más datos de los medios de respaldo, el disco se puede desconectar de VMware. El almacén de datos NFS temporal también se puede desconectar de VMware y la exportación NFS en Data Domain se puede eliminar. Estos pasos de limpieza se detallan en la sección Limpieza después de las operaciones de restauración de:  NetWorker: Montaje manual del disco del saveset de la VM de Windows para el proceso FLR sin el dispositivo vProxy

Productos afectados

NetWorker

Productos

NetWorker Family
Propiedades del artículo
Número del artículo: 000450321
Tipo de artículo: Solution
Última modificación: 29 abr 2026
Versión:  2
Encuentre respuestas a sus preguntas de otros usuarios de Dell
Servicios de soporte
Compruebe si el dispositivo está cubierto por los servicios de soporte.