Определение конфигурации RAID с помощью пользовательских файлов

Определение конфигурации RAID по пользовательским файлам

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

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

Немного теории

Возьмем для примера zip-архивы. Содержимое файла zip можно условно разделить на 2 категории:

Структура zip-архива с 2мя файлами внутри

Структура zip-архива с 2мя файлами внутри

  • «метаданные zip» — различные структуры, которые описывают содержимое архива: имена сжатых файлов, способ сжатия, размеры до и после сжатия и тому подобное;
  • собственно сжатые данные файлов, хранящихся внутри архива.

Для наших целей метаданные zip очень удобны:

  • их легко проверить — у каждой структуры есть сигнатура (например, 0x504B0304 у LocalFileHeader);
  • их легко найти — структуры идут либо сразу друг за другом, либо между ними находятся сжатые данные, размер которых известен.

Метаданные zip являются чем-то вроде «контрольных точек», с помощью которых можно судить о целостности файла. Подобные точки можно выделить и у многих других типов файлов. Архивы zip я выбрал как удобный пример, но далеко не единственный.

zip-архив в просмотрщике структур

zip-архив в просмотрщике структур

Вернемся к RAID-массивам. Данные массива разбиваются на равные блоки и распределяются по дискам-участникам с помощью некоторого закона. Для всех «классических» RAID’ов, кроме JBOD, такой закон периодичен и легко описывается с помощью таблицы (мы еще часто называем ее «матрица функционирования массива»):

Матрица функционирования для RAID5 LS

Матрица функционирования для RAID5 LS

Одна ячейка — это один блок. Каждому участнику соответствует столбец. Белые ячейки с числами — блоки данных из которых формируется пространство RAID. Числа указывают в каком порядке надо брать блоки с учетом периодичности.
В большинстве случаев, задача определения конфигурации сводится к задаче заполнения пустой таблицы (т. е. определения закона следования блоков), ячейка за ячейкой.

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

Далее я опишу сценарии использования файлов для определения конфигурации RAID.

Уточнение конфигурации с помощью файла

Очень часто на практике возникает ситуация, когда мы уже начали определять конфигурацию RAID, поставили несколько блоков данных с помощью, например, метаданных диска и файловых систем. Но дальше дело, что называется, «не пошло».
Рассмотрим такой случай с RAID5 из 5 дисков и размером блока 128 секторов.

Частично заполненная таблица

Частично заполненная таблица

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

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

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

У меня нашлось несколько архивов и изображений. Все они повреждены (красная отметка возле LBA). Как раз такие нам и нужны — целый («зеленый») файл ничего нового о RAID не скажет. Делаем экспорт результатов в виртуальную файловую систему и возвращаемся к форме создания RAID. (Примечание: экспорт работает с учетом фильтра, а фильтром можно исключить целые файлы, чтобы в дальнейшем было проще).

Просмотр файлов из виртуальной ФС

Просмотр файлов из виртуальной ФС

Для дальнейшей работы нам нужны вкладки: «Проводник», «Таблица» и «Структура» (нижняя панель). Перебираем файлы в созданной виртуальной ФС. Я выбрал zip-архив. На нижней вкладке «Структура» виден перечеркнутый восклицательный знак (). Это значит, что при разборе произошла ошибка. У этой ошибки могут быть две причины: очередная структура файла находится в еще непоставленном блоке данных, либо файл поврежден или фрагментирован. Нас интересует первый случай.

Вместо вкладки «Проводник» откроем вкладку структура на левой-верхней панели, чтобы подробней разобраться с этим файлом.

Верхняя вкладка "Структура" для просмотра содержимого файла на RAID, нижняя вкладка для просмотра структур на дисках

Верхняя вкладка «Структура» для просмотра содержимого файла на RAID, нижняя вкладка для просмотра структур на дисках по текущему смещению

Мы видим, что в архиве были найдены 3 структуры LocalFileHeader и на этом разборщик остановился. Строка ErrorSignature имеет смещение, по которому ожидалась, но не была найдена, корректная для zip-файла сигнатура. Если выделить ее, то будет выполнен пересчет этого смещения для поиска на участниках.

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

Данные из ячейки d1 не подходят

Данные из ячейки D1 не подходят

Данные для ячейки E1 удалось успешно интерпретировать как еще один LocalFileHeader. Такая ячейка оказалось единственной, поэтому можно смело обозначать ее как 4й блок данных.

Данные из ячейки E1 подходят

Данные из ячейки E1 успешно интерпретируются как очередной LocalFileHeader

Мы поставили новый блок данных, т. е. текущая конфигурация RAID была изменена. Надо обновить структуру. Более того, комплекс обнаружил, что такая расстановка блоков может быть только у RAID 5 LS и автоматически расставил еще несколько блоков.

Обновление структуры

Обновление структуры

Теперь мы видим, что появилась еще одна запись LocalFileHeader – это результат установки 4го блока данных. Однако, файл все равно не раскрывается до конца и мы можем использовать его дальше.

Конфигурация после установки 4го блока данных

Конфигурация после установки 4го блока данных

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

Как начинать с пустой таблицей и файлом, найденным на одном из участников

В предыдущем примере мы начинали с уже частично заполненной таблицы. Но иногда на восстановление попадают массивы, которые пытались «лечить» деструктивными методами, например, запуская ребилд с новыми параметрами или форматируя в новую файловую систему. У таких массивов переписано начало каждого участника и бывает трудно начать заполнение таблицы по дисковым метаданным и метаданным файловых систем.

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

Обычно для определения некоторых параметров RAID я пользуюсь черновым восстановлением, поэтому когда дело доходит до заполнения таблицы, часто уже есть результаты режима для нескольких участников. Предположим, мы хотим воспользоваться конкретным файлом, например, мы точно знаем, что он из «старой» конфигурации, а не из той, что возникла в попытках «лечения».

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

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

Пусть это «красный» zip-архив на LBA 496 944 на участнике E (его номер в оригинальном RAID нам еще не известен). С помощью несложных расчетов легко понять, что этот архив попадает в строку №2 таблицы:

(FileOnDiskLBA div BlockSize) mod RowCount = (496 944 div 128) mod 5 = 2

А его LBA на RAID будет где-то рядом с 1 987 776:

FileOnDiskLBA * (DriveCount – 1) = 1 987 776

Посчитать точно мы не можем, поскольку нам неизвестны все параметры.

Ячейки в строке №2 у RAID5 из 5 дисков

Ячейки в строке №2 у RAID5 из 5 дисков

Независимо от алгоритма у RAID5 из 5 дисков в строке №2 находятся следующие блоки данных: 8, 9, 10 и 11. На один из них и попадает найденный нами zip-архив, но мы не знаем точно на какой именно. Выберем любой, например, 8 и поставим его в таблице. Скорей всего мы не угадали, но в дальнейшем мы это учтем. Наша цель сейчас, просто получить этот файл в пространстве данных RAID.

Блок 8

Блок 8

Запустим черновое восстановление на RAID от LBA 1 900 000, чтобы найти тот же архив, но уже на текущем RAID.

Результаты чернового восстановления на временном RAID, где установлен только блок 8

Результаты чернового восстановления на временном RAID, где установлен только блок 8

В моем случае архив нашелся на LBA = 1 987 632. Выполним экспорт результатов в виртуальную файловую систему. И вернемся к сборке массива.

Перед тем как расставлять блоки с помощью этого файла, необходимо включить опцию учета конфигураций со сдвигом. При сравнении текущей конфигурации со стандартными комплекс будет учитывать, что выбранный нами блок 8 на самом деле может быть блоком 9, 10 или 11.

Включение опции учета конфигураций со сдвигом

Включение опции учета конфигураций со сдвигом

Дальше процесс расстановки блоков по контрольным точкам файла будет почти такой же как в предыдущем случае. Однако будут некоторые отличия от «нормальной» сборки, когда не учитывается возможность сдвига:

  • некоторые блоки будут попадать не в свою строку. У меня блок 3 оказался в строке 1, когда должен находиться в строке 0;
  • в списке подходящих конфигураций появятся конфигурации со сдвигом, например, L5LS>1 – конфигурация со сдвигом в один блок (блок 8 на самом деле является блоком 9);
  • кандидаты, подходящие для текущего блока с учетом сравнения со стандартными конфигурациями (ячейки обведенные серым), могут располагаться в нескольких строках и их может быть больше.
Расстановка блоков у конфигурации со сдвигом

Некоторые особенности при определении конфигурации со сдвигом

Когда комплекс угадает полностью конфигурацию, он учтет сдвиг и перенумерует правильным образом все блоки данных.

Если конфигурация файла еще не определена, то можно запустить черновое на временном RAID и продолжить с новыми файлами.

Еще один способ начинать с пустой таблицы

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

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

Мы собираем RAID5 из 5 дисков с размером блока 128 секторов. Порядок дисков и алгоритм нам неизвестны (т. е. не известно заполнение таблицы). Выберем эти параметры произвольным образом. Я не менял порядок дисков, а алгоритм выбрал RA. Если нам очень повезет, то мы угадаем параметры

Запустим на таком RAIDе черновое восстановление и подождем пока не наберется побольше потенциально подходящих файлов. Главное отличие от предыдущего метода в том, что мы будем искать данные сразу на всех дисках и нам не надо будет делать пересчет в пространство секторов RAID.

Черновое восстановление на RAID с произвольно выбранной конфигурацией

Черновое восстановление на RAID с произвольно выбранной конфигурацией

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

Виртуальная ФС

Виртуальная ФС

Рассмотрим отдельно от остальных один из файлов виртуальной ФС. У такого файла уже есть положение в RAID, он точно попал в свою строку, но не факт, что попал в нужный блок. Мы абсолютно также можем начать собирать RAID с помощью этого файла, как и в предыдущем примере: включаем учет конфигураций со сдвигом и проходимся по контрольным точкам файла.

Однако важно понимать, что если мы продолжим собирать конфигурацию с другим файлом из этой виртуальной ФС, то скорей всего совершим ошибку. Мы получили эту ФС после анализа неправильной конфигурации, поэтому у каждого файла будет свой сдвиг относительно правильной конфигурации, например, у первого архива 1 блок, а у второго -2 блока. Если расставить все заголовки файлов из виртуальной ФС — то получим ту самую заведомо неправильную конфигурацию, с которой начали.

Чтобы не попасть в такую ловушку необходимо придерживаться следующих правил:

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

Заключение

За недолгое время существования просмотрщика структур в Data Extractor, он уже не раз помогал нам быстро определить конфигурацию массива в достаточно сложных случаях, когда массив пытались «лечить» с помощью ребилдов и форматирований в новую файловую систему. На дисках при этом оказывалась каша из различных метаданных, которые были до, во время и после «правильной» конфигурации. Поэтому они были малопригодны для определения конфигурации.

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

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

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

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

3 комментария на «Определение конфигурации RAID с помощью пользовательских файлов»

  1. JP Saunier говорит:

    Hi !
    great video and exemple ! But have you the same video in English, please ?
    Thanks,

    • Hello!
      Thank you for your comment!
      There are no videos in English, but we are going to make them in the second half of September. They will be posted on our English blog: http://blog.acelaboratory.com/.

      Just a little comments about videos:
      All videos are about how to use user’s files to detect RAID configuration. We examine 3 cases (one case — one video):

      1) We had already started detection of RAID configuration (there are 2 placed blocks in the table) and got stuck. After that we search files and use them to continue detection of configuration.

      2) We have found suitable file on one of the drives and we want to use it for filling the table. We don’t know exactly in which data block it should be placed. So we choose any one from row and turn on option «check configurations with shift».

      3) We set randomly unknown parameters (drive order and algorithm) to make temporary RAID. After that we search files on this RAID, use one of them for filling the table. We use temporary RAID for two reasons: 1) we are searching for files on all drives at once — it is faster 2) we don’t have to do any calculations like in the 2nd video. But be careful, there is a wrong way! If you start to place headers of all files, you’ll get temporary RAID. The right way is using only one file or files which have already been placed. Also you can search for new files on incomplete configuration and continue with these files.

      P.S. Sorry for possible mistakes in my English.

  2. gex91 говорит:

    Здравствуйте, Александр, если Вас не затруднит, прошу связаться со мной по эл. почте Ilya0991@mail.ru либо ВК id308845713.
    С Уважением! Илья.

Добавить комментарий для gex91 Отменить ответ

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

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>