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

Я бы хотел рассмотреть один из интересных случаев из практики. Он не является типичным и стандартные подходы к определению конфигурации тут немного “сбоят”, но тем интересней показывать, как они работают.

Я постараюсь описать весь процесс решения достаточно близко к реальному. Т.е. не стану первым делом подмечать нужные признаки и делать сразу правильные выводы, а позволю себе отойти от прямой дороги, что характерно решения сложных задач.

Первая часть будет особенно полезна начинающим пользователям Data Extractor RAID Edition, т.к. затрагивает только базовые приемы самостоятельного определение конфигурации. Я постарался описать процесс достаточно подробно.

Первоначальный анализ массива

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

Анализ статистики участников RAID

Запускаем черновое восстановление на всех дисках и ждем некоторое время.

Запуск чернового восстановления в фоне для всех участников

Затем переходим в режим статистики участника RAID. Первый раз запускаем с параметрами по-умолчанию.

Видно что на каждом диске 6 «пиков» или «волн», а длина одного пика — 512 секторов. Пики начинаются с 0, никакого сдвига нет.

Сразу же видим:

  • размер блока равен 512 секторам
  • начальное смещение должно быть кратно блоку (StartLBA = 512*n, n=0, 1, 2, …).

С уровнем массива и количеством участника ситуация пока неопределенная:

  • либо мы указали неверное количество дисков и/или delay, и поэтому мы не видим характерных гистограмм для RAID-5 или RAID-6
  • либо это один из уровней с блоками данных, но без блоков XOR, RS, HS, например, RAID-0, 10, 1E или что-то еще. Тогда изменение параметров ничего нового не даст.

Быстро перебираем разумные варианты с другим количеством участников (+1, +2) и delay (8, 16, 32).

Статистика для других параметров. Качественно ничего не поменялось, просто видим больше пиков из-за того, что указан больший размер окна выборки.

Ситуация не меняется — “пустые” блоки не появляются. Делаем выбор в пользу второго предположения.

Также отмечаем, что гистограммы на всех 3х дисках похожи — скорей всего все 3 входят (или входили) в массив. Но, помним, что это вовсе не означает, что в массиве ровно 3 участника.

Зафиксируем наши предположения:

  • размер блока 512 секторов
  • начальное смещение = 512*n, n=0, 1, 2, …
  • это RAID-0, 10, RAID-1E или что-то подобное
  • возможно в массиве 3 участника

Это, конечно, наиболее вероятные параметры, а не все теоретически возможные.

Параллельный просмотр участников

Воспользуемся этим режимом, чтобы быстро проверить нет ли среди участников дисков-копий (уровни RAID-10 и RAID-1E Adjacent).

Просматриваем несколько областей около начала, середины и конца дисков. Ненулевые данные отличаются. Похоже что уровни RAID-10 и RAID-1E Adjacent можно исключить из ближайшего рассмотрения.

Данные на участниках не совпадают

Анализ результатов чернового восстановления

Переходим в режим чернового восстановления, чтобы уточнить предположения.

Смотрим на результаты, которые:

  • дают информацию о размере данных массива, они позволят уточнить уровень массива и количестве участников;
  • дают информацию о начальном смещении.

Наилучшим образом нашим интересам удовлетворяют дисковые структуры: MBR, GPT, LVM2 и тд. А также буты и суперблоки файловых систем. Все они содержат информацию о размере и расположены в начале или рядом с началом RAID.

Приступаем к анализу.

MBR и GPT.

Список найденных «дисковых» структур на одно из участников. В поле «комментарий» указана дополнительная информация. Для MBR — это список разделов. Для GPT — MyLBA и Alternative LBA и тоже список разделов.

Из всего списка структур вызывает интерес только пара MBR+GPT, найденная на LBA = 1069056. Из нее мы узнаем размер массива — 58.6 млрд. секторов, что почти равно размеру 3х дисков (размер диска 19.6 млрд.).

Размер массива я определил на основе поля AlternativeLBA — это место, где лежит копия заголовка GPT, а лежит она всегда в конце “диска”, этим диском может быть RAID. В нашем случае, число значительно больше размера одного физического диска, поэтому делаем вывод, что структура относится к массиву.

MBR находится в LBA = 1069056. Начальное смещение должно иметь вид 512*n, проверяем так ли это: 1069056 mod 512 = 0. Этот LBA подходит!

Уточняем предположение:

  • это страйп из 3х дисков;
  • еще подходит редкий RAID-1E Offset из 6 дисков, но тогда получается, что клиент не донес еще 3 диска. Пока что отклоняем это предположение, как слишком необычное.
  • StartLBA = 1069056

Остальные найденные структуры не интересны:

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

BootNTFS

На одном из участников нашелся BootNTFS. В поле «комментарий» указан размер раздела в секторах.

Еще одна подходящая структура.

  • описывает раздел в 58,6 млрд. секторов — почти та же цифра, что и в GPT.
  • лежит по LBA = 1157120. Этот адрес тоже подходит под начало массива (1157120 mod 512 = 0), но больше похоже, что это начало раздела, описанного в GPT.

Другие найденные на диске структуры не несут информации о размере и начале массива. Но нам итак удалось сформировать одно полноценное предположение:

  • RAID-0
  • 3 участника и все 3 у нас на руках
  • блок 512
  • начало 1069056.

Стадию первоначального анализа можно считать завершенной.

Определяем RAID-0 с блоком 512

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

Действуем стандартным образом:

  • добавляем участников и выставляем StartLBA
  • устанавливаем уровень RAID-0, указываем блок = 512
  • чистим таблицу (т.к. она задает порядок дисков, который нам неизвестен).

    1) добавлены все участники 2) установлено стартовое смещение 3) мы собираемся определять RAID-0 и нам нужно настроить таблицу (указать число строк и блоков данных), проще всего это сделать просто выбрав уровень RAID-0 в списке 4) установлен размер блока 5) последний шаг еще не сделан — это очистка таблицы, т.к. ее содержимое нам неизвестно

Определение проходит очень быстро:

  1. 0й блок ставим на основе MBR. Это та самая структура, которую мы использовали в предварительном анализе.

    На роль начала диска (массива) подходит только структура найденная в ячейке A0

  2. 1й блок ставим на основе копии Boot сектора NTFS

    В конце раздела должна быть копия Boot NTFS, она нашлась в ячейке B0

  3. 2й блок устанавливается автоматически

    Для блока №2 остался всего один вариант.

Конфигурация определена! Даже порядок дисков остался прежним. Можно переходить к следующему этапу.

Так выглядит корень файловой системы на собранном массиве.

К слову, возможных вариантов было всего 6, можно было даже перебором воспользоваться.

Проверяем корректность конфигурации

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

Есть несколько способов проверки конфигурации. Если на RAID есть NTFS я всегда проверяю корректность таблицы MFT. Эта область обычно большая (сотни мегабайт), ее легко проверить, она регулярно обновляется и критически важна для файловой системы.

Алгоритм следующий:

  1. строим карту таблицы MFT
  2. оцениваем количество и размер цепочек
  3. запускаем на карте черновое восстановление
  4. проверяем соответствуют ли результаты карте

Проверяем таблицу MFT в нашей задаче:

  • В карте 15 цепочек, из них первые 4 достаточно большие. Т.е. в черновом восстановлении мы тоже должны найти 4 больших региона и несколько маленьких с записями из конца таблицы.

    Построенная карта таблицы MFT

  • Запускаем черновое восстановление и сразу же видим, что результат сильно отличается от того, что мы ожидали получить: вместо больших регионов мы видим множество мелких по 128 секторов, записи идут с пропусками.

    Результат чернового восстановления

Похоже, что мы сделали где-то ошибку и собранная конфигурация не верна.

Возвращаемся к первоначальному анализу

Первое, что приходит на ум — мы ошиблись с размером блока, слишком подозрительно записи разбились на куски по 128 секторов. Посмотрим как размещены записи на участниках RAID.

Возвращаемся к результатам чернового восстановления на участниках массива и явно видим, что размер блока равен 128 секторов, какой участник мы бы не взяли. Похоже, что предположение сделанное на основе статистики — не верно (к этому выводу мы еще вернемся).

Записи MFT, найденные на одном из участников.

Обновляем наше предположение:

  • RAID-0
  • 3 участника и все 3 у нас на руках
  • блок 128
  • начало 1069056.

Определяем RAID-0 с блоком 128

На этом этапе процесс определения конфигурации в точности повторяет тот, что мы делали для блока 512. Так бывает, что после изменения размера блока часть структур транслируется в те же самые места. Этот случай такой.

Проверяем RAID

Кажется, что корень файловой системы открылся лучше. Это хороший знак.

На этот раз в корне оказалось больше каталогов. Каталоги found.000, found.001 и Chkdsk — признаки работы Check Disk.

Подмечаем, что тут есть следы выполнения программы CheckDisk: характерные каталоги found.000, found.001 и Chkdsk

Повторяем проверку таблицы MFT:

  • карта таблицы та же, поэтому к результатам чернового восстановления у нас такие же ожидания

    На новом массиве карта MFT построилась так же как и на старом.

  • на этот раз результаты проверки соответствуют ожиданиям — мы получили 4 больших региона с нужным числом записей и несколько маленьких.

    Записи упорядочены по номерам. Видно, что найденные регионы соответствуют карте таблицы MFT.

Таблица проверена успешно.

Примечание 1. До версии 6.6 DE искусственно разбивал большие регионы на участки по 100000 записей. Поэтому вместо одного региона на 205 тыс. записей появлялись идущие друг за другом регионы: 100 + 100 + 5 тыс. записей.

Примечание 2. Нормальной можно назвать ситуацию, когда в таблице отсутствуют записи с номерами от 16 до 24. А также записи из самого конца таблицы (место было выделено, но еще не заполнено).

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

Когда мы говорим о проверке конфигурации массива, то “большой файл” — это файл, который больше чем объем данных, адресуемых одной таблицей. В нашем случае в таблице 3 блока данных по 128 секторов = 384 сектора по 512 байт ~ 200КБ. Но в случае страйпа лучше проверить “очень большой файл” — файл, который содержит в себе больше 32 таблиц (32 — максимальный delay, который попадался на практике). Основная цель такой проверки — убедиться, что трансляция, задаваемая таблицей, подтверждается многократно.

Пробуем несколько файлов и… снова неудача, ни один большой файл не открывается.

Неудачная попытка открыть zip архив

В этот момент хочется сделать заключение, что данные повреждены и их нельзя восстановить.

Ваши варианты

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

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

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

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

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

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