» Восстановление разделов и информации на HDD (часть 7)

Цитата:

на приемнике была nfts до копирования, и информация была удалена, правда без форматирования....

Если делалась посекторка, то смысла в обнулении нет - ну разве что секторов которые лежат после крайнего в оригинале.

В дампах видно что первые три записи накрыло шаблоном, напоминающим Bitmap (MFT)
Технически ранлист (патч) соорудить можно, но я пока не могу это сделать. В любом случае 100% гарантии нет.
И выполни просьбу igor_me

Цитата:

Ну и на всякий случай покажите скриншот SMART исходного диска...

Ведь должна же быть причина такому глюку.

Всем Здравствуйте! У меня перестал работать раздел диска "D". Объясню все с самого начала. Я хотел перераспределить память из диска "D" на диск "С" и воспользовался мультизагрузочным USB от Strelec. Для перераспределения памяти использовал программу Acronic Disk Director(как и всегда). Зашел в программу и изменил размер тома, т.е. уменьшил его с 400GB до 390. Точнее пытался уменьшить, но загрузка дошла до половины и выдало ошибку, что файловая система неизвестна, хотя она NTFS. После данной ошибки диск D перестал работать и требует форматировать его, но у меня там остались важные файлы. Пробовал менять файловую систему, но после смены требуется форматирование. Есть ли способ как-то восстановить его или скопировать оттуда файлы?

Скриншоты:
http://hkar.ru/z3q4
http://hkar.ru/z3q5

HelpMeAss
1)Acronis Disc Destroyer выбросить и забыть.
2)Показать скриншот окна Разделы из DMDE. Для этого нужно открыть пострадавший диск как физическое устройство.

Alex_Green
Скриншот окна разделы-> http://hkar.ru/z3B5

Здравствуйте,

Вопрос такой. По ошибке на диск с данными был клонирован образ системного диска. Утилита HDD Clone, ОС Win 7 SP1 x64.
Возможно ли в этом случае восстановление данных? По возможности со структурой папок.. (т.к. данных много.. диск был занят на 90%)

Диск Seagate ST1000DM003-9YN162 - рабочий.
Был размечен как базовый GPT/NTFS, на разделы не разбивался.
Сейчас это размеченные 256Гб с ОС и неразмеченная область 676ГБ.
Обнаружилось это сразу.. никакие другие манипуляции с диском не проводились.

Полные данные не выкладываю.. пока.. если необходимо добавлю.
Спасибо.

P.S.
Предполагаю что могу рассчитывать только на неразмеченную область.. т.к. начальная часть перезаписана..
Также хотел уточнить можно ли через восстановление раздела вернуть первоначальную разметку.. может это как-то поможет восстановлению (хотя если честно сомневаюсь)?
Диск стараюсь не трогать работаю только с образами (img и т.д.)

Цитата:

По ошибке на диск с данными был клонирован образ системного диска

Ну приехали

Цитата:

Утилита HDD Clone

Цитата:

Предполагаю что могу рассчитывать только на неразмеченную область

Если делалось посекторное копирование с исходного диска - то да, конечно. Если же делалось копирование раздела или SMART-копирование диска - могут быть варианты.
ЗЫ А какого размера был исходник??? Что -то 256 Гб не подходит под штатный размер физического диска...

Добавлено:
И на сколько был заполнен исходный диск?

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


monolight
Действительно, не очень понятно с полученной структурой.
Если образ не посекторный то я уже как то писал про метод зачистки новых данных. Правда с 7-кой он затруднителен в виду огромного числа файлов и тем более замудренными правами. Но Если говорить о восстановлении по файловой системе. то зануление наложенной MFT может сделать более удобным работу со старой. И то, в части записей не попавших под перезапись. И тут очень критично чем формировался раздел.
В любом случае, остаётся сигнатурный поиск.

HelpMeAss
Нужен дамп сектора 64 и 100 начальных секторов MFT.
Есть вариант что первый раздел увеличен лишь в таблице разделов. Но не факт.
И пробуй открыть жёлтый диск с индикаторами xxCF
И да, с диском лучше не работать, так как если версия выше не подтвердиться, то в конец раздела моут записаться данные накрыть прежнюю MFT.

9285
Я уже 10-й час восстанавливаю оттуда все файлы через программу R-Studio сохраняя при этом структуру папок. Остался 1 час. Пока ничего не буду делать, а после завершения - форматирую. Надеюсь проблема решится форматированием! Если что - отпишусь.

9285

Цитата:

Есть вариант что первый раздел увеличен лишь в таблице разделов. Но не факт.

Дык первый раздел вроде как остался прежнего размера (может я не так понимаю ситуацию), а второй будто бы увеличился на 6Гб за счёт левой границы.

HelpMeAss
Ждём дампы, которые запросил 9285, и также если после открытия Local Disk с индикаторами xCF будут видны папки и файлы, то можно восстановить несколько файлов на другой носитель и проверить их работоспособность.


Добавлено:
HelpMeAss

Цитата:

Пока ничего не буду делать, а после завершения - форматирую. Надеюсь проблема решится форматированием! Если что - отпишусь.

Восстановленные файлы надо сначала проверить на работоспособность, и только если они окажутся рабочими, можно приступать к форматированию.

Alex_Green

Цитата:

за счёт левой границы

Некоторые ещё пишут о верхней-нижней границе.
Может так правильнее, но если я путаюсь в этих понятиях, то что может подумать обычный пользователь?
Куда более понятнее начало-конец раздела.

Что касается того, что произошло, то цифры немного не идут и тому есть одно логичное обьяснене. В акронисе было задано уменьшение D на гигов пять, а потом решено ещё пять отрезать. Мы то понимаем что надо отрезать 10, но акронис делает так, как задано, и поэтому первое уменьшение было на 5 гигов.
То есть старый D это тот, что с xxCF, а новый тот , что только запись в РТ. А бывший С начинался в 2048 и заканчивался где то в районе 125833215. Конец раздела перенесён, а начало сдвинуто в 64 - последнее действие бессмысленное, но это бзик акронисовцев. Как то так.

9285

Цитата:

В акронисе было задано уменьшение D на гигов пять, а потом решено ещё пять отрезать

А, вон оно даже как...


Цитата:

А бывший С начинался в 2048 и заканчивался где то в районе 125833215. Конец раздела перенесён, а начало сдвинуто в 64 - последнее действие бессмысленное, но это бзик акронисовцев.

Да, действительно логика никоим образом здесь не улавливается. Удивительно что С вообще работает после таких издевательств.


Цитата:

То есть старый D это тот, что с xxCF, а новый тот , что только запись в РТ.

Дай бог чтобы файлы были рабочими после восстановления, а то ведь может иметь место смещение, и не одно.

Цитата:

А, вон оно даже как...  

Ну это как бы моё видение, основанное на практике подобных кейсов.
Хотя они же как бы намекают что иногда деструкция производится в несколько этапов (видимо зависит от версии (билда) УПД).


Цитата:

Удивительно что С вообще работает после таких издевательств. 

С этим как раз может всё нормально (особенно если использовалась 11-я версия).

Вообще, было бы интересно посмотреть ещё кое какие дампы. И именно в свете CF.

Alex_Green

Цитата:

Ждём дампы, которые запросил 9285, и также если после открытия Local Disk с индикаторами xCF будут видны папки и файлы, то можно восстановить несколько файлов на другой носитель и проверить их работоспособность.

Цитата:

Восстановленные файлы надо сначала проверить на работоспособность, и только если они окажутся рабочими, можно приступать к форматированию.

Все отлично работает! Восстановились даже "цвета"(иконки) папок.
По сути произошло простое копирование файлов с одного диска на другой.
Вопрос решен.

Спасибо всем за отзывчивость!

igor_me, 9285, прошу прощения за задержку, вот SMART. http://rghost.ru/6BbcRxjyX

HDDScan почему-то не захотел делать.

А чекдиском я смогу исправить этот глюк?

Спасибо.

Цитата:

А чекдиском я смогу исправить этот глюк?

Есть такая вероятность, но это вам 9285 точнее ответит. Я железячник больше Посему по SMART: Ну что, есть немного нестабильных секторов. Теоретически могут быть и ещё незаремапленные бэды. Но раз у вас (как понял) посекторная копия создалась без проблем, то пока у вас основная забота - починка раздела. Вполне можно чинить на копии. А вот потом: сделать полное стирание исходного диска, например в Виктории, в ней же потом запустить скан. И смотреть по результату. Если бэдов нет и секторов с задержками - возвращать копию обратно. Если же будут - можно чуток "подрихтовать", скрыть бэды\задержки. Это уже потом ко мне обратитесь, если что, по удалёнке могу глянуть...

nutta
Недавно был (скорей всего) единственный случай когда сдвиг первых записей был таков, что по сути всё было целое - то есть достаточно было сделать обратный сдвиг и сформировать один сектор, в котором нули и пара байтов. И уникальность этого случая в том, что чекдиск не нашёл ошибок.
Во всех остальных случаях патч делает основу исправлений, а шлифовку производит как раз чекдиск.
Черновик патча готов, но хотел бы его протестировать в виртуалке. В принципе, могу его выложить.

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

9285, спасибо, с удовольствием воспользуюсь патчем, до проверки или после, как посчитаете лучше/правильнее. Единственное, я не очень поняла из темы как его надо прописывать.

nutta
Архив с патчем.
Процедура прописи аналогична деланью дампа, только меняются местами источник (файл патча) и место для записи (указанный в патче номер сектора).

9285, спасибо! Правильно я поняла
Сервис - Копировать секторы - справа выбрать файл (вставляю файл с патчем) - место для записи указать Начальный сектор 0 ?

вот так http://rghost.ru/7lsMsxNFm?

nutta

Цитата:

вот SMART

По Смарту видно что у вашего WD Sadle G6 стали появляться кандидаты в бэды.
Это ничего, но обычно эта проблемка вырастает в уже проблему slow responding, свойственную всем моделям данного семейства.

Цитата:

Начальный сектор 0 ?

уже написал - указанный в патче номер сектора
то есть 6293504
Разве не логично патчить то, где ошибки?

9285, пожалуйста, посмотрите мой скриншот, может я не то делаю? у меня там в байтах ....

http://rghost.ru/7lsMsxNFm

вместо 0 в поле "место для записи" указать Начальный сектор 6293504, так?

nutta
Да.
После патча можешь проверить правильность.
Переоткрой диск, а в нём том - без поиска должна стать доступна структура диска.

9285
Да, видится без поиска! Спасибо!!!
Мне теперь проверять его чекдиском надо или просто перезагрузить?

nutta
Конечно проверять. Я же раньше писал - патч это полуфабрикат. Не исключаю что если подключить винт в линуксовую систему, то доступ к данным будет. Но в винде точно нет.
Тут основной момент - как отработает чекдиск. Поэтому то говорится о неоднозначности и совет восстанавливать всё важное до исправлений (на другой носитель).
Ну и проверку сначала делают в режиме только чтения.
Впрочем, не буду больше нагонять тучи. А ты уже принимай решение о дальнейших действиях.

Добавлено:
nutta
И обрати внимание на совет Michael99

9285
Конечно буду проверять, я уже приняла решение, важные данные скопированы как уж нашлись.
Прошу прощения, а как проверить в режиме чтения

nutta
просто набрать команду и букву диска - то есть без дополнительных ключей.
Кстати, по поводу совета Michael99 - думаю не лишним будет запусить мониторинг SMART и посматривать за его показателями.

9285
Вот скан chkdskа
http://rghost.ru/68bq5thJR

пациент жив или мертв?))

nutta
Жив, но хворает.
На самом деле чекдиск не всегда пишет все ошибки, а относительно 8-ного (нового по идеологии) я вообще не могу ничего сказать.

9285
Спасибо за помощь и терпение!

Мне осталось просто перегрузиться или еще сделать chkdsk с r и/или f?
Могу еще на 7ке попозже его запустить или это уже не важно.