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

Ребят, нужна помощь в одном вопросе.
Была флешка 8гб и на ней была важная информация. Флешку я потерял и хочу спросить, смогут ли с неё восстановить данные.
Незадолго перед тем как я её потерял, я сделал с ней вот что:
1. Через обычные средства вин 8.1 сделал быстрое форматирование, сменил файловую систему с FAT32 на NTFS. (заняло пару секунд)
2. Через пару минут открыл программу Rufus указал в ней путь до образа вин 8.1(обрезок, весил вроде 1гб с мелочью), сменил разметку диска с GPT на MBR, файловая система сразу автоматически перескачила с FAT32 на NTFS и тоже стояла галочка быстрого форматирования внизу программы.
Когда образ залился на флешку, я закинул пару файлов и собственно все.

nirvanistka
В http://forum.ru-board.com/topic.cgi?forum=84&topic=4564&start=1520#9 я уже ответил п.2.
То что будет меняться уже было в дампах.
Тут есть другая сомнение-непонятность (для меня).
Если исходить из лога поиска, то как бы чётко вырисовываются два фрагмента; и сделать патч только для них не проблематично. Но с некоторым пробелом есть записи с более большими значениями. По логу это записи от какого то прежнего раздела с началом в секторе 63 (не любит наш пользователь прибирать поляну), а если от этого? Вот в этом случае с патчем проблемы могут быть.

Madapaka
Всё зависит от желания восстанавливающих, типа данных и от кучи других обстоятельств.

9285
Посекторку всего винта (для надёжности) я сделала. Так что если будут проблемы, вытащить из него всё равно сможем. Фотографии и самую нужную виртуалку я и так восстановила, а вытаскивать кучу солюшнов, открывая каждый каталог в каталоге, так как восстанавливаются только файлы, а не папки, это я помру.
Так что давайте пробовать с патчем. Сам винт мне этот когда-то отдали (уже поделённый и уже с виндой в первом томе, и я её не переустанавливала), так что не смогу сказать, были ли там до этого прежние разделы...

Добрый день уважаемые.
Вот и мои партиции слетели.. Поставил на поиск файлов по сигнатурам Active@ recovery, файлы то он находит ок, но время 400 часов!! пипец..

сам диск:


в загрузочном секторе твориться это:


Буду признателен для указания куда копать. Плюс.. Есть ли смысл форматировать? я найду свои файлы опосля?

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


Цитата:

Есть ли смысл форматировать? я найду свои файлы опосля?

точно не нужно ничего форматировать, будет хуже.

ЗЫ: по СМАРТу особых проблем нет, разве что таймаут (BC), проверить на наличие апдейта прошивки и обновиться, если есть - но это уже после того, как данные достанете... мало ли.

nirvanistka
Архив с патчем.
В имени файла-патча указан номер сектора физического (в скобках применительно к логическому) диска куда записать. После записи патча можно перезапустить DMDE и открыть диск по новой. Проблемный раздел должен открыться без предварительного поиска.
После стандартно:
- перезагрузка системы
- не допустить автоматической проверки диска
- сделать вручную в режиме только чтения
- показать результат.
Впрочем, если не терпится и есть посекторка, то можно и сразу пролечить.

Цитата:

что было в начале - как разбит, чем разбит и т.п.

У меня два таких винта (одинаковые), они целиком под видео и фото. И вот один слетел.
Может есть варианты какие?
чёрт.. это медленно как то)

По собственной глупости сделал себе проблему. Раздел С: был уже переполнен и я решил расширить его за счёт свободного пространства из раздела D: и двух скрытых системных разделов. Ипользовал прогу Paragon PM, когда процесс начался и было переписано 3-5 гиг, я по незнанию прервал его, ибо было некогда ждать перезаписи всего раздела D:, думал на ночь поставить. Короче когда перезагрузил систему, раздел D: неотформатирован. Далее пробывал кучу прог по востановлению раздела, ничего не помогло. Дошла очередь до Testdisk, но прежде чем экспериментировать решил попытаться данные востановить. К счастью R-Studio смог вытащить всё, кроме контейнера TrueCrypt, его вытаскивал уже в DMDE. Всё получилось, но он почему то не читается TrueCrypt’ом пришет что файл не является контейнером TrueCrypt или неправильный пароль(пароль 100% правильный). Тогда вытащил повторно его уже другой прогой Runtime GetDataBack for NTFS, результат тот же. Проверил размер востановленого контейнера с его июньским бекапом, размеры идентичны. Почему он не читается для меня загадка. Есть надежда что если востановлю сам раздел то и контейнер заработает, там пароли которые востанавливать проблематично. Для востановления раздела D: буду использовать Testdisk. Проблема в том что я мало что понимаю из тех цифр, что показывает эта прога. Я наделал скринов и прилагаю лог програмы, smart отчёт тоже прилагается. После быстрого скана и глубокого скана, невозможно прочитать файлы с раздела D и сделать write. Также не помогло rebuild BS. Буду очень благодарен за ваш диагноз и рекомендации по востановлению. Сам боюсь дальше тыкониной заниматься, нехватало ещё и раздел С: потерять.
https://yadi.sk/d/SqauPQGfc5ejS

MrBy
Ну а что ты хотел, если винт такой огромный?
Кстати да, при таком обьёме, в первую очередь возникает мысль о завороте данных и о том что разметка должна быть GPT. И если было несколько разделов (сколько и какие почему то умалчивается), то пострадает скорей всего один а остальные целы. В этом случае задача упрощается.
И что мешало воспользоваться той же DMDE для предварительного анализа?
PS. Вообще полезно полезно пользоваться софтом, который может делать сохранение промежуточных результатов и последующее продолжение исследования.

Добавлено:
Master_Max
При изменении размеров разделов со сдвигом начала раздела, практически всегда идёт перемещения файлов и перепись MFT. И если в какой то из моментов происходит обрыв, то и возникает ситуация когда данные о размещении файла не соответствуют действительности. Поэтому то и проблемы при открытии.
И плохо что ты уже начал что то реконструировать, т.к. парагоновское ПО (последних версий) может заканчивать прерванное. Правда не могу сказать при каких условиях это происходит.
По крайней мере я проводил эксперимент с одни винтом. Начал изменения, прервал, перезагрузил системник - вышло сообщение, предлагающее вставить специальный рековери диск (насколько понимаю - код этого записан в MBR). Вставил и всё закончил успешно.

9285
Я использовал Парагон ПМ11, после перезагрузки он мне ничего не предложил. Я сам его всего излазил и не нашол никакой возможности для продолжения или востановления.

Master_Max
Возможно что "подстилка" делается при каких то условиях (или как вариант какой то "мега-проф" версией).
Опять же, сколько винтов? Если не один, то возможно что всё это есть но не срабатывает по причине загрузки с другого винта.
Это лишь предположения. Хотя может быть вопросом к техподдержке парагона или знатокам их ПО.

9285

Цитата:

В имени файла-патча указан номер сектора физического (в скобках применительно к логическому) диска куда записать. После записи патча можно перезапустить DMDE и открыть диск по новой. Проблемный раздел должен открыться без предварительного поиска.

Тут уже не ладное...
сектора записала, переоткрыла DMDE, выбираю второй том ($Volume02),
http://s010.radikal.ru/i313/1410/b2/4b0de529f8fc.png
нажимаю открыть, получаю (на обоих строчках)
http://s019.radikal.ru/i622/1410/20/97e3e9d056f8.png

я так понимаю, что дальше уже следовать инструкции смысла нет?

Добавлено:
Ну ради интереса всё же перегрузилась и сделала проверку, ничего нового ((
chkdsk f:
Тип файловой системы: NTFS.
Метка тома: KOFAX.

ВНИМАНИЕ! Параметр F не указан.
CHKDSK выполняется в режиме только чтения.
Повреждена основная таблица файлов. Будет выполнена попытка восстановления
основной таблицы файлов с диска.
Не удается восстановить основную таблицу файлов. Выполнение CHKDSK прервано.

nirvanistka
Патч записан не в тот сектор, куда было указано. В противном случае появился бы индикатор F.

9285
Открывала весь диск,
сервис-копировать секторы
источник - Ваш файл, Место для записи Диск, начальный сектор - 67724079 (из названия патча)
http://s019.radikal.ru/i628/1410/2a/ef548038cc5d.png
Как же могло не в тот сектор записаться?

Добавлено:
сделала по-другому, и получилось
во-первых сначала перезаписала те 4096 байтов, которые уже заполнила чем-то не тем - обратно копией из первого дампа
а потом выбрала так же, как когда тот дамп делала (открывала сразу именно логический диск)
и вот в него уже записала с сектора 6291456
теперь появилась буква F

nirvanistka
Если проблема была уже после перезагрузки системы, то скорей всего система переписала заголовок MFT из копии.

9285
Ничего не понимаю
когда сделала перезапись в логический диск, буква F появилась, и том стал открываться.
Однако после перезагрузки системы - опять всё по-старому, и chkdsk так же ничего не делает.

система так и будет сама записывать мне битую информацию в те сектора?

Добавлено:
Похоже. всё портит сам чекдиск! Повторила процедуру. записала патч в логический диск, закрыла-открыла DMDE, открыла весь дтск, буква F появилась, том открывается
http://s019.radikal.ru/i637/1410/b9/46b49517bf2c.png
решила в этот раз систему не перегружать, а сразу попробовала сделать проверку.
результат чекдиска тот же - никакой.
однако сразу после этого открываю DMDE и там опять буква F пропала, том не открывается

nirvanistka
Сразу не получится - система кэширует данные.
Сделай по другому.
Удали у диска букву (F).
Запиши дамп в указанный сектор + в место расположения зеркала (чтобы не переписывалось старым мусором). Для физического диска это сектор 519100343.
Перезагрузи систему, назначь букву диска и сделай чекдиск.

Нет, не так, как я говорила получается...
Если сделать замену патчем, потом открываю диск - индикатор F есть, можно открыть том. если не отрывать и перезапустить DMDE, то всё так, типа хорошо.
А если всё же открыть, а потом перезапустить приложение, то уже индикатора F в следующий раз не увидишь

nirvanistka
Сделай как я написал.
Тут есть мой недочёт - обычно первым делом (в самом начале) делают отключение буквы диска.

9285
Перезаписала табличный сектор, появился индикатор F, а когда перезаписала зеркало (519100343), индикатор сменился на xf
http://s017.radikal.ru/i433/1410/97/7e50af7a4d3b.png
это хорошо или плохо?

Цитата:

это хорошо или плохо?

Даже не знаю что сказать. По логике должна быть только красная F (попробую смоделировать при минимуме исходных данных на виртуалке).
Можешь сделать дамп секторов, куда пишешь патч - посмотрю что там реально.

9285
Эксперименты до добра не довели (((
Решила скопировать секторы для зеркала так же как для таблицы получилось: в DMDE сразу открыла логический диск F, и туда записала патч, начиная с 457667720.
После этого у меня почему-то сломался первый том (((
http://s51.radikal.ru/i131/1410/bc/b8fe966b53b0.png
Причём замена этих же секторов тем, что было в дампе (первого дня) ничего не меняет.

nirvanistka
Это дело такое - аккуратность лишней не бывает.
Если судить по скриншоту, ты видимо не было замечено что источником записи выбран физический диск и сектор 0. Соотвественно, перезаписались 8 начальных секторов и таблица разделов.
Можешь посмотреть содержимое этих секторов и сравнить с патчем. Или покажи что сейчас в них.
Если всё так, как я предполагаю, то разделы просто надо Вставить - первый как основной, второй как логический в расширенном (хотя можно и как основной). Применить изменения разметки.
Ну и не забыть дать первому разделу признак активности + записать загрузочный код в MBR (например с помощью команды консоли восстановления ОС).

Добавлено:
В архиве патч для 0-го сектора. в котором твоя таблица, идентификатор диска (критичен в некоторых случаях для операционки) и с загрузочным кодом семёрки.
Запиши в 0-вой физического - попробуй не ошибиться.
Если ты работаешь в системе с этого диска, то обязательно запиши патч, потому что без него прийдётся вручную восстанавливать загрузку и т.п.

PS. Пока убегаю - если что, отвечу наверное вечером.

9285

Цитата:

видимо не было замечено что источником записи выбран физический диск и сектор 0. Соотвественно, перезаписались 8 начальных секторов и таблица разделов.

как ни удивительно, но каждый раз при копировании вводился номер сектора, так что даже если бы и перепутала диск, с 0 точно бы не должно было запороться
дамп первых 8
http://rghost.ru/58568462

nirvanistka
В дампе содержимое твоих секторов сбойной MFT. Если всё делалось правильно, то оно туда не могло попасть.

9285
блин...
извини, правда не понимаю как такое случилось

скопировала первые 8 из моей полной копии, помогло, стало как в самом начале было )

потом ещё раз пропатчила (в локальном) с сектора 6291456 и 457667720.
индикаторы F появились.

перегрузилась, чек диск на этот раз выдал другую инфо
chkdsk f:
Тип файловой системы: NTFS.
Метка тома: KOFAX.
ВНИМАНИЕ! Параметр F не указан.
CHKDSK выполняется в режиме только чтения.
Проверка файлов (этап 1 из 3)...
0% выполнено. (обработано файловых записей: 0 из 158720)
Сегмент записей в файле 0 поврежден.
Обработано файловых записей: 158720.
Проверка файлов завершена.
Обработано больших файловых записей: 31.
Обнаружены ошибки. Продолжение работы в режиме только чтения невозможно.

правда, каюсь, я про удаление метки забыла.
результат чекдиска обнадёживает? или всё плохо?

nirvanistka
В DMDE то хоть нормально раздел открывается? Данные видны? Структура соотвествует?
Всё (важное) имеется. Ведь я сделал патч для двух огромных фрагментов. Хотя другие скорей всего не от этого тома, а возможно и от виртуалки, но проверить не мешает
Результат чекдиска практически ниочёмный, но это характерно для чекдиска.

9285
В DMDE всё открывается, данные видны.
Спасибо огромное!
У меня тоже было подозрение. что там от витруалок информация лезет.
значит что дальше? Включаю чекдиск с параметром /f ? или /r ?

Есть пару вопросов.
Имеется DIM-образ диска с "полетевшей" системой. Есть ли инструмент, который :
а) позволит определить какие системные файлы отсутствуют;
б) может автоматически (из указанного источника) дописать эти файлы в DIM-образ диска с "полетевшей" системой?

Также есть вопрос по определению BAD-секторов
А именно
версии Active@ File Recovery 7 и 8 - постоянно отображают диапазон 1421217-1421279, а версии Active@ File Recovery 11 и 12 - 1419264-1421311, а R-Studio только выдает ошибку "Read disk F: at position 727646720 failed after 1 attempts. Ошибка в данных (CRC) (23)" Что это значит?

nirvanistka
Для исправления логических достаточно /f , но если хочешь сразу исключить проблемные сектора (если чекдиск их таковыми посчитает), то можешь и /r.

А вообще насчёт остальных фрагментов. Скорей всего если загрузить лог поиска а потом найденный том, то можно попробовать перейти к любой из записей MFT начиная от 159272 и до 171545 и посмотреть что за имена файлов там фигурируют

cdrom2
Что такое DIM-образ?