NVP-vProxy: Der Data-Protection-Wiederherstellungsclient listet keine SQL-VM-Backups auf

• Der Zugriff auf den Data Protection Restore Client (DPRC) erfolgt über einen Webbrowser: https://NetWorker_Server_Address:9090/flr
• Die Optionen Admin und App sind ausgewählt und der Nutzer wird erfolgreich authentifiziert.
• Das Quell-vCenter und ein Zeitbereich werden angegeben, die SQL-VM ist ausgewählt, aber es werden keine Backups angezeigt:
   
• Die Umgebung besteht aus mehreren vCenter Servern. Die zur Wiederherstellung ausgewählte SQL-VM wurde in das neue vCenter kopiert (oder repliziert). Die VM ist (oder war) in beiden vCenter-Umgebungen vorhanden. Die verwendete Replikationsmethode war extern für NetWorker.

Die VM wurde mithilfe einer Methode repliziert, die zu einer "kopierten" VMware-UUID (Universally Unique Identifier) führte. Die NetWorker-Mediendatenbank listet dieselbe UUID unter zwei verschiedenen vCentern auf. Zum Beispiel:

[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

Der DPRC verwendet die REST API, um eine Verbindung zum NetWorker-Server herzustellen und Backups aufzulisten. Es verwendet eine globale REST API GET-Anforderung, um die VM mithilfe von global/vmware/vms?q=Uuid:UUIDherunter. Folgendes ist zu sehen in der flr-server.logherunter.

• Linux: /nsr/authc/logs/flr-server.log
• Windows (Standardeinstellung): 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 ist nicht in der Lage, die Backups zu präsentieren, da der Konflikt aufgrund der eindeutigen Kennung in mehreren vCentern auftritt. Derselbe REST API-Aufruf gibt beide vCenter:
Linux zurück:

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

Beispiel:

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

Hierbei handelt es sich nicht um erwartetes Verhalten. Die inhärente Erwartung an eine UUID ist, dass sie einzigartig ist. Bei der Abfrage einer VM-UUID werden nur die Ergebnisse für eine VM in einem vCenter erwartet.

Aufgrund des UUID-Konflikts in VMware-Umgebungen ist es nicht möglich, die Daten aus DPRC wiederherzustellen. Eine Problemumgehung finden Sie im Abschnitt Zusätzliche Informationen .

Mit den folgenden Schritten kann die doppelte UUID korrigiert werden. Dadurch werden die vorhandenen Backupdaten jedoch nicht wiederherstellbar. Die folgende Änderung ist eine Korrekturmaßnahme für Backups, die nach der Änderung und danach durchgeführt werden. Sobald die Backups mit der doppelten UUID von NetWorker abgelaufen sind, findet die Recovery-Benutzeroberfläche die VM-Backups korrekt anhand ihrer Universally Unique ID (UUID).

1. Entfernen Sie die doppelte VM aus allen NetWorker-Schutzgruppen, in denen sie derzeit gesichert ist.
2. Leistung der neuen VM in VMware.
3. Heben Sie die Registrierung der VM im vCenter-Bestand auf (wählen Sie "Aus dem Bestand entfernen"). Löschen Sie die VM nicht.
4. Registrieren Sie die VM erneut: Durchsuchen Sie den Datenspeicher und klicken Sie mit der rechten Maustaste auf .vmx und wählen Sie "VM registrieren" aus.
5. Schalten Sie die VM ein. Wenn Sie von vCenter dazu aufgefordert werden, wählen Sie "Ich habe es kopiert". Dies zwingt vSphere dazu, ein brandneues, eindeutiges BIOS und eine Instanz-UUID zu erzeugen.
6. Fügen Sie die virtuelle Maschine (VM) wieder zu den Schutzgruppen hinzu, aus denen sie in Schritt 1 entfernt wurde.

Informationen zu den Auswirkungen einer doppelten UUID finden Sie in der folgenden VMware-Dokumentation: Ändern oder Beibehalten einer UUID für eine verschobene virtuelle Maschine 

Voraussetzung:

• Das für die Wiederherstellung erforderliche Saveset muss ein Datenbank-Saveset sein, kein txnlog Sicherung. Dies kann mithilfe des NetWorker-Servers identifiziert werden mminfo -Befehl überprüfen, ob sie ausgeführt werden:

mminfo -avot -q vmname=SQL_VM-NAME

Beispiel:

[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

Bei der full Ein Backup ist ein vollständiges Datenbankbackup einschließlich der Virtual Machine Disk (VMDK). Bei der txnlog Das Backup enthält nur die Transaktionsprotokolle und nicht die Datenbanken.

• Das VM-Backup muss sich auf einer Data Domain befinden. Wenn es sich um einen anderen Medientyp (Band, CloudBoost, AFTD) handelt, klonen Sie das Backup von Band auf eine Data Domain, auf die vCenter zugreifen kann: NVP-vProxy: Manuelles Klonen eines VM-Saveset von einem Nicht-Data Domain-Gerät auf ein Data Domain-Clone-Gerät
• Der Prozess zum Erstellen des NFS-Exports und zum Mounten auf VMware und der Ziel-VM ist im folgenden Artikel dokumentiert: NetWorker: Manuelles Mounten einer Windows-VM-Saveset-Festplatte für den FLR-Prozess ohne vProxy-Appliance

Datenwiederherstellung:

Nachdem die erforderlichen Schritte ausgeführt wurden, sollte die VM-Festplatte mit den SQL-Daten mit einem zufälligen Laufwerksbuchstaben auf der SQL-VM bereitgestellt werden. Führen Sie folgende Schritte aus:

1. Kopieren der SQL-Datenbank .mdf und .ldf Dateien von der angeschlossenen Festplatte an einen anderen Speicherort auf der VM verschieben. Auf der angeschlossenen Festplatte befinden sich beispielsweise die folgenden Datenbanken:

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. Stellen Sie sicher, dass die Dateien und Ordner nicht schreibgeschützt sind. Klicken Sie mit der rechten Maustaste auf den Ordnerpfad zu den Daten und stellen Sie sicher, dass "Schreibgeschützt" nicht aktiviert ist. Für die Dateien darf außerdem nicht "Schreibgeschützt" ausgewählt sein:
    
3. Melden Sie sich bei SQL Server Management Studio (SSMS) mit einem Administratornutzerkonto an.
4. Klicken Sie mit der rechten Maustaste auf Datenbanken und klicken Sie dann auf Anfügen.
5. Klicken Sie im Fenster Anzuhängende Datenbanken auf Hinzufügen. Navigieren Sie zu dem Speicherort, an dem sich die .mdf Die Datei wurde kopiert und wählen Sie sie aus.
6. Wenn der SQL-Server eine Datenbank mit demselben Namen wie die ursprüngliche Datenbank enthält, müssen Sie die zu importierende Datenbank umbenennen. Wählen Sie das Feld Anfügen als aus und benennen Sie die Datenbank um, z. B. add _OLDherunter.

7. Klicken Sie auf OK, um die Datenbank in SQL Server Management Studio zu importieren.
   WARNUNG: Alle Berechtigungen oder betriebssystembasierten Importfehler müssen vom System- oder Datenbankadministrator behoben werden.
   
   In diesem Beispiel ist die ursprüngliche Datenbank NetWorkerSupport vorhanden und die Sicherungskopie "NetWorkerSupport_OLD" wird importiert.

Die Datenbanktabelle enthält Inhalte aus der ursprünglichen Datenbank zum Zeitpunkt des Backups:

Die SQL-Daten werden im System wiederhergestellt und können vom SQL-Datenbankadministrator verwaltet werden. Sobald die Daten wiederhergestellt sind und keine weiteren Daten vom Backupmedium erforderlich sind, kann die Festplatte von VMware getrennt werden. Der temporäre NFS-Datenspeicher kann auch von VMware getrennt werden und der NFS-Export auf der Data Domain kann entfernt werden. Diese Bereinigungsschritte werden im Abschnitt Bereinigung nach Wiederherstellungsvorgängen aufgeführt unter:  NetWorker: Manuelles Mounten einer Windows-VM-Saveset-Festplatte für den FLR-Prozess ohne vProxy-Appliance