Программа для диагностики жёстких дисков R.tester

Бесплатная программа для восстановления файлов R.saver

Неофициальный блог R.LAB, заходите!

Восстановление данных
восстановление данных
Звоните нам в Москве: +7(495) 230−1000
28.10.2020, 23:03:13 *
Добро Пожаловать, гость. Пожалуйста войдите или зарегистрируйтесь, если хотите стать полноправным участником форума. Не получили активационное письмо?

Страницы: [1]
  Печать  
автор Тема: MHHD похерил файлы  (прочитано 2736 раз)
Пинат
Newbie
*

Репутация: 0
сообщений: 3


просмотр профиля
« было: 26.01.2016, 02:14:10 »

Здравствуйте! Случилась следующая беда: Решил прогнать винт в MHDD, в результате было обнаружено достаточное количество СОФТ-БЭДов. Решил вместо ремапа попробовать их затереть. Область для сканирования была выбрана от 0 до 70000000 секторов, из общего колличества 1.95x.xxx.xxx . Если я правильнопонимаю, то это примерно 35gb из общего 1TB. В этой области у меня располагался системный раздел с полетевшей ситемой. Но в результате я обнар ужил что  так же пропал и второй раздел с файлохранилищем...

Прошу совета, что можно попробовать, дабы реанимировать разделы и содержимое? Заранее благодарен!!!
Авторизирован
OLiMP
Global Moderator
Hero Member
*

Репутация: 143
сообщений: 2604

HDD Research Group member


просмотр профиля WWW
« Ответить #1 было: 26.01.2016, 12:06:55 »

Если затирались только первые 35 GB от начала диска, а раздел с нужными данными был дальше, то он никуда не делся. Исчезла информация о разделах, она хранится в MBR (сектор ноль, который Вы затёрли). Дальше читаем статью простое восстановление данных, сканируем диск извлекаем данные на другой носитель например при помощи нашей программы R.Saver . Так же можно при помощи дискового редактора найти начало и размер интересующего раздела и прописать информацию о разделе в MBR, но это требует знаний об устройстве файловых систем. Для автоматического поиска и записи информации о разделах существует программа TestDisk, можно попробовать воспользоваться ей.
« Последняя правка: 26.01.2016, 12:09:27 от OLiMP » Авторизирован
Пинат
Newbie
*

Репутация: 0
сообщений: 3


просмотр профиля
« Ответить #2 было: 26.01.2016, 17:45:10 »

Спасибо! Насчет восстановления загрузочного сектора ясно, но как быть со структурой каталогов? Прогнал R-Studio, файлы нашлись, но у них слетели названия и дерево папок. Есть ли шансы восстановить эти данные без дополнительного бэк-апа?
Авторизирован
OLiMP
Global Moderator
Hero Member
*

Репутация: 143
сообщений: 2604

HDD Research Group member


просмотр профиля WWW
« Ответить #3 было: 26.01.2016, 23:34:52 »

Если по нужному разделу очистка диска не шла то структура папок должна была сохраниться. Если же названия файлов и папок разрушены то имеются какие то проблемы в информации о файлах в разделе. Возможно MHDD затёрла информацию о файлах на нужном разделе. Обычно информация о файлах располагается в 3 GB от начала раздела NTFS. Сканируйте весь диск той же R-Studio и извлекайте файлы в том виде а каком получится.
Авторизирован
Wlad
Newbie
*

Репутация: 0
сообщений: 2


просмотр профиля
« Ответить #4 было: 27.01.2016, 19:17:42 »

Если по нужному разделу очистка диска не шла то структура папок должна была сохраниться.
Может она и сохранилась, но в связи со смещением позиции раздела после мапа бэдов находится абсолютно не по месту, и все файлы тоже смещены по отношению к указанным в файловых таблицах. Если бы перед тем как перезаписывать поляну позаботились отключить автономное замещение дефектов то такое было бы невозможно, но поскольку MHDD не умеет работать с служебной областью то естественно никто ничего не отключал.  А R-Studio как инструмент ниже всякой критики, и при использовании его "в автоматическом режиме" только на черновое восстановление и способен.
Авторизирован
OLiMP
Global Moderator
Hero Member
*

Репутация: 143
сообщений: 2604

HDD Research Group member


просмотр профиля WWW
« Ответить #5 было: 27.01.2016, 20:41:59 »

Автономное замещение секторов (ремап) в логическом пространстве данные не меняет. К примеру первый резервный сектор находится по адресу LBA 625000000. У Вас не читается сектор по адресу LBA 1000, он замещается на сектор по адресу LBA 625000000. То есть физически используется другой сектор. При обращении системы к сектору по LBA 1000 диск автоматически уходит по адресу LBA 625000000 и отдаёт данные из этого сектора. Если ремап прошёл корректно то и данные из сектора по  адресу LBA 1000 были скопированы в сектор по адресу LBA 625000000 . Другое дело что ремап происходит при записи, и если в сектор по адресу LBA 1000 не удалось записать данные то их копия сразу же кладётся самим диском в сектор по адресу LBA 625000000 . Если же у Вас данные в секторе по адресу LBA 1000 уже не читаются то никакой ремап их восстановить не поможет.

MHDD при сканировании поверхности с включённым режимом ремап делает следующее. При нахождении хотя бы одного битого сектора затирает паттерном блок из 256 секторов, и те сектора которые не смогли записаться переносятся самим диском в резервную область. Так что ничего никуда не съезжает. Но вот данные при таком скрытии дефектов убиваются основательно. К примеру не читается один сектор в области MFT, выполняем в MHDD сканирование поверхности в функцией ремап и получаем 128 убитых записей о файлах, поскольку информация о размещении файла хранится в двух секторах, а затирается паттерном 256 секторов.

R-Studio вполне нормальный инструмент, и способен он не только на черновое восстановление. Вот только если у Вас в метаданных дырка то и информации о файлах не будет. Или наоборот MFT дублируется в большом количестве (Windows это очень любит делать начиная с Vista), то в таком случае файлов с одинаковыми именами будет очень много. Правильной записью о файлах будет всего одна. И выискивать среди кучи одинаковых записей одну валидную ой какая не благодарная работа.
« Последняя правка: 27.01.2016, 20:49:18 от OLiMP » Авторизирован
Пинат
Newbie
*

Репутация: 0
сообщений: 3


просмотр профиля
« Ответить #6 было: 28.01.2016, 00:25:50 »

Огромное спасибо всем ответившим! К моему счастью R-Studio всё-таки вуыдила нужный мне раздел с уцелевшей структурой каталогов. Теперь сижу, раскидываю 830GB. спасенного добра по бэкапам. Затем хочу затереть весь диск в Виктории, дабы выяснить ситуацию с софт-бэдами, которые собственно и подтолкнули к безалаберным экспериментам.
Авторизирован
OLiMP
Global Moderator
Hero Member
*

Репутация: 143
сообщений: 2604

HDD Research Group member


просмотр профиля WWW
« Ответить #7 было: 28.01.2016, 08:57:20 »

После того как пройдёте записью по диску посмотрите атрибуты SMART, вполне возможно что дефекты реальные. Показатели SMART просядут в таком случае. И если они ухудшатся то в дальнейшем использовать диск не рекомендуется.
Авторизирован
Wlad
Newbie
*

Репутация: 0
сообщений: 2


просмотр профиля
« Ответить #8 было: 28.01.2016, 11:59:02 »

Автономное замещение секторов (ремап) в логическом пространстве данные не меняет. К примеру первый резервный сектор находится по адресу LBA 625000000. У Вас не читается сектор по адресу LBA 1000, он замещается на сектор по адресу LBA 625000000. То есть физически используется другой сектор. При обращении системы к сектору по LBA 1000 диск автоматически уходит по адресу LBA 625000000 и отдаёт данные из этого сектора. Если ремап прошёл корректно то и данные из сектора по  адресу LBA 1000 были скопированы в сектор по адресу LBA 625000000 . Другое дело что ремап происходит при записи, и если в сектор по адресу LBA 1000 не удалось записать данные то их копия сразу же кладётся самим диском в сектор по адресу LBA 625000000 . Если же у Вас данные в секторе по адресу LBA 1000 уже не читаются то никакой ремап их восстановить не поможет.
Ну а третье дело когда сектор по адресу LBA 1000 переносится системой самодиагностики самого харда в G-List и пересчитывается транслятор. Хотите сказать что ситуация гипотетическая? Нет, просто редкая но однако встречающаяся, и для этой ситуации в PC3000 предусмотрена виртуальная трансляция. Поэтому и не рекомендуется делать всяческие "ремонтные" действия с накопителем, с которого нужны данные - сперва скопируйте, а потом записывайте, лечите BAD-ы. И перед копированием данных отключите всю самодиагностику у харда.
Вообще хард имеющий повреждения поляны нельзя назвать исправным накопителем, и соответственно к нему полностью применимо требование создание копии данных перед началом работ по ремонту. И работа с этой копией в режиме read only, если уж хочется играть с такими программами как R-Studio.
А для конкретной ситуации R-Studio с его полным сканом поляны был избыточен. Затерта partition table в LBA0, но boot NTFS второго раздела никуда не делась - иначе R-Studio ничего бы и не нашел
с уцелевшей структурой каталогов.
И для хозяина диска который имел полные данные о том какого размера были разделы на харде "до того как" нужно было просканить на предмет нахождения boot NTFS либо область в районе предполагаемого места начала раздела, либо в его конце, посмотреть в найденом boot значение hidden sectors и соответственно сделать в LBA0 свою PT где relative sectors равно hidden sectors найденого boot, и c количеством секторов как в total sectors обнаруженного boot. Дело - ровно на 5 минут. И заодно все предположения по смещению координат поляны проверяются.
Авторизирован
OLiMP
Global Moderator
Hero Member
*

Репутация: 143
сообщений: 2604

HDD Research Group member


просмотр профиля WWW
« Ответить #9 было: 28.01.2016, 12:25:16 »

Транслятор не пересчитывается при самотестировании накопителя и скрытии дефектов в таблицу растущих дефектов. Учёт переназначенных секторов идёт на лету. Виртуальный транслятор нужно использовать в тех случаях когда данные смещены, например из за внесения дефектов в заводские а не растущие листы. Сам по себе диск этого сделать не может. Это может сделать только пользователь имеющий доступ к служебной информации накопителя, например при помощи того же оборудования PC3000. Современные диски при внесении нового дефекта в заводской лист вообще перестают читать что либо за областью нового дефекта.

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

Найти и прописать информацию о разделах дело небольшого количества времени, но для этого нужны знания об устройстве файловых систем, которых у большинства пользователей нет. Равно как нет и профессионального оборудования. Посему человеку было проще пролечить "софтбэды", это не правильный и опасный подход, в первую очередь для данных пользователя, да и накопитель может выйти из строя если дефекты окажутся реальными, а область с дефектами будет иметь серьёзные повреждения на поверхности пластин, просканировать весь диск в той же R-Studio, которая обнаружила раздел, и успешно извлечь данные.
« Последняя правка: 29.01.2016, 08:05:23 от OLiMP » Авторизирован
Страницы: [1]
  Печать  
 
Перейти в раздел:  

Яндекс.Метрика
Восстановление данных - R.LAB
Москва, Коровий Вал, д. 1А  (схема проезда). Телефон: +7 (495) 230−1000; e-mail: 
Другие города »