Відновлення NMM 19.9.0.5.Build.227 SQL VDI не вдається відновити з помилкою 'Не вдалося знайти об'єкти страйпу для '/dbname'

Відновлення NMM 19.9.0.5.Build.227 SQL VDI не вдається відновити з помилкою:
'No stripe objects could be located for '/dbname' (pid=9308,11-07-2025 15:31:14) D:/views/nw/19.9/nsr/db_apps/bsmsql/rplan.c(1555): Stripe /C1-db02~1 from Stripe Map Missing, Exiting. 151535 11-07-2025 15:31:15 No stripe objects could be located for '/dbname'

- Перегляд і збереження резервних копій SQL VDI встановлено на 4 тижні
- Налаштовуються
лише повні, кумулятивні резервні копії incr і Log- Повне резервне копіювання виконується в день, а потім Cumulative inc протягом наступних кількох днів
- Виконується спроба відновлення з кумулятивної резервної копії incr, протягом якої залежна повна резервна копія пройшла свій період перегляду та зберігання.
- Набори збережень для повного резервного копіювання все ще доступні для перегляду через залежність від кумулятивних резервних
копій incr - Деякі з кумулятивних резервних копій incr між ними перетнули свої періоди

перегляду та зберігання Вихід mminfo для частково простроченої кумулятивної резервної копії incr виглядає так:
Backup1107.001        Data Domain    win19-sql19-c1 4218476226       1 MSSQL:C1-db02~2          11-07-2025 14:47:52     1752225472 cr      11-07-2025 14:57:51      11-08-2025 23:59:59
Backup1107.001        Data Domain    win19-sql19-c1 4201699010       1 MSSQL:C1-db02~1          11-07-2025 14:47:53     1752225473 cr      11-07-2025 14:57:51      11-08-2025 23:59:59
Backup1107.001        Data Domain    win19-sql19-c1 4184921798       1 MSSQL:C1-db02            11-07-2025 14:47:58     1752225478 cb      11-07-2025 14:57:45      11-08-2025 23:59:59
Backup1107.001        Data Domain    win19-sql19-c1 4168144583       1 MSSQL:                   11-07-2025 14:47:59     1752225479 cb      11-07-2025 14:57:45      11-08-2025 23:59:59

Два батьківські набори збереження мають прапорець cb, тоді як два дочірніх набори збережень мають cr (записи індексу для цих наборів збереження були очищені.

Відповідно до дизайну NMM SQL, для відновлення було вибрано кумулятивне інкрементне резервне копіювання (з/без смужок).  NMM перебирає індекси, зчитуючи інформацію про об'єкти аж до останнього повного резервного копіювання.  
Не існує окремого зв'язку між кумулятивним інкрементним резервним копіюванням і останнім повним резервним копіюванням. 

Як тільки повна резервна копія буде знайдена, NMM проігнорує кумулятивні інкрементальні/журнальні резервні копії між ними та відновить лише вибрану сукупну інкрементну резервну копію та останню повну резервну копію. 
У цьому конкретному випадку він не зміг знайти індекси для кумулятивного інкрементного резервного копіювання (дочірні набори збережень), що призвело до збою відновлення.

Спосіб вирішення: для аналогічного сценарію слід видалити записи mminfo для частково простроченої кумулятивної резервної копії incr за допомогою команди:

nsrmm -d -P -S 1933473985

Потім у клієнтському вузлі SQL Server, меню «Пуск» Windows -> EMC Networker -> плагін NMM SQL -> вкладка «Відновлення бази даних» -> «Відновлення вікон» -> «Переконайтеся , що запис у базі даних (3 червня) відсутній». Виберіть незакінчений Cumulative incremental та виконайте відновлення БД.