NVP-vProxy: Клієнт відновлення захисту даних не містить резервних копій SQL VM

• Клієнт відновлення захисту даних (DPRC) здійснюється з веб-браузера: https://NetWorker_Server_Address:9090/flr
• Опції Адміністратор та Додаток вибираються, і користувач успішно автентифікує.
• Вказано вихідний vCenter і часовий діапазон, вибрана SQL-віртуальна машина, але резервні копії не відображаються:
   
• Середовище складається з кількох серверів vCenter. SQL-віртуальна машина, обрана для відновлення, була скопійована (або реплікована) на новий vCenter. Віртуальна машина існує (або існувала) в обох середовищах vCenter. Метод реплікації був зовнішнім для NetWorker.

Віртуальна машина була реплікована методом, який призводив до «скопійованого» універсального ідентифікатора VMware Universally Unique Identifier (UUID). База даних NetWorker містить однаковий UUID під двома різними vCenters. Наприклад:

[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 використовує REST API для підключення до сервера NetWorker і списку резервних копій. Він використовує глобальний запит REST API GET, щоб знайти віртуальну машину за допомогою global/vmware/vms?q=Uuid:UUID. Наступне видно у flr-server.log.

• Linux: /nsr/authc/logs/flr-server.log
• Windows (за замовчуванням): 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 не може подавати резервні копії, оскільки конфлікт виникає через унікальний ідентифікатор, який з'являється у кількох vCenter. Той самий виклик REST API повертає обидва vCenter:
Linux:

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

Вікна:

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

Приклад:

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

Це не очікувана поведінка. Притаманне очікування UUID полягає в тому, що він унікальний. Під час запиту для UUID віртуальної машини очікуються лише результати для однієї віртуальної машини в одному vCenter.

Відновити дані з DPRC неможливо через конфлікт UUID у середовищах VMware. Дивіться розділ «Додаткова інформація » для обхідного рішення.

Наступні кроки можуть виправити дубльований UUID; однак це не робить існуючі резервні дані придатними для відновлення. Наведена нижче зміна є коригувальною дією для резервних копій, зроблених після зміни і надалі. Після того, як резервні копії з дублікатом UUID закінчуються з NetWorker, інтерфейс відновлення правильно знаходить резервні копії віртуальної машини, використовуючи їхній універсально унікальний ідентифікатор (UUID).

1. Для дублікатної віртуальної машини видаліть її з будь-яких груп захисту NetWorker, де вона зараз резервна копія.
2. Потужність нової віртуальної машини у VMware.
3. Видаліть віртуальну машину з інвентарю vCenter (виберіть «Видалити з інвентарю»). Не видаляйте віртуальну машину.
4. Перереєструйте віртуальну машину: Переглядайте сховище даних, клацніть правою кнопкою миші .vmx і виберіть «Зареєструвати віртуальну машину».
5. Увімкніть віртуальну машину. Якщо vCenter запитає, виберіть «Я скопіював це». Це змушує vSphere генерувати абсолютно новий, унікальний BIOS та UUID Instance.
6. Додайте віртуальну машину (VM) назад до груп захисту, з яких її було видалено на першому кроці.

Дивіться наступну документацію VMware щодо впливу дублікатів UUID: Зміна або збереження UUID для переміщеної віртуальної машини 

Передумова:

• Набір збережень, необхідний для відновлення, має бути набір збережень бази даних, а не txnlog Підкріплення. Це можна ідентифікувати за допомогою сервера NetWorker mminfo КОМАНДУВАННЯ:

mminfo -avot -q vmname=SQL_VM-NAME

Приклад:

[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 резервне копіювання — це повна резервна копія бази даних, включаючи диск віртуальної машини (VMDK). The txnlog Резервне копіювання містить лише журнали транзакцій і не включає бази даних.

• Резервне копіювання VM має знаходитися в домені даних, якщо воно знаходиться на іншому типі медіа (Tape, CloudBoost, AFTD), клонуйте резервну копію зі стрічки у домен даних, доступний vCenter: NVP vProxy: Як вручну клонувати набір збережень віртуальної машини з пристрою без домену даних на клон домену даних
• Процес створення експорту NFS та його монтування на VMware та цільову віртуальну машину описано в наступній статті: NetWorker: Ручне монтування диска набору збережень Windows VM для процесу FLR без vProxy Appliance

Відновлення даних:

Після виконання попередніх кроків диск VM, що містить SQL-дані, слід змонтувати до SQL-віртуальної машини випадковою літерою диска. Виконайте наступні кроки:

1. Скопіюйте базу даних SQL .mdf та .ldf файлів з підключеного диска до іншого місця на віртуальній машині. Наприклад, на приєднаному диску знаходяться такі бази даних:

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. Переконайтеся, що файли та папки не є «тільки для читання». Клацніть правою кнопкою миші по шляху папки до даних і переконайтеся, що «Тільки для читання» не встановлено. Файли також не повинні мати виділення «Тільки для читання»:
    
3. Увійдіть у SQL Server Management Studio (SSMS) з адміністративним обліковим записом користувача.
4. Клацніть правою кнопкою миші по базах даних, потім натисніть Прикріпити.
5. У вікні «Бази даних для прикріплення » натисніть «Додати». Перейдіть до місця розташування .mdf файл було скопійовано і вибрати його.
6. Якщо SQL-сервер містить базу даних з тією ж назвою, що й оригінальна, потрібно перейменувати базу даних, яку імпортуєте. Виберіть поле Attach As і перейменуйте базу даних, наприклад, додати _OLD.

7. Натисніть OK, база даних імпортується в SQL Server Management Studio.
   УВАГА: Будь-які помилки дозволів або помилки імпорту на основі ОС мають бути вирішені системним або базним адміністратором.
   
   У цьому прикладі існує оригінальна база даних NetWorkerSupport , і імпортована резервна копія "NetWorkerSupport_OLD".

Таблиця бази даних містить вміст оригінальної бази даних на момент резервного копіювання:

SQL-дані відновлюються в систему і керуються адміністратором SQL Database Administrator. Після відновлення даних і подальших даних із резервного носія диск можна від'єднати від VMware. Тимчасове сховище даних NFS також можна відокремити від VMware, а експорт NFS у домені даних можна видалити. Ці кроки очищення детально описані в розділі «Очищення після операцій відновлення »:  NetWorker: Ручне монтування диска набору збережень Windows VM для процесу FLR без vProxy Appliance