В наше время все более широкое распространение получает программное обеспечение позволяющее восстанавливать не только пользовательские данные, но и "здоровье" самих накопителей. Оно уже не требует от пользователя каких-либо специфических знаний и умений. Глядя на рекламные заявления производителей такого ПО у многих пользователей часто складывается мнение, что проблемы любой сложности можно решить самостоятельно или пригласить знакомого, который в состоянии переустановить Windows и запустить программу автоматического восстановления данных. Но так ли все просто, как представляется в рекламе? И действительно ли можно решить любые проблемы с накопителем несколькими кликами мышкой?
Вот один из примеров подобной истории...
Однажды пользователь обратил внимание, что его ПК начал задумываться и отзываться с некоторыми задержками. Он не придал особого значения этому факту, предположив, что виной всему ОС Windows 10, в которой в данный момент запущено слишком много процессов, и что после ближайшей перезагрузки все само собой нормализуется. Доработав день, пользователь отключил компьютер и покинул офис. Наутро, включив офисный компьютер, обнаружил, что после прохождения стандартных процедур BIOS компьютер начал загрузку Windows, но так и не смог ее завершить ни через 5 минут, ни через 10. Черный экран и горящий индикатор активности жесткого диска и никакой иной активности. Пользователь попытался несколько раз отключить и включить компьютер, но ничего не изменилось. Далее последовала попытка загрузки с «Live CD» с целью скопировать данные, но все по-прежнему обернулось черным экраном и непрерывно горящим индикатором активности на системном блоке. Пользователь не хотел сдаваться, поэтому, вооружившись крестовой отверткой, снял боковые крышки системного блока и извлек HDD. Визуальный осмотр не выявил каких-либо неисправностей, посему было принято решение подключить накопитель к другому компьютеру и переписать данные. И эта попытка завершилась неудачей, так как подключенный к SATA порту накопитель также препятствовал загрузке операционной системы.
Следующим шагом был вызов приходящего системного администратора, которому было поведано о проблемах с накопителем. Системный администратор увидел, что при включении накопитель отзывается на запрос со стороны BIOS и отдает паспортные данные (иными словами «определяется в BIOS). Загрузил DOS и запустил диагностическую утилиту MHDD, оценил показания SMART и попытался сканировать накопитель. Заметив, что сканирование местами замедляется, администратор прервал процесс. Далее заявил, что вопрос серьезный, но у него громадный опыт по восстановлению данных и что в течение нескольких дней с использованием Linux он все решит. Но спустя несколько дней вопрос не решился и, более того, усугубился. Накопитель перестал отвечать на запрос BIOS при включении компьютера. Системный администратор сообщил владельцу накопителя о том, что у данного диска кроме всех его проблем неисправна плата контроллера, а так как у него нет точно такого же контроллера, то он ничего сделать не сможет.
рис. 1
Итак, накопитель Western Digital 4ТБ WD4000FYYZ-01UL1B1 поступил на восстановление данных в нашу лабораторию. Данный диск относится к Enterprise-class, что подразумевает, что его производительность и надежность должны быть на более высоком уровне, нежели у накопителей более низкого класса. Конструктивно этот HDD представляет собой устройство с 5 пластинами и 10 магнитно-резистивными головками. Сердцем печатной платы (PCB) 2060-771822-002 установленной на этом накопителе является микроконтроллер (MCU) Marvell 88i9346.
Любой жесткий диск, поступающий в лабораторию восстановления данных, должен быть обследован прежде, чем посчитается допустимым подать на него питание. Первичный комплекс проверок подразумевает: осмотр на предмет нарушения герметичности гермоблока, визуальный контроль PCB на наличие механически и термических воздействий, обследование с помощью мультиметра для установления, имеет ли место короткое замыкание в цепях 5 и 12 вольт. Также оценивается сопротивление обмоток двигателя для установления обрывов либо межвиткового замыкания. В случае этого накопителя осмотр не показал ничего подозрительного.
Подключив к порту программно-аппаратного комплекса (ПАК) PC3000 Express, подали питание. Накопитель начал раскрутку вала. Был слышен звук прохождения калибровки, что говорит о корректном поведении контроллера и способности головок обнаруживать серворазметку. Но после калибровки и загрузки микропрограммы в регистрах накопитель по прежнем держал флаг BUSY и не хотел отвечать на какие-либо запросы по интерфейсу.
рис. 2
Если прислушаться, то слышно, что некая активность имеет место. Отключаем питание, используем 3 перемычки для перевода накопителя Western Digital Marvell (ROYL) в KERNEL режим. В данном режиме прочитаем содержимое ПЗУ, отдельно выделим модули ПЗУ. Из всех возможных методов получения доступа к служебной зоне рассмотрим один из самых простых, который подразумевает наличие ПЗУ, сервооверлея (5Сh) и главного оверлея (11h) другой версии, но от накопителя того же семейства. Для этого в донорское ПЗУ поместим модули ПЗУ оригинального накопителя: 0Ah (карта головок), 0Bh (каталог модулей ПЗУ), 0Dh (конфигурация), 20Bh (каталог модулей ПЗУ), 30h (транслятор служебной зоны), 47h (адаптивные параметры служебной зоны), 4Fh (в некоторых семействах в этом модуле так же содержатся адаптивные параметры). Модификации необходимы, чтобы у нас была точная координата каталога модулей в служебной зоне, а также учитывались дефекты, скрытые с момента прохождения процедур selfscan при изготовлении накопителя. Модифицированное ПЗУ записываем в накопитель.
Выключим накопитель, удалим перемычки и запустим в нормальном режиме. После прохождения калибровочного теста микропрограмма жесткого диска обнаружит, что оверлей в служебной зоне не соответствует версии ПЗУ и прекратит загрузку, но по регистрам (DRD и DSC) накопитель покажет готовность к взаимодействию по интерфейсу.
рис. 3
После загрузки в ОЗУ сервооверлея и основного оверлея, появляется возможность читать и записывать область служебной зоны с использованием ABA адресации. Выполним резервирование модулей микропрограммы.
рис. 4
Проведем тесты записи и чтения да каждой из головок на дорожках (треках) служебной зоны, которые не используются микропрограммой накопителя. Результат тестирования наглядно демонстрирует, что все 10 головок условно исправны. Возможность чтения и записи в служебной зоне во многих случаях позволяет выявить неисправные головки, но в то же время не гарантирует, что прошедшие тест головки смогут устойчиво читать в пользовательской зоне.
В прочитанных модулях микропрограммы оценим содержимое модуля 32h (Relo list). В исправном накопителе, где нет затруднений в чтении с поверхностей пластин, в этом модуле присутствует только стандартный заголовок модуля, а все остальные байты заполнены нулями. В нашем случае модуль практически полностью заполнен данными, что свидетельствует о том, что микропрограмма накопителя обнаружила массу мест, где есть затруднения чтения с поверхности. Особенности микропрограмм WD таковы, что процедуры контроля состояния накопителя пытаются анализировать каждое затруднение в чтении и выполняют переназначение (remap) нестабильно читаемого сектора незаметно от пользователя. При серьезном дефектообразовании или нестабильном чтении какой-либо из головок эти процедуры приводят к тому, что ресурсы накопителя целиком поглощены ими, что выражается либо в медленной реакции на команды со стороны интерфейса, либо в отсутствии реакции как таковой.
Для того, чтобы эти процедуры перестали выполняться, необходимо очистить relo list с обязательным пересчетом контрольной суммы, а также некоторые из логов SMART процедур; в настройках конфигурации накопителя в модуле паспорта (02h) отключить процедуры переназначения, запретить добавление кандидатов в дефекты в relo list, выключить процедуры SMART. Модифицированные модули записываем в копию 0 в служебную зону накопителя и удостоверяемся в их читабельности. После выполнения этих действий записываем оригинальное ПЗУ обратно в накопитель, отключаем питание и стартуем заново. В результате проведенных манипуляций накопитель после калибровочного теста и загрузки микропрограммы сообщает в регистрах о готовности к обмену данными. На запрос паспортных данных накопитель реагирует немедленно и выдает информацию о себе. Результат интерпретации данных на рис. 5.
рис. 5
Выполним операцию чтения любого сектора из пользовательской зоны. Накопитель не отверг команды и успешно прочитал сектор, что подтверждает корректную инициализацию всей системы трансляции. Как видим, диагноз неисправности платы контроллера, поставленный системным администратором, не подтвердился.
Исходя из описания проблемы пользователем и состояния оригинального relo list накопителя очевидно, что у накопителя есть проблемы с чтением с поверхностей.
Для вычитывания неисправного накопителя используем Data Extractor, являющийся компонентом полного комплекса PC3000 Express. Сформируем задачу посекторной копии на новый накопитель. Построим карту распределения мини зон между головками накопителя. Параметры чтения: режим UDMA 133, 500 миллисекунд ожидания ответа накопителя. При отсутствии ответа сценарий подачи програмного сброса, аппаратного сброса и в случаях, когда накопитель окончательно завис выключить и повтороно включить накопитель. При любой задержке переходить от чтения проблемной мини зоны к следующей.
При таком сценарии стали очевидными проблемы чтения зон головкой №8. Исключим из первичного сценария начитки зоны, которые необходимо читать восьмой головкой, и произведем чтение зон головками № 0, 1, 2, 3, 4, 5, 6, 7, 9. Чтение обязательно проводить под контролем оператора ПАК, чтобы своевременно принимать меры в случае обнаружения крупных дефектообразований, во избежания развития деградационных процессов.
Были прочитаны все мини зоны кроме зон, для чтения которых нужно использовать головку №8. Из технического задания клиента знаем, что на данном накопителе был один раздел на всю емкость, на котором использовалась файловая система NTFS. Для получения оригинальной структуры каталогов нам необходимо полностью прочитать MFT. Построив карту расположения фрагментов MFT выясняем, что один из фрагментов необходимо прочитать восьмой головкой. Изменяем параметры чтения: режим PIO 4, 2000 миллисекунд ожидания ответа накопителя, а далее аналогичный прошлому сценарий обработки потери готовности за исключением размера прыжка, который уменьшаем до 10000 секторов. С каждой итерацией уменьшаем размер прыжка и увеличиваем размер таймаута ожидания готовности. И так действуем до окончательной вычитки (или до момента, с которого прекратится положительная динамика в вычитке). В нашем случае все фрагменты MFT были прочитаны целиком. Средствами Data Extractor выполнили сканирование MFT, что дало возможность удостовериться в корректности записей и построить древо каталогов. Оценили размер папок согласно техническому заданию и подтвердили, что данный диск заполнен более, чем на 99%. Так как отсутствовали приоритеты в вычитывании данных, то продолжим последовательное чтение зон головкой №8. Вернем параметры чтения к тем, что были на первом шаге вычитывания MFT по восьмой головке. Построив карту мини зон, которые необходимо читать восьмой головкой, приступим к вычитке. Самая важная особенность профессиональных комплексов в том, что ни один сектор не приходится перечитывать дважды, что очень важно в случае проблемных накопителей. Поэтому, выполняя несколько раз сценарий чтения проблемных зон нестабильно работающей головкой, мы с каждым проходом дополняем результат начитки.
После двух рабочих дней непрочитанными остались порядка 5 000 000 секторов из 7 814 037 168, Которые локализовались c 1 230 000 000 по 1 400 000 000 сектор. Дальнейшие этапы чтения с варьированием таймаутами ожидания готовности накопителя, размерами прыжков в случае потери готовности и уточняющим чтением позволили сократить количество непрочитанных секторов до 1636. На этом положительная динамика закончилась, так как головка №8 окончательно вышла из строя. Локализация дефектов, а именно их цикличность повторения, явно демонстрировала повреждение пластины в виде небольшой радиальной царапины. Сопоставление границ дефектов с картами размещения файлов выявило 37 файлов, которые частично не дочитаны из более, чем 300 000.
Из всего вышесказанного можно сделать вывод о том, что возможности dd в LINUX сильно преувеличены, и линейное копирование, которое оно выполняет попросту неуместно в случае накопителей, имеющих повреждение пластин. В данной ситуации можно сказать, повезло, что процедуры оффлайн сканирования ввели накопитель в состояние «комы» и не позволили системному администратору окончательно вывести его из строя.
Янчарский Павел
HDD MastersМожно перечислить много причин, почему для квартиры камера видеонаблюдения может быть такой же важной, как и для улицы
В данной статье мы рассмотрим, почему прямое пополнение стало проблематичным, как беларуские и российские игроки могут
Smart Lock можно использовать с любым устройством Bluetooth, таким как Chromebook или умная колонка, но использовать
