RAID-recovery

подъем RAID'ов с аппаратно-программной глубины\\ на операционную поверхность

крис касперски ака мыщъх

airplane rule (правило самолета) гласит: сложность увеличивает вероятность поломки; двухмоторный самолет по сравнению с одномоторным имеет, по крайней мере, вдвое больше проблем с двигателями. и это совсем не шутка. отказы RAID'ов (как программных так и аппаратных) — вполне обычное дело, а вот сложность их восстановления порядка на два выше. в одной статье, короткой как мышиный хвост, просто невозможно описать технику восстановления в деталях, поэтому ограничимся базовыми приемами, подтолкнув читателя в нужном направлении.

Ручное восстановление данных требует специальной подготовки и боевого опыта (сына ошибок трудных). Не стоит и надеяться, что чтение статей, книг и технической документации поможет восстановить упавший дисковый массив с первого раза, не угробив его окончательно. Автоматизированные утилиты — бесспорное зло, но это наименьшее зло и безальтернативный компромисс для тех, кто не занимается восстановлением данных регулярно и не имеет ни средств, ни времени для обучения. На «подъем» дискового массива зачастую отпущены дни или даже часы и чтобы в суматохе ничего не напутать, необходимо _заблаговременно_ скачать автоматизированные утилиты (тем или иным образом зарегистрировав их), создать виртуальный RAID под VM Ware (или Virtual PC) и разобраться с основными рычагами управления.

Главным образом, мы будем говорить об операционных системах семейства NT и файловой системе типа NTFS, Linux/BSD устроены совсем по другому, но оставить их неупомянутыми — это преступление.

Лучшая утилита для автоматизированного восстановления аппаратных RAID-массивов и динамических дисков, поддерживаемых начиная с Windows 2000, это, бесспорно, R-Studio от компании R-Tools Technology (www.r-tt.com). Версия чисто для NTFS (http://www.r-studio.com/) обойдется всего лишь в $50, что немногим дешевле полной версии, «передающий» десяток файловых систем из разных операционных миров и стоящей $80, хотя ее полнота весьма относительна и R-Studio Technical License со всеми наворотами обойдется в $900, при этом компания настоятельно рекомендует хорошо подумать, прежде чем ее покупать. Довольно странный маркетинг неправда ли?

Рисунок 1 так выглядит R-Studio

NtExplorer от Runtime Software (http://www.runtime.org) представляет собой продукт совершенно иного класса —удобный дисковый редактор, отображающий в естественном виде все ключевые структуры файловой системы NTFS (версия для Linux появилась относительно недавно и все еще остается достаточно сырой, но все же это лучше, чем lde или другие дисковые ректоры, которыми приходилось пользоваться до этого). И та, и другая версия стоят по $69. Работа с RAID-массивами непосредственно не поддерживается, но при тяжелых отказах (например, кончине RAID-контроллера) с дисками приходится работать на физическом уровне и тут NtExplorer оказывается незаменим. R-Studio так же включает в себя дисковый редактор, но нереально примитивный и ужасно неудобный.

Рисунок 2 …а так — NtExplorer

Наконец, для осмысленного управления всеми рычагами непременно потребуется справочное руководство и путеводитель по структурам файловых систем, например, «технику восстановления данных», которую можно бесплатно скачать с http://nezumi.org.ru/recover-full-rus.zip

Всякий RAID (неважно аппаратный или нет) представляет собой дисковый массив, информация о конфигурации которого чаще всего хранится на самих дисках в специальной области, обычно расположенной в начале и/или конце каждого диска, а, потому, воткнуть диск в обычный контроллер не получится — даже если это RAID-1 (зеркальный диск), то BIOS, не обнаружив в положенном месте загрузочного сектора с таблицей разделов, откажется грузится. ОК, грузимся с дискеты. На физическом уровне диск читается прекрасно, но вот операционная система в упор не видит структур данных файловой системы и предлагает отформатировать такой диск, считая его пустым. Заманчивое предложение, но лучше отказаться от него сразу и навсегда.

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

Достаточно многие аппаратные RAID-контроллеры определяют порядок следования дисков, путем жесткой привязки их к портам контроллера или говоря человеческим языком — кабелям, соединяющих их. Это не есть гуд по той простой причине, что если мы вытащим (сгоревший) контроллер, предварительно не пометив порядок кабелей, то даже заменив его новым, превратим дисковый массив в труху (если, конечно, это не RAID-1) и придется запускать утилиту автоматического восстановления, например, ту же R-Studio.

Размер одного блока иногда хранится в энергонезависимой памяти контроллера и утрачивается при кончине последнего (или тотальном сбросе всех настроек, если, конечно, размер блока отличается от дефлотного). Простейшие RAID-контроллеры хранят в энергонезависимой памяти и тип дискового массива (особенно это характерно для RAID-контроллеров, интегрированных в материнскую плату).

Блок конфигурации аппаратного RAID'а операционной системе недоступен и потому может быть разрушен только из-за ошибок в самом RAID'е или образовании BAD-секторов на поверхности диска (клинические случаи когда мы снимаем диск с RAID-контроллера и подключаем к обычному IDE/SCSI контроллеру мы не рассматриваем, хотя… интегрированные RAID-контроллеры зачастую могут работать в обоих режимах и при сбросе настроек CMOS'а переходить из RAID'а в обычный режим).

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

А можно и не вытягивать, а восстановить методом перебора. Поскольку, дисковые массивы более чем из 5ти HDD – редкость, их порядок побирается за несколько минут. С размером блока дела обстоят чуть сложнее, но, поскольку, он может принимать только фиксированный ряд значений, кратный размеру сектора, то количество возможных вариантов не так уж и велико. Просто создаем виртуальный RAID в R-Studio и перебираем его параметры до тех пор, пока все данные не станут полностью читабельными.

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

А вот вылет RAID-контроллера, интегрированного в материнскую плату, это уже катастрофа. Даже если удастся найти аналогичную мать, вовсе не факт, что при смене ревизии и прошивки контроллера не изменится и структура блока служебных данных. Опять-таки, если часть информации о конфигурации хранится в CMOS (а она хранится она там предательски часто), то после замены матери интегрированный RAID-контроллер запросто может отказаться распознавать дисковый массив, предлагая сделать ему REBUILD, уничтожающий все данные.

В таких случаях приходится растаскивать массив по отдельным дискам, подключать их к обычному контроллеру и собирать исходную матрицу в дисковом редакторе или все том же R-Studio. Он это умеет. Проблема возникает лишь когда кол-во дисков в матрице превышает кол-во портов IDE-контроллера на материнской плате. Мыщъх не собирается отправлять пострадавших в магазин на поиски платы с большим кол-вом портов, равно как не настаивает на использовании внешних IDE-контроллеров, втыкаемыхв PCI (реже в USB), поскольку это негуманно. Виртуальные RAID'ы, создаваемые R-Studio, могут собираться по частям, сливаясь в один большой файл, записываемый на диск. Конечно, этот диск должен быть достаточного размера и при восстановлении RAID-0 массивов, составленных из нескольких дисков максимального объема, какой только встречается в продаже, возникает очевидная проблема — а куда все это лить?! Ответ — собирать новый RAID. Другого выхода нет.

Кстати, SCSI-контроллеры обычно не имеют таких жестких ограничений по кол-ву портов как IDE и потому собирать матрицу по кусочкам не требуется и (не без риска конечно) можно собирать виртуальный RAID непосредственно на базе разрушенного, то есть без копирования его в отдельный файл, который нам и разместить негде.

Отказ одного или нескольких жестких дисков, превышающий предел избыточности RAID'а — это самое худшее, что только может случиться с массивом. И нужно очень сильно извратится, чтобы спасти хотя бы _часть_ данных, особенно на массивах типа RAID-0 (т.е. без избыточности).

Техника восстановления (а с ней — и наши шансы на удачу) очень сильно зависит от типа массива поэтому мы решили разделить RAID'ы по классам, начиная от самых простых и заканчивая уже совсем навороченными. Поехали, короче.

concatenation (JBOD или SPAN)

Это не совсем RAID, точнее совсем не RAID, но он поддерживается многими контроллерами и довольно популярен в программных RAID'ах. Два и более дисков физических просто объединяются в один логический с последовательной адресацией. Естественно, «логический» в терминах RAID'а. С точки зрения операционной системы это вполне натуральный физический диск, который может быть разбит на сколько угодно логических разделов (томов). Ни скорости, ни отказоустойчивости это не добавляет, просто позволяет создавать диски большого размера. И, как правило, такие диски не разбиваются. Иначе зачем их было объединять?!

Вылет последнего диска из строя не представляет никакой проблемы и при этом теряются только записанные на нем данные. Естественно, фрагментированные файлы могут располагаться сразу на нескольких дисках и если хотя бы один кластер попадает на дефектный диск, файл становится «дырявым». Насколько это смертельно — зависит от типа файла. Многие файлы (pdf например) включают себя не продублированные и не восстанавливаемые структуры данных при повреждении которых они вообще не открываются. Другие же (скажем, zip-архивы) выживают даже если представляют собой сплошное «решето».

Хуже всего, если вылетает первый диск. На нем в NTFS хранится схема размещения всех остальных файлов, без которой нечего и пытаться вытянуть с RAID'а хотя бы часть данных. Исключения составляют случаи, когда файлы слабо фрагментированы и включают в себя служебные структуры данных, указывающие на порядок размещения их блоков. Тот же zip-архив может быть восстановлен даже при относительно сильной фрагментации и отсутствии схемы размещения кластеров, принадлежащих восстанавливаемую файлу. Просто собираем все свободное пространство в один большой комок данных и говорим pkzip.exe заветное слово -fix и… мы получаем все файлы, хранящиеся в zip-архивах.

Аналогичным способом можно восстанавливать MS Office документы, базы данных… На сайтах вышеупомянутых компаний имеются специальные утилиты, которые делают это. R-Studio даже в урезанной редакции распознает большое количество типов файлов и хорошо умеет их восстанавливать. Так что не отчаивайтесь!

Вылет «серединного» диска представляет собой частный случай отказа последнего диска, при котором гибнут только те данные, которые расположены на нем. При отсутствии одного из дисков матрицы контроллер, конечно, работать с ней откажется, но вот R-Studio – запросто. Перегоняем содержимое на виртуальный RAID-массив и копируем с него все данные, которые только можно скопировать. При этом могут оказаться разрушены каталоги, т.к. каталоги хранятся в специальных индексных файлах, но они уже давно перестали быть критической структурой данных и лишь ускоряют операции с каталогом, дублируя базовые структуры файловой системы, которые записаны на первом диске. Для переиндексации каталогов в NT/NTFS достаточно запустить chkdsk и все будет ОК. С файловой системой FAT этот номер, увы, не проходит, но вот с ext2/3fs/UFS (файловые системы миров Linux/BSD) – вполне.

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

Рисунок 3 JBOD RAID

RAID-0 (он же stripe set или striped volume)

Гадость. Обещает увеличить производительность вдвое, но… на практике быстродействие возрастает максимум на 10%-30% (цифровой видео монтаж и работа с графическими файлами полиграфического разрешения — единственное исключение из правила), а вот надежность падает ниже абсолютного нуля.

Данные пишутся на диск блоками. Первый блок на первый диск, второй — на следующий и так далее. Допустим, мы имеем два диска в матрице (наиболее распространенная комбинация) и записываем блоки A1 A2 A3 A4 A5 A6, тогда при выходе одного дисков из строя мы имеем «решето» вида A1 A3 A5 A7. Ну и что с ним делать?! Большинство журнальных статей предлагают идти и вешаться или сдаваться на мясокомбинат, потому что сделать тут нельзя абсолютно ничего.

На самом деле, все зависит от конфигурации RAID'а. Учитывая, что типичный размер одного блока составляет 8, 16, 32 или 64 Кбайт, то мелкие файлы восстанавливаются на ура. Это раз. Если имеется более одной копии восстанавливаемых файлов (пускай даже расположенных на том же самом RAID'е), то с определенной вероятностью они окажутся «продырявленными» в разных местах, и собрать из двух копий одну — вполне нормальное явление.

Что же касается информации об размещении файлов, то… половину записей в служебных структурах данных мы теряем сразу (и она, увы, нигде не продублирована), а потому реально удается восстановить в лучшем случае 10%, ну максимум 25% данных с двухдисковой RAID0 матрицы с одним поврежденным диском, да и то при благоприятных условиях. Но все-таки, 10% это уже кое-что и _намного_ больше, чем совсем ничего.

Рисунок 4 RAID-0

RAID-1 (он же mirror)

Самый замечательный массив в плане восстановления. Данные дублируются на все диски, что только есть в наборе (обычно их там два) и при отказе одного из дисков мы не теряем ничего. Теоретически. А практически, очень многие RAID-контроллеры отказываются работать с одним диском, требуя вставить чистый диск такого же или большего объема для его автоматического реплицирования. Причем, зачастую это выглядит как полный отказ. Контроллер сообщает об ошибке, операционная система не видит массива и перепуганный администратор хватается за валидол, недоумевая как могли погибнуть сразу два диска. И только запустив диагностическую утилиту (поставляемую вместе с контроллером) мы видим, что вылетел только один диск и какой именно. Главное тут — не перепутать их местами.

Как вариант, можно воспользоваться услугами R-Studio, последовательно подключая то один, то другой диск к обычному контроллеру. R-Studio запросто вычитает с рабочего диска все данные, позволив их записать куда угодно. А некоторые контроллеры имеют режим перевода RAID1в не-RAID, что позволяет подключить уцелевший диск к матери и работать с ним без всяких извращений, правда, пользоваться этой фичей _категорически_ не рекомендуется, поскольку при этом часто гробятся данные из-за багов контроллера, плюс, такой ребилд создает огромную и весьма продолжительную нагрузку на винчестер, а он ее может и не выдержать (раз его сосед сдох, то, с некоторой вероятностью, может сдохнуть и он).

Рисунок 5 RAID-1

RAID-2, RAID-3, RAID-4

Используются _крайне_ редко, если вообще используются. Заинтересованных мыщъх отсылает к Википедии (http://en.wikipedia.org/wiki/Standard_RAID_levels) а сам тем временем переходит к более насущим вещам.

RAID-5

Довольно популярен на серверах. Требует как минимум 5ти дисков (обычно же используется _ровно_ 5), при этом 1/5 объема массива занимают коды коррекции ошибок за счет которых RAID выдерживает отказ _любого_ из дисков матрицы. Другими словами, если RAID-0 имеет избыточность 50%, то RAID-5 всего лишь 10%.

Практически все RAID'ы используют так называемое _систематическое_ кодирование, при котором коды коррекции ошибок отделены от данных. А вот где они записываются… это вопрос. Часть контроллеров записывает их на отдельных диск, часть — распределяем по всем дискам, причем, первая схема используется намного чаще второй, вот и будем от нее плясать.

Возьмем RAID-5 массив и представим, что из строя вышло сразу два диска. Такое хоть редко, но случается. Каковы наши шансы на успех? Увы! Наши шансы невелики, поскольку нам придется иметь дело с RAID-0 из четырех дисков, один из которых неисправный. То есть, мы получаем «решето» с дырой в каждом четвертом блоке. Если размер блока составляет 64 Кбайта, то файлы размер которых не превышает 192 Кбайт имеют хорошие шансы остаться не продырявленными, а вот с остальными предстоит распрощаться или собирать их по осколкам при наличии копий по вышеописанной методике.

Рисунок 6 RAID-5

комбинированные типы RAID'ов

Хорошие контроллеры поддерживают режим гибридизации, позволяющий совмещать RAID-0 с RAID-1, в результате чего мы… кхм, удваиваем (в теории!) производительность и отказоустойчивость ценой 50% избыточности. На самом деле, отказоустойчивость приближается к 75%, поскольку, при вылете двух зеркальных дисков, мы сохраняем 100%, но вот если выйдет из строя один зеркальный и парный ему диск, мы получаем ту же ситуацию, что и с RAID-0, описанную выше.