Проблема з відновленням логічного диска (Work) з образів RAID 0 (2xSSD, Intel Z77) в UFS Explorer

[Eski_62]

Вітаю товариство!
Потрібна порада досвідчених спеціалістів або тих, хто стикався зі збоями інтегрованих Intel RAID-контролерів.Історія та конфігурація масиву:
Дата створення: 2013 рік.Конфігурація: RAID 0 з двох однакових SSD-дисків.Материнська плата / Контролер: ASUS P8Z77-M PRO (чіпсет Intel Z77, Intel Rapid Storage Technology).
ОС: Windows 7.
Структура: Масив був поділений на 2 логічних диски: System та Work.Збій: У 2019 році RAID «розвалився» через фізичні проблеми з підключенням (кабелі/живлення). Самі диски фізично не затиралися.
Що було зроблено зараз:За допомогою FTK Imager знято повні побітові образи обох SSD. Помилок читання немає: результат no bad blocks found in image.Образи завантажено в UFS Explorer Professional Recovery для збору віртуального RAID-масиву.
Успіх із першим диском: При ручному зборі віртуального масиву та встановленні розміру стрипу (сектора/блоку) в 32 КБ, перший логічний диск (System) змонтувався ідеально. Файли (як дрібні системні, так і велике відео на 1.4 ГБ) відновлюються цілими й відкриваються без пошкоджень.
Суть проблеми:Другий логічний диск (Work) копіюється та відновлюється з помилками, файли «биті» або не відкриваються. Програма показує хаос у структурі (як на доданому скриншоті — безліч дрібних NTFS розділів замість одного цілісного простору диску Work).Оскільки диск System збирався з тим самим розміром блоку (32 КБ) і на тих самих фізичних накопичувачах, геометрія початку масиву правильна. Але далі, очевидно, збивається зміщення (offset) або порядок дисків для другої логічної зони.
Запитання до знавців:Чому за однакового розміру стрипу (32 КБ) перший логічний диск зчитався чудово, а на другому починається сегментація на дрібні NTFS "шматки"?
Чи може утиліта Intel RST у 2013 році створювати логічні диски з різним розміром блоку на одному масиві, або з якимось специфічним зміщенням для другого розділу?
Як правильно розрахувати або знайти зміщення (Offset) для старту другого логічного диска (Work)?На які параметри/заголовки (MFT, копія Boot-сектора в кінці диску) варто звернути увагу в UFS Explorer, щоб скоригувати віртуальну збірку саме під другий розділ?

Дякую заздалагіть.

[Alexsandr]

Пишуть що Стрип задається для всього масиву на рівні контролера, але Intel Matrix RAID дозволяє на одній парі фізичних дисків створити, два незалежні RAID-об'єми і для другого міг бути інший розмір стрипу.
Ну сам контроллер міг плутати змінити місцями диски.
можливо простіше подивитись пошуком що дам с диском, де початок.

[Eski_62]

Дякую.
А шо, чім і як дивитися.

[Eski_62]

Дякую, це дуже влучна підказка про Intel Matrix RAID! Я не знав, як саме було налаштовувано масив у 2013 році — цілком можливо, що це були два окремі RAID-об'єми з різними розмірами стрипу (наприклад, 32 КБ для системи та 64/128 КБ для Work під великі файли).
Згоден, що зараз найпростіше — це зробити пошук вручну і подивитися, що там коїться всередині.

Підкажіть, будь ласка, алгоритм для UFS Explorer:
Як мені правильно знайти фізичний початок (Offset) другого логічного диска?
Шукати сигнатуру NTFS (заголовок бут-сектора розділу NTFS) за допомогою Hex-пошуку?
Якщо я знайду цей початок, як визначити, чи не переплутав контролер диски місцями (диск 1 і диск 2) саме для цього другого об'єму?
Чи є в заголовок секторів якийсь маркер, який це підкаже?

[11motor]

Дякую, це дуже влучна підказка про Intel Matrix RAID! Я не знав, як саме було налаштовувано масив у 2013 році — цілком можливо, що це були два окремі RAID-об'єми з різними розмірами стрипу (наприклад, 32 КБ для системи та 64/128 КБ для Work під великі файли).

Можливо другий диск у Вас створений на базі raid 1 (Intel Matrix RAID це дозволяє)

[Eski_62]

Дякую!
робили для прискорення пряцювання 3ds Max рендеру, техничних подробіць не знаю

Відправлено через 40 хвилин 27 секунд:

це 32 кб

Відправлено через 32 хвилини 42 секунди:

Знайдений розділ Work відкрив структуру папок та назви файлів, але самі файли відновлюються "битими". Великі зображення JPEG відкриваються лише на кілька відсотків зверху (як на скриншоті), а далі йде порожнеча.Це остаточно доводить, що розмір страйпу 32 КБ для розділу Work є неправильним, хоча для диска System він підійшов ідеально. Другий RAID-об'єм Intel Matrix дійсно був створений з іншим розміром блоку.Оскільки початок розділу (сектор 322138240) нам тепер достеменно відомий, підкажіть, як вчинити правильно:Перезібрати в конструкторі UFS Explorer віртуальний RAID, змінивши розмір блока на 64 КБ чи 128 КБ? Але якщо я зміню блок для всього масиву, чи не зміститься фізичний початок диска Work, який ми щойно знайшли?Чи можна в UFS Explorer задати різні розміри страйпу для різних зон (LBA) одного масиву, або ж потрібно вручную вираховувати новий Offset початку диска Work під блок 64/128 КБ?

[11motor]

Eski_62
Якій обʼєм у SSD? 120ГБ, 128ГБ?
У Вас же образи дисків, дані с першого логічного Ви вже зберегли. Можна спокійно експериментувати з розміром блока

[Eski_62]

128 ГБ

Відправлено через 1 хвилину 30 секунд:
Дякую!
Бажано алгорітм дій

[tornadox]

Не пробували читати дані через лінуксові утиліти? Вони добре вміють працювати з Intel Fake Raid.

[Eski_62]

Дякую за пораду щодо Linux-утиліт! Про Intel Fake RAID та утиліту mdadm / dmraid я теж думав.
Якими командами в терміналі мені правильно змонтувати мої два побітові образи .bin з жорсткого диска D: як віртуальні петльові пристрої (losetup), щоб утиліта mdadm побачила їх як фізичні SSD і сама активувала Fake RAID масив?

[Shpoker]

Якими командами в терміналі мені правильно змонтувати мої два побітові образи .bin

losetup -fP 1.bin
losetup -fP 2.bin
...
losetup -fP X.bin

на сколько я помню, должно получиться 2 луп девайса
потом для каждого mdadm --examine /dev/loopX (ну или партишны, уже не помню)

и если оно живое - то тогда собрать mdadm --assemble /dev/mdX /dev/loop0 /dev/loop1... /dev/loopX (ну или партишны, уже не помню)

есть нюанс, если мдадм захочет что-то поправить - то обгадится ибо рид-онли девайсы. я б раскатал образы на свободные диски и потом уже попробовал с ними играться
и да, мдадм вряд-ли автоматом соберет интеловский фейкрейд и прийдется руками указывать всякие там рейдлевелы, чанки и маркать что оно живое
и еще, помоему, мдадму важен порядок дисков, потому это тоже может быть проблемой, особенно если параметры массива не известны точно

[Eski_62]

дякую

[Eski_62]

поки так по пошуку початку

[Eski_62]

Уточнення для експертів щодо чорних смуг на диску Work (Volume 2).
Оскільки сбой стався "на холодну" (просто відійшло живлення одного SSD), дані фізично цілі.
Каша та чорні діри у файлах — це 100% помилка кроку зшивання.
Простий перебір страйпів (32, 64 КБ) результату не дав.
Очевидно, ми вперлися в логіку чергування Intel Matrix RAID.
Оскільки Boot-сектори ми знайшли на різних LBA (206848 для 002.bin та 21832 для 001.bin), початок файлів зшивається рівно.
Але далі блоки розсинхронізуються.

Підкажіть, будь ласка:

Чи практикує Intel RST внутрішній Stripe Block Offset (зсув чергування на 1 або більше блоків вперед/назад на одному з дисків) для другого логічного об'єму?

Як у конструкторі UFS Explorer прописати цей зсув блоків чергування, не змінюючи знайдені початкові фізичні сектори дисків?

Чи варто спробувати зібрати цей масив через утиліту DMDE (функція "Конструктор RAID"), оскільки ми вже маємо з неї всі початкові логи, і подивитися, чи не впорається її алгоритм із чергуванням блоків Intel краще?

[Alexsandr]

Пишуть що кожен том створюється як окремий "контейнер" з фіксованим розміром страйпу, але фізичні дані для обох томів лежать послідовно. Жоден том не має індивідуального зсуву блоків.
На рівні ОС Intel RST вимагає лише вирівнювання розділів.

Оскільки на межі між дисками System і Work виник асинхронний зсув (один диск "випередив" інший на кілька блоків або один блок виявився забитий сміттям), лінійний збір віртуального RAID продовжує читати диски у старому порядку. Але фізично на SSD дані другого розділу тепер зміщені. Типове зміщення 32-64кб, але іноді може бути значно більшим.

В UFS Explorer Professional Recovery є інструмент для роботи зі складними або деградованими масивами. Спробуйте створити масив, де для простору після диска System вводиться штучний зсув (Offset) для одного з дисків.

Можливо спробувати створити окремий віртуальний RAID лише для зони диска Work. Замість старту з 0 сектора, задайте початковий сектор (Start Offset), який відповідає початку диска Work. Якщо структура все одно бита, змініти Start Offset на одному з SSD-образів вперед або назад на величину, кратну розміру страйпу (наприклад, на +32 КБ, +64 КБ або -32 КБ). Це компенсує той блок, який Intel RST встиг чи не встиг записати в момент відключення живлення (питання скільки встиг). На всякий випадок перевірити інверсію (Порядку дисків)Іноді Intel RST при створенні Matrix RAID (двох томів на одних дисках) для другого логічного тому використовує зворотний порядок дисків.

[Eski_62]

Дякую дуже, вже багато чого робив, поки результата для Work немає, нажаль