Из Краснодара в Москву проездом прибыл мой Краснодарский представитель, и привез два принятых у клиентов поломанных жестких диска. Один из них — недавно купленный 2,5 дюймовый накопитель Hitachi HTS547550A9E384, который при обращении к нему начал завешивать систему. На нем важная для клиента информация, требующая восстановления.
Прежде чем приступать к восстановлению данных, требуется провести диагностику. Диагностика выявила интересную картину — при подаче питания диск на слух нормально рекалибруется, после окончания стартовой инициализации винчестера в регистрах состояния выставляются биты DRDY и DRSC, т.е. с виду все хорошо. Идем дальше — запрос get drive ID, чтобы оценить результаты инита драйва. Программка рапортует:
Hitachi HTS547550A9E384
S\N: J2160051EK7K9D
FW: JE3OA50B
LBA: = 268435455
LBA48: = 976773168
Total: = 500107862016 bytes (476940 MB)
UDMA-5 supported
Automatic Acoustic Management (AAM) not supported
SCT Error Recovery Control Is Supported Все отлично, вроде как. Даю команду на чтение сектора, — диск выставляет BUSY и зависает наглухо. Программный и аппаратный сброс не работают. Помогает только рестарт питания. Ладно, сбрасываю питание, решаю проверить служебную информацию. Все модули читаются без ошибок. Проверяю диск на так называемый пендинг баг — распространенная ошибка почти у всех современных дисков, когда так называемая background activity которая возникает, если адаптивные настройки по той или иной причине перестают быть на 100% валидными, или начинают деградировать сами пластины. Reallocation Status -> Off
Тут выясняется странное: диск после подачи питания сколько угодно может реагировать на ту же get ID, можно считать за один присест весь массив треков или модулей со служебки, но при любой ПОВТОРНОЙ попытке чтения, драйв виснет. Причем не важно, читается ли это служебная информация после подачи технологического ключа (super-on, супер-он команды), или читается сектор пользовательской области (опять же любой командой, хоть 0х20, хоть 0х24) — один сектор прочитали, больше до сброса питания не видать. Более того, диск после подачи питания мог стоять пять и больше минут, в течении которых можно было много раз забирать из памяти ID по запросу, по прошествии которых без проблем читался тот же самый единичный сектор, но после его прочтения, диск уходил в себя.
Подозрение логично пало на плату электроники. Из магазина был доставлен аналогичный, полностью исправный, запечатанный диск, с него снята плата, перенесено содержимое NVRAM от пациента, и заведомо рабочий контроллер прикрутили на жесткий диск, нуждающийся в реанимации. Картина осталась прежней.
HTS547550A9E для ремонта и восстановления
Плата электроники HDD HTS547550A9E
В итоге было найдено простое, но пока что необъяснимое решение: сразу после подачи питания, не давая диску прерваться, было запущено полное посекторное копирование на destination drive, которое закончилось без единой ошибки и в результате чего был получен клон поломанного HDD на диске исправном.