Pull to refresh

Грех администратора или восстановление данных из стучащего HDD Western Digital WD5000AAKX

Reading time 10 min
Views 50K
В одной маленькой софтверной компании хранение данных было организовано следующим образом: сервер, в котором обыкновенные SATA накопители средствами linux (mdamd) организованы в несколько массивов RAID 1, каждый из которых являлся хранилищем для одного из направлений разработки. Данный вариант при минимальных затратах относительно надежен, если за ним подобающим образом присматривать. Но системный администратор решил, что нет нужды регулярно проверять состояние массивов, и занимался иными делами. В июне 2017, получив жалобы о невозможности прочитать данные от пользователей одного из массивов, обнаружил, что собственно массива уже давно нет, и что на один из накопителей запись прекратилась в августе 2015, а второй с актуальными данными при попытке монтирования подвешивает ОС. Резервная копия за пределы сервера последний раз была сделана в ноябре 2016 года.


рис. 1

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

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

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

12 июня утром, сразу же после открытия, на пороге офиса нашей компании появляется человек, который сообщает, что ему срочно необходимо получить услугу бесплатной диагностики накопителя WD5000AAKX-221CA1, который подвешивает систему и не позволяет скопировать файлы. Накопитель без следов вскрытия.

Проводим стандартные диагностические мероприятия: визуальный осмотр, проверка цепей питания на печатной плате, сопротивления обмоток двигателя. Не обнаружив ничего крамольного, подключаем к порту PC3000 и подаем питание. Слышен нормальный звук раскрутки вала, прохождения калибровочного теста. По регистрам накопитель демонстрирует готовность к обмену данными. На запрос паспорта получаем от жесткого диска корректный ответ со всеми данными. Проверяем читабельность модулей микропрограммы и оцениваем их контрольные суммы. При анализе relo-list обнаруживаем, что он не пустой, что свидетельствует о том, что микропрограмма накопителя обнаружила некоторые проблемы на поверхности. Просматривая атрибуты SMART, замечаем, что 197 атрибут (текущее количество нестабильных секторов) весьма далек от нулевого значения, что подтверждает наличие проблем. Модифицируем в ОЗУ накопителя настройки: отключаем процедуры переназначения и добавления дефектов в relo-list, очищаем сам relo-list, запрещаем обновление журналов SMART. После такой модификации накопитель не будет выполнять процедуры оффлайн сканирования и обновлять журналы SMART. На этом этапе производим оценку качества чтения каждой из головок в зонах разной плотности записи. Тест подтверждает пригодность оригинального БМГ для вычитывания данных. Читаем 0 сектор.


рис. 2

Обнаруживаем, что в нем содержатся записи для трех разделов.

По смещению 0x00000800 (2048) секторов располагается первый раздел Linux RAID (0xFD), размер раздела 0x00064000 (409 600) секторов.

По смещению 0x00064800 (411 648) секторов располагается второй раздел Linux RAID (0xFD), размер раздела 0x39DC8000 (970 752 000) секторов.

По смещению 0x39E2C800 (971 163 648) секторов располагается третий раздел linux swap (0x82), размер раздела 0x00400000 (4 194 304) секторов.

Анализ содержимого суперблоков первых двух разделов показывает, что они состояли в массивах RAID 1 и в каждом массиве содержит по одному разделу c Ext4. Выполнив попытку чтения метаданных файловой системы на большом разделе, обнаруживаем, что имеются затруднения в чтении.

На этом первичные диагностические мероприятия завершены, и их результат сообщается клиенту, также сообщается ценовая ниша услуги от 250 до 350 белорусских рублей и срок выполнения около 2-3 рабочих дней (исключительно в дневное время, так как накопитель требует постоянного наблюдения). Если необходимо выполнять работы во внеурочное время для сокращения сроков, то это возможно, но это прямо отразится на стоимости. План работ: модификация микрокода накопителя, локализация дефектных зон, чтение стабильных зон, анализ метаданных файловых систем на копии, вычитывание недостающих метаданных из проблемных зон, повторный анализ и построение цепочек нужных файлов для вычитывания из проблемных зон, при необходимости мероприятия по анализу регулярных выражений в областях, не занятых файлами, и возможные реконструкции поврежденной файловой системы.

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

14 июня в начале рабочего дня, данный клиент вновь пришел к нам и сообщил о том, что пытался многократно скопировать образ из накопителя используя dd. Поначалу винчестер периодически зависал, но после выключения и повторного включения снова виделся в системе и позволял продолжать копирование, но теперь накопитель пропал из системы, и выключение-включение более не помогает, а потом при очередной попытке включения из гермоблока стало доноситься какое-то жужжание.

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

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

15 июня в середине рабочего дня снова появляется данный клиент (он же системный администратор), но уже не один, а в сопровождении своего прямого руководителя. Сходу была озвучена претензия, что после наших диагностик накопителю стало намного хуже, что он теперь стучит и не определяется в BIOS. На этом моменте останавливаем монолог системного администратора и говорим, что мы готовы принять письменную претензию и дать на нее ответ в установленный законом срок, но прежде, чем переходить к ведению диалога в подобном русле, давайте проведем визуальный осмотр накопителя при Вас и также сравним отличается ли его внешний вид от того, что был, а также при необходимости просмотрим видеозапись вчерашнего дня и установим было ли что-либо в наших действиях, что могло серьезным образом усугубить ситуацию. Системный администратор хотел было начать перечить, но в диалог вмешался его руководитель, который велел системному администратору выложить жесткий диск на стойку.

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

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

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

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

В условиях ламинарного бокса было произведено вскрытие накопителя. Повреждения БМГ были заметны визуально и даже не требовали снятия для осмотра под микроскопом. Но фотофиксация была сделана.


рис. 3

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

Таким образом, вместо заурядной задачи с вычитыванием накопителя с дефектами, из-за особого усердия системного администратора имеем задачу, где необходимо выполнить пересадку БМГ и перспективы весьма туманны, так как имеются радиальные царапины в начале диска. Служебная зона данного накопителя находится в самом начале пластины т.е. в зоне с царапинами.


рис. 4

Обратим внимание, как изувечен край пластины оборванными слайдерами (зона повреждений примерно 0,1-0,3мм, из-за увеличения кусок окружности вырождается почти в прямую). Благо, что в этом месте при сходе с рампы у исправного БМГ слайдеры находятся еще достаточно высоко, поэтому эти самые сильные повреждения пластины угрозы не представляют.

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

Приступая к работе, производим подбор нескольких комплектов БМГ от накопителей-доноров с учетом близости адаптивных параметров, чтобы получить максимально устойчивое чтение. Обеспыливаем гермоблок пациента и производим процедуры перестановки БМГ от накопителя донора с помощью специализированного инструмента.


рис. 5

Собрав накопитель, выполняем пробный старт. Слышен звук раскрутки вала, прохождение калибровочного теста. Какие-либо подозрительные звуки отсутствуют, по этой причине не прерываем процедуру инициализации и ожидаем порядка 40 секунд до появления готовности к обмену данными.


рис. 6

Запрашиваем паспорт накопителя и получаем пустышку, что свидетельствует о том, что накопитель не смог загрузить из служебной зоны все модули, которые необходимы для старта. Анализируем версию кода в ПЗУ накопителя и подбираем подходящий оверлей из нашей базы данных микропрограмм скопированных из накопителей. После загрузки его в память накопителя получили возможность полноценно читать и анализировать содержимое служебной зоны. По результатам проверки целостности служебной зоны нечитабельными оказались 0x11 (основной оверлей), 0x31 – транслятор, 0x32 – relo-list, 0x33 – P-list, 0x34 – G-list, 0x43 – адаптивные параметры, а также модули, ответственные за работу SMART.

Производим посекторную вычитку наиболее критичных модулей. P-list прочитался с небольшим количеством дефектов, расположение которых достаточно далеко от начала модуля. Аналогичная картина с модулем адаптивных параметров. Модули транслятора, G-list, relo-list оказались нечитабельными на 100%. Подобные повреждения модулей случаются при работе накопителя с не совсем исправными головками при попытке переписать модуль микропрограммой накопителя.

Для восстановления модуля транслятора записываем все необходимое, полученное из служебной зоны пациента, в накопитель-донор, в том числе и реконструированные 0x33 и 0x43. Выполнив пересчет транслятора с учетом P-list получим оригинальный 0x31 модуль за счет работы самой микропрограммы накопителя. Информация о скрытых дефектах в модуле 0x34 безвозвратно потеряна, поэтому создадим модуль пустышку без записей. Аналогичное действие выполним и с модулем 0x32.

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

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

Создаем задачу посекторной копии на другой накопитель в Data Extractor и выполняем процедуру построения карты мини зон. Учитываем, что при обследовании обнаруживались царапины в начале пластины, основное чтение в UDMA режиме начнем с конечных зон.


рис. 7

Есть проблемы с чтением в границах swap раздела, но их мы игнорируем, так как раздел представляет весьма малую ценность. В границах основного второго радела чтение идет без нареканий до 57 89х ххх сектора, затем начинают появляться первые нестабильности.

Изменим чтение с UDMA режима на PIO для лучшего контроля процесса чтения и произведем вычитку метаданных файловой системы (Ext4) второго раздела. Завершив этут операцию на 99,99% перейдем к чтению мини зон с коротким таймаутом и прыжком 10 000 секторов в случае нестабильности. Данная мера позволила нам дочитать более 85% от непрочитанного объема.

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

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

В процессе проведения работ Заказчику пересылались отчеты о поврежденных файлах после каждой деградации донорского БМГ и согласовывалось использование каждого дополнительного донора. При использовании третьего динамика чтения была малозаметной, по этой причине было принято решение о прекращении дальнейших попыток получить оставшиеся данные из дефектных зон. Удалось получить более 95% всех файлов (и более 99,5% согласно основному техническому заданию). Данный результат удовлетворил Заказчика.

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

Следующая публикация: Экономия на спичках или восстановление данных из скрежещущего HDD Seagate ST3000NC002-1DY166
Предыдущая публикация: Неглубокое погружение или восстановление данных с жесткого диска после затопления офиса
Tags:
Hubs:
+90
Comments 135
Comments Comments 135

Articles