MHHD похерил файлы

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

Прошу совета, что можно попробовать, дабы реанимировать разделы и содержимое? Заранее благодарен!!!

Если затирались только первые 35 GB от начала диска, а раздел с нужными данными был дальше, то он никуда не делся. Исчезла информация о разделах, она хранится в MBR (сектор ноль, который Вы затёрли). Дальше читаем статью простое восстановление данных, сканируем диск извлекаем данные на другой носитель например при помощи нашей программы R.Saver . Так же можно при помощи дискового редактора найти начало и размер интересующего раздела и прописать информацию о разделе в MBR, но это требует знаний об устройстве файловых систем. Для автоматического поиска и записи информации о разделах существует программа TestDisk, можно попробовать воспользоваться ей.

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

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

[quote author=OLiMP link=topic=1916.msg9289#msg9289 date=1453840492]
Если по нужному разделу очистка диска не шла то структура папок должна была сохраниться. [/quote] Может она и сохранилась, но в связи со смещением позиции раздела после мапа бэдов находится абсолютно не по месту, и все файлы тоже смещены по отношению к указанным в файловых таблицах. Если бы перед тем как перезаписывать поляну позаботились отключить автономное замещение дефектов то такое было бы невозможно, но поскольку MHDD не умеет работать с служебной областью то естественно никто ничего не отключал.  А R-Studio как инструмент ниже всякой критики, и при использовании его "в автоматическом режиме" только на черновое восстановление и способен.

Автономное замещение секторов (ремап) в логическом пространстве данные не меняет. К примеру первый резервный сектор находится по адресу 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), то в таком случае файлов с одинаковыми именами будет очень много. Правильной записью о файлах будет всего одна. И выискивать среди кучи одинаковых записей одну валидную ой какая не благодарная работа.

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

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

[quote author=OLiMP link=topic=1916.msg9292#msg9292 date=1453916519]
Автономное замещение секторов (ремап) в логическом пространстве данные не меняет. К примеру первый резервный сектор находится по адресу LBA 625000000. У Вас не читается сектор по адресу LBA 1000, он замещается на сектор по адресу LBA 625000000. То есть физически используется другой сектор. При обращении системы к сектору по LBA 1000 диск автоматически уходит по адресу LBA 625000000 и отдаёт данные из этого сектора. Если ремап прошёл корректно то и данные из сектора по  адресу LBA 1000 были скопированы в сектор по адресу LBA 625000000 . Другое дело что ремап происходит при записи, и если в сектор по адресу LBA 1000 не удалось записать данные то их копия сразу же кладётся самим диском в сектор по адресу LBA 625000000 . Если же у Вас данные в секторе по адресу LBA 1000 уже не читаются то никакой ремап их восстановить не поможет.
[/quote] Ну а третье дело когда сектор по адресу LBA 1000 переносится системой самодиагностики самого харда в G-List и пересчитывается транслятор. Хотите сказать что ситуация гипотетическая? Нет, просто редкая но однако встречающаяся, и для этой ситуации в PC3000 предусмотрена виртуальная трансляция. Поэтому и не рекомендуется делать всяческие "ремонтные" действия с накопителем, с которого нужны данные - сперва скопируйте, а потом записывайте, лечите BAD-ы. И перед копированием данных отключите всю самодиагностику у харда.
Вообще хард имеющий повреждения поляны нельзя назвать исправным накопителем, и соответственно к нему полностью применимо требование создание копии данных перед началом работ по ремонту. И работа с этой копией в режиме read only, если уж хочется играть с такими программами как R-Studio.
А для конкретной ситуации R-Studio с его полным сканом поляны был избыточен. Затерта partition table в LBA0, но boot NTFS второго раздела никуда не делась - иначе R-Studio ничего бы и не нашел [quote author=Пинат link=topic=1916.msg9293#msg9293 date=1453929950]
с уцелевшей структурой каталогов. [/quote] И для хозяина диска который имел полные данные о том какого размера были разделы на харде "до того как" нужно было просканить на предмет нахождения boot NTFS либо область в районе предполагаемого места начала раздела, либо в его конце, посмотреть в найденом boot значение hidden sectors и соответственно сделать в LBA0 свою PT где relative sectors равно hidden sectors найденого boot, и c количеством секторов как в total sectors обнаруженного boot. Дело - ровно на 5 минут. И заодно все предположения по смещению координат поляны проверяются.

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

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

Найти и прописать информацию о разделах дело небольшого количества времени, но для этого нужны знания об устройстве файловых систем, которых у большинства пользователей нет. Равно как нет и профессионального оборудования. Посему человеку было проще пролечить "софтбэды", это не правильный и опасный подход, в первую очередь для данных пользователя, да и накопитель может выйти из строя если дефекты окажутся реальными, а область с дефектами будет иметь серьёзные повреждения на поверхности пластин, просканировать весь диск в той же R-Studio, которая обнаружила раздел, и успешно извлечь данные.