Мы на связи:
+7 (351) 751-16-68

Мы находимся:
Челябинск, Гагарина, 9, оф. 417

Восстановление данных

RAID-массив на данные

Итак, дорогие друзья, давненько мы не баловали вас публикациями! А все потому, что в основном работа однообразная, разве что за зиму удалось разобрать несколько новых вариантов DVR-систем, оптимизировать и исправить кучу ошибок в нашем проекте по WFS0.4, а так же разработать пару исследовательских инструментов для разбора видеозаписей со стационарных видеорегистраторов для удаленной помощи. Но сегодня не об этом, а об одном занимательном, нетипичном для российской глубинки RAID-массиве (собственно, он так и остался нетипичным, так как решали задачу удаленно для коллег). Что такое RAID-массив, вы можете прочитать на википедии по ссылке.

Вводная

Итак, 4 диска. Точнее, 5. Точнее, 3 :-)

Изначально было 4 диска-участника. Назовем их физическими дисками 0, 1, 2, 3.

На каждом диске было по два раздела в RAID1 (зеркало, то есть одинаковые данные на всех участниках). На этих разделах лежала исходная операционная система Linux.

Дальше на каждом диске лежали по 8 разделов, что там внутри - на первый взгляд не ясно.

raid-drives

Анализ

Дальше пошло интересней - разбор суперблоков показал, что каждый раздел из восьми является частью RAID-5, который растекался по всем дискам. Сейчас станет чуть понятней после иллюстрации.

raid-drives

Собрав этот набор рэйдов-пятерок мы получили 8 разделов. Анализ разделов показал, что при разбивке участвовал LDM (подробней об LDM на википедии).

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

raid-drives

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

Но это еще не все! Внутри JBOD раздела мы наконец-то увидели файловую систему, и система это зовется XFS. Внутри файловой системы лежит один файл-образ размером около 10 терабайт для подключения по iscsi (подробнее на википедии).

raid-drives

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

Внутри iscsi файла оказалась файловая система VMFS (ссылка на другую википедию).

raid-drives

Внутри VMFS, как уже знает осведомленный читатель, находятся виртуальные машины VMWare вместе с образами жестких дисков.

raid-drives

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

Неисправность

А звоночек заключался в "потере бойца", то есть одного из дисков, если быть точнее - диска 0. О чем ОС радостно и сообщила пользователю.

Что в этом случае сделал пользователь? Поставил новый диск, который стал физическим диском 4.

Настало время ввести термин "роль". Роль - она и в Африке роль, но мы будем в данном случае ролью называть номер логического диска в массиве.

В исходной комбинации роль диска равнялась его физическому номеру. Диск 0 - роль 0, диск 1 - роль 1 и так далее.

Новый диск 4 получил роль 0, так как он был поставлен взамен ушедшего на покой диска 0.

И был ребилд, и синхронизация шла бодро... пока не вышел из строя диск №2. (синхронизация - вычисление и запись данных отсутствующего диска за счет оставшихся данных и блоках контрольных сумм на живых дисках).

В итоге, диск №2 выпал из системы, систему перезагрузили и наш диск 4 стал полноценным участником в массиве, разве что один из оставшихся разделов не успел синхронизироваться.

Благо, найти место расхождения не так уж и трудно, массив был собран из всей этой сборной солянки, задача решена!

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

Выводы

Что могу сказать - даже, казалось бы, надежный RAID-массив не может гарантировать целостности данных. Только бэкап спасет мир!

А Вы, дорогой читатель, в случае проблем с массивами лучше сразу принесите его для анализа и сборки специалистам, чем запускать ребилд и усложнять работу в разы. :-)