Системный диск стал RAW | Apacer AS610S

[serglavr]

Цитата (9285) »

Перед патчеванием NTFS на HDD обычно делается "отключение" MBR, после чего винда уже не лезет на том, не блокирует запись в его метафайлы и после патчевания не пытается почекать том чекдиском.

Патчить на SSD ещё не доводилось, и не знаю как он отреагирует на такое отключение. Технически пропатчить без отключения можно в линуксовой или досовской версии, но можно попробовать загрузиться с какого нибудь LiveCD и делать патчевание в его среде.

Само патчевание идентично тому как делается дамп, только меняются ролями Источник и Место для записи.
В источнике выбирается файл патча (из архива), в Месте для записи выбирается проблемный диск и указывается номер начального сектора куда надо писать патч. Номер сектора присутствует в имени патча.
Если патчевание сделано правильно, после переоткрытия диска (в DMDE) и открытия тома, в Root должна увидится структура данных.

Я сижу через live cd AdminPE

[9285]

Как минимум, надо забрать букву у тома.
И ещё - патч желательно записать и в MFTmirror.
То есть, записать этот же патч в сектор 206864

[serglavr]

а MBR off операцию делать?

[9285]

Я написал что не знаю как на это среагирут SSD. Поэтому - нет.

[serglavr]

Есть контакт!
В Root структура данных показывается
Патчевание сделал и в MFT Mirror

[9285]

Цитата (serglavr) »

В Root структура данных показывается

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

[garniv]

Цитата (serglavr) »

а как целостность проверить? Открыванием файла?

Погуглил, можешь попробовать Bad Peggy

P.S.
А для Linux есть консольная утилита jpeginfo

[serglavr]

Цитата (9285) »

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

Виртуальная реконструкция - это ПКМ по тому и "Построить виртуальную ФС"?
Если так, то я убрал там галочку с "включая удаленные" и режим выставлен автоматически " "Чистая" реконструкция ФС".

Выдало в начале ошибку(скриншот)затем дошло до конца и показало туже самую структуру данных.

Добавлено через 38 секунд

Цитата (garniv) »

Погуглил, можешь попробовать Bad Peggy

P.S.
А для Linux есть консольная утилита jpeginfo

Попробую, спасибо

[9285]

Цитата (serglavr) »

Выдало в начале ошибку(скриншот

чуть выше писал что 2-я запись обнулена, поэтому всё нормально.
Что там чекдиск вещает?

[serglavr]

Цитата (9285) »

чуть выше писал что 2-я запись обнулена, поэтому всё нормально.
Что там чекдиск вещает?

Запускал как chkdsk M:

[9285]

Видно что концовка.
Чтобы получить весь лог - выведи его в текстовый файл
примерно так
chkdsk M: >C:\log.txt
Вместо С: указываешь путь на носитель доступный для записи.

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

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

[serglavr]

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

Насчёт восстановления файлов, я до патченирования освободил место на HDD и скопировал полностью Root директорию на диск

[9285]

Ага, увидел про ошибку в 0-вой записи.
В остальном всё уже написано выше. Так что решай что делать дальше, хотя ничего нового не просматривается - чекать том и смотреть что получится. Если что - посекторка есть в запасе.

Цитата

скопировал полностью Root директорию на диск

По этому поводу есть некоторые мысли.
1. Free-шная версия не позволяет восстанавливать каталогами. Если вдруг использовалась ломанная, то там могут быть сюрпризы в виде битых файлов, которые в нормальной версии восстанавливаются нормально.
2. В принципе, в результатах поиска не так много "левых" записей, поэтому надеюсь что такового будет не очень много.
3. Часть данных моет находится не в папке root, а в папках типа $Fxxx, поэтому если что то "пропало", то ищи данные в таковых.
Это связано с тем, что если нет данных о родительском обьекте, то программа не знает где данные находились и складывает все обьекты с одинаковыми "родителями" в одну такую папку.

[serglavr]

Цитата (9285) »

Ага, увидел про ошибку в 0-вой записи.
В остальном всё уже написано выше. Так что решай что делать дальше, хотя ничего нового не просматривается - чекать том и смотреть что получится. Если что - посекторка есть в запасе.

По этому поводу есть некоторые мысли.
1. Free-шная версия не позволяет восстанавливать каталогами. Если вдруг использовалась ломанная, то там могут быть сюрпризы в виде битых файлов, которые в нормальной версии восстанавливаются нормально.
2. В принципе, в результатах поиска не так много "левых" записей, поэтому надеюсь что такового будет не очень много.
3. Часть данных моет находится не в папке root, а в папках типа $Fxxx, поэтому если что то "пропало", то ищи данные в таковых.
Это связано с тем, что если нет данных о родительском обьекте, то программа не знает где данные находились и складывает все обьекты с одинаковыми "родителями" в одну такую папку.

У меня DMDE купленная лицензия
По поводу $Fxxx, на них значок корзины и они не восстанавливаются (при восстановлении пишет "исключенные директории").Да и файлов таких не очень много.
Прочекать том - это chkdsk M: /f /r ?


P.S загрузился с fullscan чтобы проверить $Fxxx. Да,появилось больше файлов, почти все восстановил, кроме тех же"корзин".

Добавлено через 35 минут

Цитата (garniv) »

Погуглил, можешь попробовать Bad Peggy

P.S.
А для Linux есть консольная утилита jpeginfo

Bad Peggy нашел корявые jpg и png файлы, но важных я не увидел (в основном Temporary Internet files)

[9285]

serglavr

Цитата

Прочекать том - это chkdsk M: /f /r ?

Ключ r используется для физической проверки поверхности - не думаю что он нужен в данном случае. Хотя ... диск то не новорожденный

Цитата

По поводу $Fxxx, на них значок корзины и они не восстанавливаются (при восстановлении пишет "исключенные директории").Да и файлов таких не очень много.

Корзина означает удалённую запись и вполне очевидно что на место где были данные об обьекте могла записаться другая инфа. Так что всё нормально.
А вот в случае использования наверняка уже были вкрапления данных от имеющихся в логе фатомных записей - там надо смотреть на значок, который означает тот или иной статус. И, в силу этого - там очень вероятно что файлы будут битыми.

Цитата

У меня DMDE купленная лицензия

А вот это молодец!

[serglavr]

Ура!

Пробую загрузиться в систему?


P.S. Система снова работает!!!
Спасибо!!!

[9285]

Ну и ладушки.
Что касается системы, то не лишним была бы проверка системных файлов. Что касается файлов данных, то для сравнения (если интересно проверить эффективность восстановления по месту) можно проверить по контрольным суммам файлов.

[9285]

Кстати, а у тебя то место очень сильно на диске занято.
Не исключено что проблема с этим связана - может винда не найдя места и решила записать данные о каких то четырёх файлах в зону начала MFT.
Опять же, такая заполненность приводит с сильной фрагментации, в том числе и MFT. Хорошо если она ранее разрослась когда диск был не такой полный - тогда может и застолбила место и поэтому фрагментов меньше 10-ка. А может быть и ситуация когда появляется расширенный атрибут у 0-вой записи и куча доп-записей в которых описаны фрагменты. В особо тяжёлых случаях для описания списков записей выделяются кластера. И бывает прикольная ситуация, когда сами по себе записи собраны в кучу в блоках идут последовательно (**), но всё равно описание занимает кучу записей, потому как не удаляется расширенный атрибут. В такой ситуации повреждение хотя бы одной из кучи уже приводит к существенным проблемам. Было бы в твоём случае такое и уже бы восстановление не было бы таким простым.
Да и на ресурс SSD такая занятость тоже влияет, существенно усиливая WA.
Так что подумай над этим и постарайся освободить место на диске.

[Smirnoff]

Цитата (9285) »

постарайся освободить место на диске.

Прямо с языка снял...

[serglavr]

Цитата (9285) »

Так что подумай над этим и постарайся освободить место на диске.

как раз над этим работаю