NVP-vProxy: Il client di ripristino della protezione dei dati non elenca i backup delle macchine virtuali SQL

Summary: Il vProxy NetWorker VMware Protection (NVP) viene utilizzato per eseguire il backup delle macchine virtuali (VM) Microsoft SQL. L'ambiente è costituito da più ambienti vCenter e la macchina virtuale SQL è stata copiata in un altro vCenter al di fuori delle procedure di NetWorker. I ripristini delle VM SQL vengono eseguiti da Data Protection Restore Client (DPRC). La procedura guidata DPRC non mostra i backup SQL per una VM, non viene restituito alcun errore. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

  • È possibile accedere a Data Protection Restore Client (DPRC) da un web browser: https://NetWorker_Server_Address:9090/flr
  • Le opzioni Amministratore e App sono selezionate e l'utente viene autenticato correttamente.
  • Vengono specificati il vCenter di origine e un intervallo di tempo, viene selezionata la macchina virtuale SQL, ma non vengono visualizzati backup:
    Data Protection Restore Client non visualizza alcun backup 
  • L'ambiente è costituito da più vCenter Server. La VM SQL selezionata per il restore è stata copiata (o replicata) nel nuovo vCenter. La VM esiste (o esisteva) in entrambi gli ambienti vCenter. Il metodo di replica usato era esterno a NetWorker.

Cause

La macchina virtuale è stata replicata utilizzando un metodo che ha generato un identificatore univoco universale (UUID) VMware "copiato". Il database dei supporti NetWorker elenca lo stesso UUID in due vCenter diversi. Ad esempio:

[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

DPRC usa l'API REST per connettersi al server NetWorker ed elencare i backup. Utilizza una richiesta GET dell'API REST globale per trovare la macchina virtuale utilizzando global/vmware/vms?q=Uuid:UUID. Quanto segue è visualizzato nella finestra di dialogo flr-server.log.

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

Il DPRC non è in grado di presentare i backup perché il conflitto si verifica a causa dell'identificatore univoco visualizzato in più vCenter. La stessa chiamata API REST restituisce entrambi 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

Esempio:

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

Non si tratta di un comportamento previsto. L'aspettativa intrinseca di un UUID è che sia univoco. Quando si esegue una query per l'UUID di una macchina virtuale, sono previsti solo i risultati per una macchina virtuale in un vCenter.

NOTA: Questo stesso problema viene osservato quando si tentano operazioni di ripristino a livello di file (FLR) da DRPC.

Resolution

Non è possibile ripristinare i dati da DPRC a causa del conflitto di UUID negli ambienti VMware. Per una soluzione alternativa, vedere la sezione Informazioni aggiuntive .

I seguenti passaggi possono correggere l'UUID duplicato; Tuttavia, ciò non rende ripristinabili i dati di backup esistenti. La modifica riportata di seguito è un'azione correttiva per i backup eseguiti dopo la modifica e in seguito. Una volta scaduti i backup che utilizzano l'UUID duplicato da NetWorker, l'interfaccia utente di ripristino trova correttamente i backup delle VM utilizzando il relativo UUID (Universally Unique ID).

  1. Per la VM duplicata, rimuoverla da qualsiasi gruppo di protezione di NetWorker in cui è attualmente eseguito il backup.
  2. La potenza della nuova VM in VMware.
  3. Annullare la registrazione della VM dall'inventario vCenter (selezionare "Remove from Inventory"). Non eliminare la VM.
  4. Registrare nuovamente la VM: Sfogliare il datastore, cliccare con il pulsante destro del mouse .vmx e selezionare "Register VM".
  5. Accendere la VM. Quando richiesto da vCenter, selezionare "I copied it". Ciò impone a vSphere di generare un nuovo e univoco UUID del BIOS e dell'istanza.
  6. Aggiungere nuovamente la macchina virtuale (VM) ai gruppi di protezione da cui è stata rimossa nel passaggio 1.
NOTA: La VM viene rimossa dal gruppo e aggiunta nuovamente per evitare che l'UUID precedente venga lasciato nell'elenco degli elementi di lavoro dopo la modifica dell'UUID in VMware. Vedere: NVP vProxy: Impossibile trovare l'elemento di lavoro della macchina virtuale selezionato con UUID "UUID" in vCenter, l'elemento di lavoro verrà ignorato.

Consultare la seguente documentazione VMware per informazioni sull'impatto di UUID duplicati: Modifica o mantenimento di un UUID per una macchina virtuale spostata Questo link ipertestuale indirizza a un sito web esterno a Dell Technologies.

 

Additional Information

NOTA: Il seguente approccio può essere utilizzato per ripristinare i dati SQL nella VM senza coinvolgere il server NetWorker, vProxy o DPRC. Questo approccio prevede la creazione di un'esportazione NFS su Data Domain utilizzando la cartella dei set di salvataggio del backup. L'esportazione NFS viene montata come datastore NFS in VMware. Il disco della VM del datastore NFS è collegato a una VM SQL nell'ambiente VMware. SQL .mdf e .ldf i file vengono copiati dal disco in un'altra posizione sulla macchina virtuale e importati in SQL Server Management Studio (SSMS).
AVVERTENZA: Si tratta di una soluzione alternativa ottimale per tentare di ripristinare i dati in una situazione in cui le condizioni dell'ambiente hanno impedito all'interfaccia utente di ripristino di trovare i backup corretti. Il supporto NetWorker fornisce assistenza per elementi come la selezione del percorso del saveset corretto su Data Domain, mentre le attività VMware, OS e SQL vengono gestite tramite i rispettivi amministratori. Queste sono tutte operazioni esterne a NetWorker che devono essere eseguite dagli amministratori VMware, di sistema e di database. Il successo di questa soluzione alternativa dipende fortemente dallo stato del database al momento del backup. Se il database SQL era in condizioni di attività o modifiche elevate, i dati previsti potrebbero non essere disponibili nel ripristino. Se il database SQL era per lo più inattivo, il processo riportato di seguito potrebbe funzionare completamente. 

Prerequisiti:

  • Il saveset richiesto per il ripristino deve essere un saveset del database, non un saveset txnlog Backup. Questo può essere identificato utilizzando il server NetWorker mminfo :
mminfo -avot -q vmname=SQL_VM-NAME

Esempio:

[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 colonna full backup è un backup completo del database, incluso il disco della macchina virtuale (VMDK). La colonna txnlog Il backup contiene solo i registri delle transazioni e non include i database.

Ripristino dei dati:

Dopo aver eseguito i passaggi prerequisiti, è necessario montare il disco della VM contenente i dati SQL sulla VM SQL con una lettera di unità casuale. Attenersi alla seguente procedura:

  1. Copiare il database SQL .mdf e .ldf file dal disco collegato a un'altra posizione sulla macchina virtuale. Ad esempio, nel disco collegato si trovano i seguenti database:
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
...
I file vengono copiati in una cartella creata dall'utente 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. Assicurarsi che i file e le cartelle non siano di "sola lettura". Cliccare con il pulsante destro del mouse sul percorso della cartella corrispondente ai dati e assicurarsi che l'opzione "Read Only" non sia selezionata. Inoltre, per i file non deve essere selezionata l'opzione "Read Only":
    L'attributo Read-only non è selezionato nei file di database 
  2. Accedere a SSMS (SQL Server Management Studio) con un account utente amministrativo.
  3. Cliccare con il pulsante destro del mouse su Databases, quindi cliccare su Attach.
  4. Nella finestra Database da collegare, cliccare su Aggiungi. Accedere alla posizione in .mdf Il file è stato copiato e selezionato.
  5. Se SQL Server contiene un database con lo stesso nome del database originale, è necessario rinominare il database che si sta importando. Selezionare il campo Attach As e rinominare il database, ad esempio add _OLD.

Importazione di un database SQL come nuovo database

  1. Cliccare su OK. Il database verrà importato in SQL Server Management Studio.
    AVVERTENZA: Eventuali errori di importazione basati su autorizzazioni o sistemi operativi devono essere risolti dall'amministratore di sistema o del database.

    In questo esempio, il database originale NetWorkerSupport esiste e viene importata la copia di backup "NetWorkerSupport_OLD".

Il database viene importato

La tabella del database contiene il contenuto del database originale al momento del backup:

Database SQL ripristinato

I dati SQL vengono ripristinati nel sistema e sono gestibili dall'amministratore del database SQL. Una volta ripristinati i dati e non sono richiesti ulteriori dati dal supporto di backup, il disco può essere scollegato da VMware. Il datastore NFS temporaneo può anche essere scollegato da VMware e l'esportazione NFS su Data Domain può essere rimossa. Questi passaggi di pulitura sono descritti in dettaglio nella sezione Pulizia dopo le operazioni di ripristino di:  NetWorker: Mounting manuale del disco del saveset di macchine virtuali Windows per il processo FLR senza appliance vProxy

Affected Products

NetWorker

Products

NetWorker Family
Article Properties
Article Number: 000450321
Article Type: Solution
Last Modified: 29 أبريل 2026
Version:  2
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.