Случай из практики: два страйпа в одном (часть 2)

Это продолжение предыдущей статьи об одном интересном случае из практики. Мы дважды пытались определить конфигурацию массива, но оба раза оказались не успешными:

  • сначала определили и собрали RAID-0 с блоком 512, но в этой конфигурации сразу наткнулись на проблемы с таблицей MFT;
  • затем определили и собрали RAID-0 c блоком 128, таблица MFT собралась успешно, но большие файлы не открывались.

В этой части мы разберемся, что случилось с массивом и что можно сделать, чтобы восстановить с него данные.

Определяем конфигурацию еще раз: метод большой таблицы и определение на основе файлов

Метод большой таблицы мы придумали еще когда не было надежного способа определить размер блока. Суть в том, чтобы использовать минимальный размер блока, а параметры таблицы установить так, чтобы она подошла и для наибольшего размера блока. Иногда этот метод помогает разобраться и в других сложных случаях.

Делаем предположение, что истинный размер блока находится между 128 и 512 секторами. 512/128 = 4, т.е. нам нужна таблица в 4 раза больше стандартной: 4 строки вместо одной и 12 блоков данных вместо 3х. В эту таблицу поместятся сразу несколько вариантов массива:

  • RAID 0 с блоком 128 секторов — будет выглядеть как простое продолжение закона следования блоков из 0й строки на 1ю, 2ю и 3ю строки
  • RAID 0 с блоком 512 секторов — в этом случае номера будут нарастать сверху-вниз пока маленькие блоки (128) не покроют собой один большой (512)
  • RAID 0 с блоком 256 секторов — промежуточные вариант, тут и нарастание сверху-вниз и повторение закона

Нет смысла пытаться определить конфигурацию, с помощью записей MFT — получим тот же страйп с блоком 128. Надо выбрать что-то другое. Хороший вариант — пользовательские данные.

Я выбрал один из архивов и попытался заполнить таблицу с его помощью.

Где-то на середине определения конфигурации. Первый столбец ясно говорит о размере блока 4*128 = 512 секторов.

Чем дальше, тем более очевидным становился тот факт, что правильная конфигурация — это RAID-0 с блоком 512 секторов.

Полностью заполненная таблица

После заполнения всей таблицы файл открылся.

Большой zip-архив открылся и был успешно проверен архиватором.

Что же произошло?

Самое время остановиться и поразмыслить.

Пользовательские данные указывают на конфигурацию с размером блока 512 секторов. А метаданные (таблица MFT) — на конфигурацию с размером блока 128. Как такое могло случиться? Похоже, что виной всему CheckDisk, а хронология событий могла быть примерно такой:

  1. изначально был массив с размером блока 512;
  2. с одним из участников возникли проблемы и массив развалился;
  3. массив принудительно собрали с новым размером блока 128;
  4. в новом рейде по случайности основные структуры оказались на месте: MBR, GPT, Boot NTFS и его копия, MFT 0 и операционная система не сломалась где-то в начале, а “подхватила” файловую систему NTFS;
  5. драйвер NTFS быстро обнаружил, что многие записи находятся не на своем месте и предложил все “починить” — запустить CheckDisk;
  6. в результате под новый размер блока была перестроена вся таблица MFT, а данные остались на своих прежних местах.

Схематичное представление того, что произошло с массивом. Из-за того, что был собран новый массив, записи MFT были разделены и перемешаны.

Проверяем предположение

Это всего лишь предположение и его надо проверить:

  • открываем форму создания нового RAID и устанавливаем все параметры для конфигурации с блоком 128 секторов;
  • выполняем сканирование таблицы MFT, чтобы получить неприкосновенный снимок файловой системы;
  • меняем размер блока на 512;
  • в полученной виртуальной файловой системе ищем большие файлы и проверяем, открываются они или нет.

Проверка прошла успешно.

Теперь понятно, почему режим статистики показал размер блока 512 — данные пользователя хранятся именно так. Практика показала, что этот режим — один из самых надежных способов определения параметров и любые аномалии в нем должны иметь объяснение.

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

  • после перестроения некоторые записи по краям цепочек могли оказаться вне таблицы MFT. А это может означать потерю нескольких файлов;
  • и в целом, мы рекомендуем всегда сохранять данные из “обычного” проводника, т.к. на этой форме слишком легко что-то поменять, что нарушит всю трансляцию.

Берем от каждой конфигурации лучшее!

Для решения этой задачи воспользуемся методами формирования карты MFT из чернового восстановления и ее загрузки в существующую файловую систему.

Приступим:

  1. на массиве с блоком 128 секторов строим карту таблицы MFT, сохраняем ее в файл
  2. открываем эту карту на массиве с блоком 512 секторов и немного “расширяем” цепочки: отнимаем пару тысяч от начала и добавляем пару тысяч секторов к концу каждой цепочки
  3. запускаем на ней черновое восстановление
  4. строим карту таблицы MFT и сохраняем ее в файл
  5. этот файл загружаем в файловую систему на RAID 0 c блоком 512
  6. выполняем сканирование MFT, т.к. могли остаться “оторванные” от основного дерева каталоги и файлы
  7. готово! на массиве с блоком 512 мы получили файловую систему как на массиве с блоком 128 — метаданные и данные теперь согласованы

Конечно же мы не отмотаем назад все, что было изменено CheckDisk’ом и полученный результат — это не то, что было до поломки. Но для данного примера — это, возможно, наилучший вариант.

 

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (2 голосов, средний: 5,00)
Загрузка...

Об авторе Александр Леоненко

Разработчик Data Extractor и Data Extractor RAID Edition
Запись опубликована в рубрике Data Extractor RAID Edition с метками , , , , , . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *