NVP - vProxy: O client de restauração do Data Protection não lista backups de VMs SQL
Summary: O vProxy do NetWorker VMware Protection (NVP) é usado para fazer backup de máquinas virtuais (VM) Microsoft SQL. O ambiente consiste em vários ambientes vCenter, e a VM do SQL foi copiada para outro vCenter fora das práticas do NetWorker. As restaurações de VM do SQL são realizadas a partir do DPRC (Data Protection Restore Client). O assistente DPRC não mostra backups SQL para uma VM, nenhum erro é retornado. ...
Symptoms
- O Data Protection Restore Client (DPRC) é acessado de um navegador da Web:
https://NetWorker_Server_Address:9090/flr - As opções Admin e App são selecionadas e o usuário é autenticado com sucesso.
- O vCenter de origem e um intervalo de tempo são especificados, a VM do SQL é selecionada, mas nenhum backup é exibido:
- O ambiente consiste em vários servidores vCenter. A VM SQL selecionada para restauração foi copiada (ou replicada) para o novo vCenter. A VM existe (ou existiu) nos dois ambientes vCenter. O método de replicação usado foi externo ao NetWorker.
Cause
A VM foi replicada usando um método que resultou em um UUID (Universally Unique Identifier) do VMware "copiado". O banco de dados de mídia do NetWorker lista o mesmo UUID em dois vCenters diferentes. Por exemplo:
[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
O DPRC usa a API REST para se conectar ao servidor do NetWorker e listar backups. Ele usa uma solicitação global REST API GET para localizar a VM usando global/vmware/vms?q=Uuid:UUID. O seguinte é visto no flr-server.log.
- Linux:
/nsr/authc/logs/flr-server.log - Windows (padrão):
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]
O DPRC não consegue apresentar os backups porque o conflito aparece devido ao identificador exclusivo que aparece em vários vCenters. A mesma chamada da API REST retorna ambos os 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
Exemplo:
[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"
}
]
}
Esse não é um comportamento esperado. A expectativa inerente a um UUID é que ele seja único. Ao consultar o UUID de uma VM, somente os resultados para uma VM em um vCenter são esperados.
Resolution
Não é possível recuperar os dados do DPRC devido ao conflito de UUID em ambientes VMware. Consulte a seção Informações adicionais para obter uma solução temporária.
As etapas a seguir podem corrigir o UUID duplicado; No entanto, isso não torna os dados de backup existentes recuperáveis. Essa alteração abaixo é uma ação corretiva para backups realizados após a alteração e assim em diante. Depois que os backups que usam o UUID duplicado expirarem do NetWorker, a interface do usuário de recuperação localizará corretamente os backups da VM usando seu ID exclusivo universal (UUID).
- Para a VM duplicada, remova-a de todos os grupos de proteção do NetWorker em que ela está atualmente submetida a backup.
- A potência da nova VM no VMware.
- Cancele o registro da VM no inventário do vCenter (selecione "Remover do inventário"). Não exclua a VM.
- Registre novamente a VM: Navegue pelo datastore, clique com o botão direito na
.vmxe selecione "Register VM". - Ligue a VM. Quando solicitado pelo vCenter, selecione "I copied it". Isso força o vSphere a gerar um UUID de instância e BIOS totalmente novos, exclusivos.
- Adicione a máquina virtual (VM) de volta aos grupos de proteção dos quais ela foi removida na etapa 1.
Consulte a seguinte documentação da VMware sobre os impactos de UUID duplicado: Como alterar ou manter um UUID de uma máquina virtual movida
Additional Information
.mdf e .ldf arquivos são copiados do disco para outro local na VM e importados para o SQL Server Management Studio (SSMS).
Pré-requisitos:
- O saveset necessário para restauração deve ser um saveset de banco de dados, não um
txnlogBackup. Isso pode ser identificado usando o servidor do NetWorkermminfocomando:
mminfo -avot -q vmname=SQL_VM-NAME
Exemplo:
[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
A coluna full backup é um backup completo do banco de dados, incluindo o disco de máquina virtual (VMDK). A coluna txnlog O backup contém apenas os registros de transações e não inclui os bancos de dados.
- O backup da VM deve residir em um Data Domain, se estiver em outro tipo de mídia (fita, CloudBoost, AFTD), clone o backup de fita para um Data Domain que seja acessível ao vCenter: NVP vProxy: Como clonar manualmente um saveset de VM de um dispositivo que não seja do Data Domain para um dispositivo clone do Data Domain
- O processo para criar a exportação NFS e montá-la no VMware e na VM de destino está documentado no seguinte artigo: NetWorker: Montagem manual do disco de saveset da VM do Windows para o processo de FLR sem o equipamento vProxy
Recuperação de dados:
Depois de executar as etapas de pré-requisito, o disco da VM que contém os dados SQL deve ser montado na VM SQL com uma letra de unidade aleatória. Execute as seguintes etapas:
- Copiar o banco de dados SQL
.mdfe.ldfarquivos do disco conectado para outro local na VM. Por exemplo, os seguintes bancos de dados são encontrados no 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
...
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
- Certifique-se de que os arquivos e as pastas não sejam "Somente leitura". Clique com o botão direito do mouse no caminho da pasta para os dados e verifique se "Somente leitura" não está marcado. Os arquivos também não devem ter a opção "Somente leitura" selecionada:
- Faça log-in no SQL Server Management Studio (SSMS) com uma conta de usuário administrativo.
- Clique com o botão direito do mouse em Bancos de dados e, em seguida, clique em Anexar.
- Na janela Bancos de dados a serem anexados , clique em Adicionar. Navegue até o local do
.mdfarquivo foi copiado para e selecione-o. - Se o SQL Server contiver um banco de dados com o mesmo nome do banco de dados original, você deverá renomear o banco de dados que está importando. Selecione o campo Attach As e renomeie o banco de dados, por exemplo, add
_OLD.

- Clique em OK, o banco de dados é importado para o SQL Server Management Studio.
ADVERTÊNCIA: Quaisquer permissões ou erros de importação baseados em sistema operacional devem ser resolvidos pelo administrador do sistema ou do banco de dados.
Neste exemplo, existe o banco de dados original NetWorkerSupport e a cópia de backup "NetWorkerSupport_OLD" é importada.

A tabela de banco de dados contém conteúdo do banco de dados original no momento do backup:

Os dados SQL são recuperados no sistema e podem ser gerenciados pelo administrador do banco de dados SQL. Depois que os dados forem recuperados e nenhum dado adicional for necessário da mídia de backup, o disco poderá ser desconectado do VMware. O datastore NFS temporário também pode ser desconectado do VMware, e a exportação NFS no Data Domain pode ser removida. Essas etapas de limpeza são detalhadas na seção Cleaning Up After Restore Operations de: NetWorker: Montagem manual do disco de saveset da VM do Windows para o processo de FLR sem o equipamento vProxy