Помните, кто такие киты? Громадные такие звери, которые в воде живут. Говорят, что больше китов в истории Земли еще никого не было. Голубой кит – до 33 метров в длину, а вес вообще за пределами понимания – 150 тонн! Здоровенная дура, ага.
Нет-нет, это не ликбез по зоологии. Просто аналогия почему-то такая придумалась. Я про RAID современные. Вот был недавно у нас такой: 8 накопителей по 3 Тбайт. RAID-0. Это 24 Тбайт без малого! Причем – совершенно никак не защищенных данных: один винт из массива вылетел – и до свидания всё, что собиралось долгим и непосильным трудом. Так, собственно, и случилось…
Справка: RAID-массив емкостью 24 Тбайт (технически имеется возможность довести емкость до 32 Тбайт увеличением емкости каждого накопителя до 4 Тбайт) производства компании Netgear представляет собой сетевое хранилище данных с собственной операционной системой (Linux) с возможностью подключения как по локальной сети (LAN), так и традиционными интерфейсами (в числе которых USB-3). Прибыл к нам в состоянии FAIL, RAID потерял 2 накопителя из восьми. На сетевом хранилище находятся видеоматериалы: крупная больница складывала сюда отснятые операции. Извлечение данных в режиме RAW (т.е., просто видеофайлы без сохранения файловой структуры) клиенту не подходит: видеофайлы разложены в папки, названия которых содержат фамилию пациента и дату операции.
Задача: восстановить работоспособность двух «выпавших» накопителей, восстановить работу RAID-массива, скопировать данные на «здоровый» накопитель.
Как видим, из самой задачи уже вытекают те трудности, с которыми нам пришлось столкнуться пи выполнении работ. Итак, по порядку:
1. Восстановление работы «выпавших» накопителей. При первичном анализе было обнаружено, что оба накопителя бодро стучат. Для НЖМД емкостью 3 Тбайт это весьма печальный синдром: во-первых, однозначно нужны доноры (а они вовсе не дешевы), во-вторых, работы по замене головок весьма трудоемки; наконец, в-третьих, вычитывание накопителя емкостью 3 Тбайт «чужими» головками – довольно продолжительный процесс, сопряженный с постоянным риском того, что головки не вынесут нагрузок и уйдут в небытие; в этом случае потребуется новый донор.
2. После того, как безвременно почившие трехтерабайтники склонированы, нужно подключить все накопители массива к компьютеру и «собрать» RAID. Тут две объективные трудности: организовать необходимое количество портов и соответствующее питание накопителей. Вторая проблема в целом решается довольно просто: устанавливаем дополнительный блок питания. Первая проблема решается несколько сложнее: покупкой многопортового SATA-адаптера, поддерживающего диски большой емкости. На Ебае таких карт – пруд пруди, однако надо понимать, что есть карты хорошего качества, есть средние, а есть откровенное гуано. Поскольку мы, прежде всего, профессионалы, гуано и среднее качество отправились на помойку наших желаний, и мы стали обладателями прекрасного 8-портового SAS/SATA-адаптера LSILogic. Железо готово к работе.
3. И вот теперь – апофеоз восстановления. Нам нужен носитель, способный вместить более 20 Тбайт клиентских данных. Однозначно, это другой RAID-массив. Клиента пришлось предупредить: копирование такого объема данных сначала на наш сервер, а потом на накопитель клиента займет не меньше двух недель, и если данные нужны достаточно срочно, будет лучше, если мы начнем копирование сразу на накопитель клиента. На следующий день нам привезли такой же RAID-массив, как тот, с которого нам пришлось восстанавливать данные.
И работа закипела…
Замена головок на трехтерабайтном WDдля профессионала не представляет особых трудностей – самое главное доноры. В нашем случае с ними не было проблем – в нашем распоряжении был весь массив, собранный из одинаковых накопителей с последовательными серийными номерами (большое везение, кстати). Согласие клиента на использование живых накопителей массива в качестве доноров было получено. Естественно, вначале все накопители массива были нами склонированы. Вычитывание каждого из «больных» заняло почти два дня (скажу честно – удачно встали донорское головы, читалось быстро и почти без ошибок).
Готовые к работе клоны (а мы никогда не работаем в случае RAID-восстановлений с оригинальными клиентскими дисками – всегда только с их клонами; во-первых, при таком подходе отсутствует риск потерять данные навсегда в случае какого-либо сбоя или ошибки, а во-вторых, у нас всегда есть возможность вернуться к первоначальному состоянию) подключаем к SATA-контроллеру, стартуем компьютер. Тут важно понимать, с чем сейчас мы будем работать. RAID-0 – это очень простая организация массива данных, диски просто объединены в один большой накопитель (для системы он им и является) и работают по простому принципу последовательной записи: данные делятся на порции, кратные определенному числу секторов, и записываются последовательно на разные накопители массива в определенном порядке. таким образом удается не только разместить данные большого объема, но и заметно увеличить скорость дисковой подсистемы, ведь данные на разные накопители можно записывать одновременно. На рисунке мы показали различия в работе дисковой подсистемы на одном накопителе и на RAID-массиве с файлом одинаковой длины.
Теоретически на 8 накопителей можно было бы писать данные раз в 8 быстрее, но практически оказывается прирост скорости примерно в 2 – 3 раза. Однако и это совсем не плохо (оговоримся, что на самом деле прирост скорости сильно зависит от вашего железа – можно и в 5 раз поднять скорость, но тогда ПК должен стоить около 2 тыс. американских рублей). Предвосхищая ваши вопросы о том, какой RAID-массив надежнее, скажу: об этом мы поговорим в следующей статье. Вопрос не простой, в паре слов его не осветить =).
О Кей, диски подключены, система запущена, начинаем соображать, как нам данные собрать. В случае с RAID-0 все достаточно просто: нам надо знать порядок дисков в массиве и величину блока. Первый диск находим по заголовку раздела. Дальше ищем диски, основываясь на файловых таблицах: они должны выстроиться по порядку. Но вот незадача: на дисках, с которыми мы работаем, разделы начинаются не с начала, как обычно, а с определенным отступом. Этот отступ называется смещение; его присутствие вызвано тем, что собственно массив находится под управлением ОС сетевого хранилища, и где-то эту самую ОС, а также необходимые журналы и прочие вспомогательные файлы, необходимо разместить. Вот и «кусает» хранилище сколько-то места от начала каждого диска, где и организуется. Кстати, вовсе не обязательно, что с начала – может и в конце чего откусить, и даже в середине; в некоторых особо извращенных случаях даже блоками сообразно какому-то паттерну. В общем, смещение надо обнаружить и учесть, если оно имеется.
В нашем случае смещение составило около 2 млн. секторов, после чего шли уже блоки данных. Определив их величину (128 секторов), приступили к определению порядка дисков. Диск номер 0 нашли по заголовку раздела; дальше нашли кусок файловой системы и начали отстраивать диски относительно него. Это не сложно: сообразно размеру блока, следующий по порядку элемент ФС должен стоять на адресе 128+1 от текущего начала элемента ФС на анализируемом диске. Процедура поиска порядка дисков заняла меньше 10 минут =).
Для сборки непосредственно массива использовалось ПО WinHex. Это одна из лучших программ для работы с данными, позволяющая делать с ними практически все, что угодно. Собранный массив можно интерпретировать как диск (при этом он подмонтируется в систему и с ним можно работать как с обычным накопителем), либо копировать из него данные как делает любая программа для их восстановления типа R-Studio. Нами было принято решение просто скопировать данные на накопитель нашего клиента. Что и было сделано. За 8 дней J.
Что можно сказать в заключение? Огромные хранилища данных – уже реальность. Они проникают к нам на работу, проникают к нам в дом. Количество media-контента растет и ширится с каждой секундой – фотографии, видеофайлы, фильмы, музыка и т.п. – и все это нужно где-то хранить. И мы покупаем, покупаем сетевые накопители, многодисковые USB-устройства, специализированные пластиковые ящики с кучей дисков внутри… Мы их роняем, неправильно включаем или выключаем, форматируем (по ошибке, конечно), заражаем вирусами (опять же, не сами 😉 ) и так далее – нашим фотографиям очень не просто живется в современном мире ;). И в итоге – все это богатство приходится спасать от исчезновения. Нет, в большинстве своем ваши данные живут нормально долгие годы, но иногда, при определенном стечении обстоятельств… В общем, не храните все яйца в одной корзине))