MQ01UBD100 не определяется в системе
Модель накопителя: MQ01UBD100
Объем: 1000 ГБ
Операционная / Файловая система: Windows NTFS
Симптомы: начал тормозить, потом файловая система стала RAW
Диагностика и восстановление Toshiba Canvio
В очередной раз с желанием восстановить данные к нам обратился клиент. Описал он недуг своего hdd так: сначала начал тормозить, потом файловая система стала RAW. Когда жесткий диск показал запрос на форматирование клиент согласился и отформатировал hdd в файловую систему FAT32. Он объяснил это тем что хотел попробовать самостоятельно восстановить файлы программой r-studio но что то пошло не так. В процессе диагностики мастер сразу заметил что жесткий диск определяется в диспетчере устройств очень долго. После того как hdd появился в системе мы начали его тестировать программой victoria, у неё достаточный функционал для первичной диагностики и она к тому же бесплатная. После того как было отсканировано чуть более 1,5млн секторов появилось большое количество бэд-блоков. Для того чтобы добраться к данным нам нужно поменять контроллер на sata, это позволит нам читать диск используя активную утилиту, которая в свою очередь поможет избежать зависания hdd на бэд-блоках. Контроллер мы берём от диска того же семейства с немного отличающейся моделью – MQ01ABD100.
В нашем распоряжении есть все самое необходимое современное оборудование для решения различных задач по восстановлению данных
После перепайки ПЗУ на донорскую плату начинаем работу в dataextractor. В нем мы запускаем построение карты голов после чего запускаем чтение с помощью «активной утилиты». Так как диск был отформатирован в FAT32 хотя изначально на нем был NTFS мы запустили «быстрый анализ данных» и мы быстро нашли следы нужной нам файловой системы. Нам очень повезло что размер MFT составил всего 21мб и в них не попало повреждений, а это значит что у нас есть информация о всех файлах хранящихся на диске. Но радоваться оставалось не долго. После сканирования MFT и получения доступа к дереву каталогов стало ясно что на диске более 20 баз 1С общим объемом более 60 гигабайт. Отчаиваться было рано поэтому мы приступили к чтению, к слову оно заняло порядка суток.
При анализе карты считанных секторов стало ясно что большинство повреждений находятся на второй поверхности первой пластины. Наш мастер предположил что проблема может быть не в самой поверхности в головке. Он решил проверить свою гипотезу и установил донорский БМГ от диска с которого мы ранее взяли плату электроники. И он был чертовски прав! Поврежденные сектора в большинстве своём перечитались! После того как данные были слиты в виде файлов, выяснилось что 4 базы все же не запускаются хотя имею давольно мало повреждений. Для попытки отремонтировать эти базы мы взяли стандартную утилиту checkdbfl входящую в состав самой 1С. После исправления ошибок 3 из 4 баз открылись и выдали необходимые отчеты. Одна база к сожалению не смогла починиться, хотя клиент тоже забрал ее с целью передачи ее на ремонт программистам 1С. Можем считать что данный случай с благополучным исходом.
Так как многие клиенты не читают инструкций к программам которые они используют, очень часто при работе с программами для восстановления данных записывают данные которые отображает программа на тот же диск с которого ведётся восстановление. Это категорически неправильно! Так как данные таким образом перезаписываются и восстановить их после таких действий уже не возможно.
Всегда используйте другой накопитель для сохранения результатов работы программ для восстановления информации.
