Восстановить данные с HP 3PAR StoreServ 7400с реально!

Оборудование:

  • 12 дисков SAWK1000S5xnN7.2 (ST91000640SS)

Проблема:

  • Сбросили конфигурацию массива и отключили

Инструменты:

  • ПАК РС3000 RAID
  • WinHex
  • UFS Recovery explorer
  • Голова специалиста)
  • Разработанная программа
Восстановление данных сервера HP 3PAR
Диагностика и восстановление:

Принесли нам на восстановление данных диски  вот из такого чуда под названием HP 3PAR StoreServ 7400c. Мы уже были третьей компанией, куда заказчик обратился за восстановлением данных, так как в других местах (известных в Москве и не только) не смогли помочь. Это уже говорит о том, что со сборкой массива не все так просто. Будем разбираться)

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

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

Первая задача, которую нам прошлось решить, это снятие образов дисков. Нюанс в том, что эти диски прошиты под бренд HP и имеют нестандартный размер сектора – вместо сектора размером 512 байт у дисков из полки размер был 520 байт. Хорошо, что диски всего по 1 Тб. За пару дней сделали образа и приступили к дальнейшему анализу.

В начале каждого диска находится служебная информация СХД (the table of contents (TOC)), где находится, видимо, какое-то описание самой системы. Причем на разных дисках информация в этих ТОС отличаются. Первые 16 секторов на всех дисках заполнены 00 и не содержат никакой информации. А в 16 секторе и далее лежит вот такое содержимое,  в том числе модель полки:

table of contents в winhex

Все работы по анализу и просмотру секторов мы делаем в дисковом редакторе WinHex. То ли уже привыкли, то ли это действительно мощный инструмент) Через инструмент Position Manager мы нашли достаточно большую последовательность файловых записей FILE0 файловой системы NTFS. На рисунке красным подчеркнута сигнатура  FILE0, с которой начинается файловая запись, а красным – номер файловой записи.

Position Manager

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

Таблица анализа

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

Таблица RAID 6 (1)
Таблица RAID 6 (3)

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

После преобразования всех образов дисков и сборки двух массивов «странного» RAID 6 нам предстояло еще их как-то объединить. На просторах интернета, на одном из форумов, где обсуждалась СХД HP 3PAR, нашлась вот такая картинка.

RAID MP

А это очень похоже на страйп, если присмотреться. Сперва перебором мы попробовали все «классические» размеры блоков данных: от 512 байт до 1 Мб. Не подошло. Путем проб, ошибок, сканированием содержимого массива по структуре и по сигнатурам, мы подобрали правильный размер блока для страйпа и получили доступ в файловой системе VMFS, в которую был отформатирован массив. Но оказалось, что она чистая – данных на ней нет.

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

На массиве, помимо обычных файлов, оказались еще файлы бэкапов программы Veeam Backup & Replication. Но вся комичность ситуации в том, что бэкапы и файлы лежат на одном массиве в разных каталогах. Не делайте так!!! Выборочная проверка последних созданных и измененных файлов показал, что все хорошо и массив собран правильно. Но, чтобы закрепить успех, мы решили проверить файлы резервных копий vbk с помощью входящего в комплект  Veeam Backup & Replication инструмента Veeam Backup Validator. Классная вещь, чтобы не «распаковывать» бэкапы. Архивы, которые весят по несколько десятков гигабайт, оказались целыми!

Как мы потом уже выяснили, по терминологии HP 3PAR на СХД StoreServ 7400c такой массив, который мы собрали, у них называется RAID MP, или массив с двойной четностью, и должен содержать не менее восьми участников, где под данные выделяются шесть блоков и два блока под контроль четности. В этом кейсе такой такой массив собран на 6 дисках.

Если вы столкнулись с потерей данных на HP 3PAR StoreServ , раз вы читаете эту страницу, или на чем-то подобном, мы готовы взяться за восстановление данных. Системы хранения бывают с очень сложными алгоритмами распределения данных. Будем честными и не будем обещать, что восстановим данные в 100% случаях, но стремимся к таким показателям.

Диагностика бесплатная! Оплата за положительный результат!

Позвоните нашим специалистам для бесплатной консультации по телефону 8(800)350-94-46
Или заполните форму обратной связи