Медицинские учреждения с государственной формой собственности постоянно испытывают недостаток финансирования из бюджета. Поэтому план закупок дорогостоящего медицинского оборудования составляется таким образом, чтобы исключить все возможные дополнительные расходы. Но в погоне за экономией из вида упускаются вполне очевидные любому системному администратору вещи.
Так случилось в одной из больниц, где рентгеновский кабинет оснащен современным оборудованием, и стоимость одного только рентгеновского аппарата превышала 100 000$. Важный момент, что при реконструкции кабинета в расчет бралась только закупка непосредственно самого оборудования. Всякие «излишества» в виде ПК врача-рентгенолога и реализации системы хранения данных пациентов в этот расчет не вошли, и больнице было предложено за собственные средства приобретать все остальное, что необходимо для работы кабинета.
рис. 1
Собственных средств больницы хватило лишь на приобретение ПК для врача-рентгенолога с единственным жестким диском Seagate Constellation CS ST3000NC002-1DY166 емкостью 3 Тб. Первоначально планировалось это использовать как временное решение, а далее, когда появятся «свободные деньги», реализовать планы по созданию системы резервного копирования.
Но планам не суждено было сбыться. Денег больнице по-прежнему катастрофически не хватало, и была масса более приоритетных задач. В итоге, временное решение стало постоянным. Шли дни, на жестком диске накапливались данные пациентов, причем в некоторых случаях от этих данных могла зависеть человеческая жизнь.
Спустя три с половиной года грянул гром. Во второй половине дня врач заметил, что компьютер начал «задумываться», и привычные операции (просмотр и сохранение рентгеновских снимков) стали занимать значительно больше времени, чем обычно, и с каждым часом ситуация усугублялась до момента, когда продолжение работ стало невозможным, и пришлось прервать прием пациентов.
Технический персонал больницы в лице единственного системного администратора, работающего на ½ ставки, смог лишь констатировать, что накопитель неисправен. После нескольких неуспешных попыток запуска программ автоматического восстановления накопитель начал постукивать, в связи с чем администратор принял решение остановиться и сообщить главврачу о том, что восстановить данные он не сможет.
С такой симптоматикой накопитель был доставлен в нашу лабораторию восстановления данных. Seagate Constellation CS ST3000NC002-1DY166 семейства Grenada. Жесткие диски этого семейства продавались весьма массово, и в связи с высокой распространенностью повидать их смогли во многих лабораториях восстановления данных. Не только нами, но и многими другими лабораториями был зафиксирован факт, что диски данного семейства при выходе из строя нередко оказываются с сильно поврежденным БМГ и запиленными пластинами.
рис. 2
На рис. 2 показан типичный случай разрушения поверхностей пластин, также показано загрязнение в труднодоступных местах. Как бы ни было сложно, но эту пыль настоятельно рекомендуется удалять до вскрытия накопителя, так как при вскрытии часть ее обязательно попадет в гермоблок.
Причины подобного явления волновали многих. Выдвигалось множество версий, некоторые звучали достаточно убедительно. Например, одна из распространившихся версий, опубликованная на Habrahabr "Если Seagate запылился…", гласила, что основной причиной начала деградационных процессов является попадание пыли из-за неподходящего уплотнителя между контактной колодкой и корпусом БМГ.
У этой версии есть недостатки. При обследовании немалого числа накопителей данного семейства с разрушениями на разных стадиях не подтверждается неплотное прилегание уплотнителя между контактной колодкой и корпусом жесткого диска. В ситуациях, где разрушение только-только началось, произошел неполный отказ одной или нескольких головок, но окончательного разрушения пластин (запиливания) еще не произошло, не обнаруживается признаков пыли под этим уплотнителем, что ставит версию под сомнение. Также не стыкуется с этой версией тот факт, что разрушение начинается не всегда с нулевой головки, хотя при попадании пыли снизу накопителя было бы логичным, чтобы деградировала в первую очередь именно нулевая головка и поверхность пластины. Точнее, деградационные процессы по нулевой головке начинаются не чаще процессов деградации по остальным головкам.
Современные накопители способны управлять высотой полета слайдеров над поверхностью пластин посредством нагревательного элемента и Seagate Grenada не является исключением.
рис. 3 (рисунок заимствован из публичного документа)
Анализ работы системы динамического изменения высоты полета (DFH) показывает, что при некоторых условиях возможно получить контакт слайдера с поверхностью, что в итоге спровоцирует начало деградационных процессов.
На основании этого анализа также можно дать рекомендацию ни в коем случае не менять платы между накопителями данного семейства без переноса ПЗУ, так как попытки старта с чужой платой (с чужими адаптивными параметрами в ПЗУ) могут привести к контакту слайдеров с поверхностью пластин. Тем более в накопителях Seagate F3 архитектуры попытки старта с чужим ПЗУ обречены на провал.
Когда мы видим, что к нам поступает Seagate Grenada, который со слов клиента начал постукивать, то диагностические мероприятия начинаем с обеспыливания накопителя и вскрытия в ламинарном боксе. Снимаем БМГ, фильтр рециркуляции воздуха и тщательно обследуем под микроскопом.
В нашем случае ярко выраженного повреждения пластин не было, фильтр рециркуляции воздуха не содержал в себе признаков металлических частиц, проблему выдавали едва заметные царапинки на слайдере №2. Остальные слайдеры видимых повреждений даже при сильном увеличении не имели. К сожалению, возможностей камеры микроскопа, вставляемой вместо одного из окуляров недостаточно, чтобы показать едва различимые повреждения слайдера.
Зная о рисках лавионообразного разрушения поверхности пластины при попытке чтения поверхности, над которой обнаруживается поврежденный слайдер, принимаем решение о физическом удалении поврежденного слайдера и подвески из БМГ. Попытка использовать оригинальный БМГ предпринимается с целью чтения остальных зон исправными оригинальными головками, так как адаптивные параметры накопителя для них подходят идеально. Получить устойчивое чтение донорскими головками не всегда возможно.
Выполняем процедуру сбора накопителя с одним физически удаленным слайдером и подвеской. Так как при физическом отсутствии одной из головок накопитель не сможет пройти процедуру калибровки, то необходимо модифицировать карту головок в ПЗУ, чтобы обойти этап калибровки по головке №2. Для этого карту головок в ПЗУ 0, 1, 2, 3, 4, 5 меняем на 0, 1, 1,3, 4, 5. Перед тем, как записывать модифицированное ПЗУ, создадим несколько резервных копий оригинального с обязательным сравнением результатов чтения с предыдущим.
С модифицированным ПЗУ данный накопитель вышел в готовность без лишних тревожных звуков.
рис. 4
Вносим изменения в настройки накопителя в ОЗУ: отключаем все процедуры оффлайн сканирования и автореаллокации при чтении и записи. Проверяем способность данных головок записывать на модуле, который не используется накопителем во время работы. Удостоверившись, что данная процедура отработала без нареканий, модифицируем модуль параметров, чтобы при дальнейших перезапусках накопителя не происходило старта нежелательных процедур.
Читаем содержимое 0 сектора и обнаруживаем там чьё-то упущение. На 3 ТБ диск с эмуляцией сектора 512 байт использовалась классическая таблица разделов вместо положенной GPT. На диске присутствуют три раздела.
рис. 5 — Таблица разделов
Первый раздел NTFS (0x07) имеет статус активного и начинается с 0x00000800 (2048) сектора, размер 0x00032000 (204 800) секторов.
Второй раздел NTFS (0x07) начинается с 0x00032800 (206 848) сектора, размер 0x06175800 (102 193 152) секторов.
Третий раздел NTFS (0x07) начинается с 0x061A8000 (102 400 000) сектора, размер 0xF9E58000 (4 192 567 296) секторов.
Заглянем в сектор 0x100000000 (4 294 967 296). Он целиком заполнен нулями, признаки таблицы разделов или загрузочного сектора раздела отсутствуют.
Предварительно можно сделать вывод, что данный диск использовался только в границах первых 2ТБ, оставшиеся 794,52ГБ не использовались в процессе эксплуатации.
Создаем задачу посекторного копирования в Data Extractor, строим карту зонного распределения без учета зон головки №2, так как самой головки нет, а вместо нее обманка в карте.
рис. 6 — Карта мини зон
Процесс чтения идет без особых затруднений, и в течение нескольких проходов получаем начитанными 4 846 ххх ххх секторов их 5 860 533 160. Непрочитанными по головкам 0, 1, 3, 4, 5 после нескольких операций перечитки осталось 72 сектора (36Кб), и все они сосредоточены на поверхности, читаемой головкой №5. Учитывая, что чтение было стабильным, то были прочитаны все зоны после 4 294 967 296 сектора. Предположение о том, что диск частично не использовался, получило подтверждение.
Исходя из анализа фрагментов прочитанных файловых систем по второму и третьему разделам, были установлены их роли. Второй раздел играл роль системного диска, и пользовательские данные там отсутствовали. На третьем же разделе, наоборот, были только пользовательские данные в виде файловой базы данных снимков пациентов.
Для полноценного чтения нам необходимо произвести пересадку донорского БМГ. Учитывая, что это Seagate Grenada, то выбор донора осуществляем среди аналогичных накопителей, принадлежащих этому семейству, с одинаковой ревизией коммутатора-предусилителя и близкими адаптивными параметрами. ST3000NC002, ST3000DM001 являются представителями одного семейства. Подобрав подходящий донор, выполним пересадку БМГ.
рис. 7
Записываем в винчестер-пациент ПЗУ с оригинальной картой головок обратно. При подаче питания слышим несколько неуверенное прохождение калибровочного теста, но, тем не менее, микропрограмма загружена, и система трансляции проинициализирована. Тестируем способность чтения головки №2 в зонах разной плотности. Удостоверившись, что чтение присутствует в разных зонах, приступаем к чтению пользовательских данных.
Просматриваем содержимое загрузочного сектора третьего раздела.
рис. 8 — Загрузочный сектор NTFS
По смещению 0x0B располагается WORD 0x0200, что означает, что размер сектора 512 байт.
По смещению 0x0D располагается BYTE 0x08, что означает, что в одном кластере 8 секторов, размер кластера вычисляется перемножением размера сектора на количество секторов в кластере, то есть 0x0200*0x08=0x1000 (4096) байт.
По смещению 0x30 располагается QWORD 0x00000000000C0000 (786 432) в нем указан номер первого кластера MFT.
Анализируем первую запись MFT, строим карту цепочек MFT третьего раздела и выполняем чтение недостающих фрагментов. MFT прочитана успешно, что позволяет отправить накопитель в спящий режим и провести полный анализ файловой системы на копии, чтобы иметь возможность построить карту расположения необходимых данных. Читать все подряд в подобной ситуации слишком большая роскошь, так как есть риски, что при чтении поврежденной поверхности будут продолжаться дальнейшие деградации.
На основании данных анализа строим цепочки расположения нужных файлов по головке №2 и объединяем их цепочки, которые расположены в границах одной мини-зоны. После данного действия немного добавится лишних данных, чтение которых не указано в техническом задании. Но подобный подход позволит пропускать целиком мини-зону в случае обнаружения нестабильного поведения, что повышает шансы на успешное вычитывание большего количества данных.
Далее следуют этапы локализации крупных дефектообразований на поверхности, читаемой головкой №2, и чтение с пропуском самых проблемных зон. Зоны с большим содержанием дефектов читаются в последнюю очередь, так как их чтение сопряжено с рисками окончательной деградации накопителя без дальнейшей возможности чтения данных.
На протяжении двух суток с постоянными изменениями сценариев чтения удается завершить вычитывание более, чем на 99,9% необходимых цепочек, и на этом положительная динамика останавливается, а на дефектных зонах появляется запил, подобный тому, что на рис. 2.
рис. 9 — Вид запила под микроскопом
К сожалению, иных вариантов чтения уже не было, это был последний шанс прочитать хоть что-то из поврежденных зон. При формировании отчета о файлах, расположенных в проблемных зонах, наблюдаем относительно неплохую картину: из более 198 000 файлов непрочитанными остаются чуть менее 2000. Но, отходя от сухих цифр, в которых рапортуется о 98,9% результате, приходит осознание того, что за этими чуть менее 2000 файлами стоит несколько сотен живых людей, чьи результаты посещения рентген-кабинета канули в небытие из-за мелочной экономии. Очень хочется верить, что утерянные результаты не были критически важными, и их потеря не отразилась на чьей-то жизни.
При выдаче данной информации была проведена консультация системного администратора, каким образом следить за состоянием жестких дисков. Накопители, подобные этому, не деградируют в одно мгновение. Если регулярно проверять показания SMART, контролировать хотя бы необходимый минимум атрибутов, а не ждать, когда накопитель начнет рапортовать «SMART status – BAD» на команду 0xB0 0xDA, то в большинстве случаев можно заметить надвигающуюся угрозу и своевременно предпринять меры. Разумеется, существуют иные проблемы, которые развиваются куда более стремительно, и регулярное наблюдение за показателями SMART ничем не поможет. Учитывая вероятность развития неблагоприятных событий, стоит хорошо продумать систему резервного копирования, причем контроль ее работы должен осуществляться не только единственным системным администратором.
Хочется надеяться, что после этого происшествия в данной больнице хоть что-то изменится в политике хранения данных пациентов, и подобные ситуации не повторятся впредь.
Автор: hddmasters