Как восстановить MFT внешнего жесткого диска

[Alex_Hope]

Добрый день, слетела таблица разделов на внешнем жестком диске Seagate + на 4Тб, жесткий заполнен полностью, документы, фото, фильмы, сериалы. По работе нужно было скопировать файлы на офисный компьютер под Windows 7, около 100 Гб, диск определился, файлы скопировались успешно, так же было скопировано с офисного компа около 3Гб файлов на жесткий. После копирования извлек жесткий без безопасного извлечения, подключил к своему ноутбуку на Windows7, система предложила его отформатировать. Я попробовал посмотреть его с помощью Akronis disk director, она отобразила дерево файлов, нажал исправить файловую систему, поставил галочки на разрешение исправления и восстановления файлов. Программа начала работу, и в окне лога исправлялись как раз те файлы что были скопированы с офисного компьютера, на 69% процесс намертво завис, пришлось отменить. После этого Akronis уже не увидел дерево файлов и написал что повреждена основная таблица файлов и восстановление не возможно. Так же я отсканировал жесткий при помощи DMDE, GetDataBack, R-Studio(отобразила все файлы как они и были на жестком) они находят файлы на диске, но таблицу разделов восстановить не могут. Partition Table Docktor пишет при попытке открыть жесткий I/O error. Прошу помощи что можно сделать чтобы восстановить MFT, некоторые скрины прилагаю, если необходимо могу выложить лог DMDE.

[Smirnoff]

Цитата (Alex_Hope) »

извлек жесткий без безопасного извлечения

силЁн, да...

Цитата (Alex_Hope) »

что можно сделать чтобы восстановить MFT

Возможно, 9285 чем-то поможет; но дурацкая привычка извлекать "без безопасного извлечения" - она тебе ещё не раз поможет потерять данные.

[9285]

Лог DMDE обязательно, а ещё потребуются дампы (или хотя бы скриншоты содержимого секторов, где как бы должны располагаться начальные сектора MFT.
По данным из другого места я знаю что речь идёт об ADD12, хотелось бы уточнить номер билда и как запускался (насколько понимаю - из винды).
И ещё - пробовал ли восстанавливать файлы (на другой носитель) и целы ли они?

Цитата

они находят файлы на диске, но таблицу разделов восстановить не могут

По имеющимся данным (ты забыл прикрепить скриншот экрана разделы) с таблицей разделов у тебя всё в порядке - проблема в MFT; а программ восстанавливающих таковую я что то не встречал.

[Alex_Hope]

Спасибо, попробовал восстановить видео файл 100 мб, восстановился, видео проигрывает без артефактов. Архив с логом не прикрепляется, слишком большой, ответил на почту.
Скрины дампов это вот это?
P.S. ADD12 версия: 12.0.3297, запускался из под Windows 7

[9285]

Ситуация не очень однозначная. Судя по одним данным - с MFT проблем нет, судя по другим - имеются. (*)
В том числе поэтому надо глянуть содержимое 0-вой записи - а заодно и остальные критичные. Для этого нужен дамп 50 секторов начиная с 6555648 (или по другому бывает что запрашивается как 6555648+49) и ещё дамп 264208+7
Дамп делается так:
- открываешь проблемный физический диск в DMDE
- в меню сервис выбираешь Копировать секторы и в появившемся окне указываешь:
в Источнике проверяешь что выбран нужный диск, указываешь номер начального сектора и число секторов (на скриншот пример для первого дампа)
- в Месте для записи выбираешь Файл и указываешь путь куда его сохранить. Предлагаемое имя файла не менять потому что оно даёт понимание с чего делается и какие сектора. А то бывет что начинают менять на MFT.bin или ещё как нибудь. Если уж так хочется внести какое то обьяснение в имени, то добавить к предложенному.
второй дамп делаешь по аналогии но уже с его данными секторов.
Оба дампа запакуй и приатачь к сообщению (размер там будет мизерный).

(*) Скорей всего ситуация как у участника с другого форума (проблема решается по электронке и уже практически на стадии завершения) - повреждения в 0-вой записи.

[9285]

Некоторых пугает запись дампов, которые нужны для более удобного анализа и изготовления патча в случае если это возможно.
Хотя для предварительного анализа сойдёт и скриншот типа такого как ниже.
Для этого открываешь физический диск потом сам том (*).
В меню Редактор выбираешь Физические секторы и вбиваешь номер начального сектора (из тех что выше написаны) и переходишь к нему.
Затем, чтобы было видно больше, закрываешь верхнее правое окно и меняешь вид просмотра (в меню Режим или нажать F2) на Шестнадцатиричный/Текст чтобы был вид как на скриншоте. Если не такой, то можно ещё раз нажать F2.
На скриншоте выделил красным место где проконтролировать тот ли сектор открыт. Ещё своеобразный контроль для случая когда запись не сильно повреждена - наличие характерных сигнатур выделенных зелёной рамкой.
По логике, у тебя они будут.
Ещё можешь изменить вид на Запись MFT (Alt+F5) сделать скриншот в таком состоянии.
(*)Том открывать не обязательно, но на скриншоте показано именно как выглядит при открытии тома.

[Alex_Hope]

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

[9285]

Это не заметил?

Цитата

Ещё можешь изменить вид на Запись MFT (Alt+F5) сделать скриншот в таком состоянии.

В таком виде будет видно содержимое записи в более восприимчивом виде - и сразу "бросится в глаза" что атрибут $Data имеет 0-вой размер. Если ассоциировать MFT с картотекой склада, то в такой картотеке данные о 0-ом количестве товара - хотя товар есть и его много.
Хотя есть и другие ошибки - те же временные штампы нулевые. В общем, запись изуродована.
Учитывая что MFT (судя по логу сканирования) состоит из нескольких фрагментов, можно сделать имплант 0-вой записи и попробовать восстановить по месту. Но это если исходить из версии что пострадала только 0-вая запись. Если исходить из практики, то вероятней всего так оно и есть, и восстановление должно пройти нормально, но 100% гарантию я конечно же не дам, так как нельзя исключать что изменения могут быть и в других местах - в таком случае всё зависит от того что повредилось, а исследовать всё это даже в случае наличия винта в руках практически нереально.
В таких ситуациях есть несколько путей:
1. Восстанавливать всё на другой носитель.
1.1. Делать это используя результаты полного сканирования, отсекая мусорные записи (порядка 20 тысяч)
1.2. Сделать имплант,записать его и восстанавливать только то, что было (виделось в проводнике).
2. Делать посекторку диска, и пробовать восстановление по месту. В случае неудачи, восстанавливать по п.1. из посекторки.
3. Восстановить только самое ценное на другой носитель и сделать восстановление по месту (без наличия посекторки). В случае если не получится останется только то, что восстановлено что на другой носитель. Хотя и в этом случае ещё можно восстановить что уцелело.
4. Ещё один вариант - это что то типа симбиоза частей предыдущих.
Перед восстановлением по месту делается бэкап MFT и в случае неудачи работа идёт с ним. Способ достаточно неоднозначный и во многом зависит от того куда чекдиск начнёт записывать свои логи (если до этого дойдёт) и файлы-потеряшки, но не упомянуть его не могу по двум причинам:
- хотя он "бродил" в умах разных форумных коллег и возможно даже предлагался ранее, но активно практиковать его начал Yatagan с хобота
- если не делается по предыдущим вариантам и даже если будут какие то повреждения, то наверняка иметь возможность восстановить что то лучше чем ничего. Или по простому - лучше ходить на костылях, чем лежать "овощем".
Вот как то так. Возможно выглядит страшно, и несмотря на оптимистичную чуйку не написать эти предупреждения - не в моих правилах.
Так что, осмысливай и принимай решение. И это полезно - надеюсь что муки выбора наведут на мысль о том что не стоит пренебрегать безопасными методами работы, бэкапом и отказаться от использования :censored::censored::censored::censored:ософта.

[Alex_Hope]

Да, пропустил, прилагаю скриншоты
Такой объем данных мне сейчас некуда восстановить( Только по приезду домой из командировки, а это не раньше чем через полтора месяца. Поставил еще в TestDisk на сканирование, но там процесс оочень долгий, за сутки 5 процентов

[9285]

Alex_Hope
Так о чём и речь - всё зависит от обстоятельств. Если ты можешь подождать 1,5 месяца - то можно пойти и по 1-му варианту. А если такой возможности нет? Именно поэтому тебе и решать как поступить рационально (*).
Testdisk-ом можешь погонять, но не думаю что есть смысл - MFT он не восстановит по любому.
(*) Если выберешь вариант 1, но при этом тебе могут понадобится те или иные файлы с диска, могу сделать ранее упомянутый имплант, который позволит в DMDE просто открывать том и восстанавливать нужные файлы.

[9285]

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

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

[Alex_Hope]

Вот такую запись лога нашел в Acronis. Не знаю правда оно или нет
Сведения о событии
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Тип: Предупреждение
Дата и время: 31 марта воскресенье 18:39:26
Код: 1!049!608(0x100408)
Модуль: 16
Владелец: Alex
Сообщение:
Неизвестная ошибка.
Дополнительные сведения:
--------------------
Код ошибки: 1032
Модуль: 16
LineInfo: 2a0adf413f5be246
Поля: $module : DiskBundleEx_vs_3297
Сообщение: Неизвестная ошибка.
--------------------
Код ошибки: 1030
Модуль: 16
LineInfo: 2c37348ce774f897
Поля: $module : DiskBundleEx_vs_3297
Сообщение:

[9285]

Это не то. Если и есть что то, то должно быть похожим на лог чекдиска типа Файлы нулевого размера#8
Но, это если исходить из варианта что запись делается в ходе проверки, если же только по окончании, то конечно же, при отмене, вряд ли такое сохранится.
Как вариант - если всё таки запись велась, посмотри в DMDE System Volume Information подпапку Chkdsk, может там есть какой либо свежий лог.
PS. В виртуалке смоделировал ошибку индексов корневого каталога. При таковой винда не может открыть том и ругается на ошибку (том считается RAW), хотя её чекдиск прекрасно лечит такую ошибку.
Акронис же не смог показать содержимое тома при такой элементарной ошибке, что наводит на мысль что изначально ошибка была не сильно серьёзной.
И ещё не нашёл возможности проверки (правда имеющаяся у меня версия чуть старее) а то бы посмотрел пишется лог или нет.

[9285]

Раз уж была упомянут Testdisk, то хотелось бы отметить следующее.
При всём моём уважении к труду автора этой программы, она хороша в части сигнатурного поиска (photorec), в части же самого testdisk-а нет ничего существенного что бы позволяло рекомендовать его.
Банально, нельзя сохранить результат сканирования и в случае какого то сбоя прийдётся гонять всё по новой.
Давненько ей не пользовался, но переиодически проверяю изменилось ли что то - решил проверить и сейчас. И именно WIP версию, в роли которой у которая у другого ПО выступают Alfa и Beta версии, которые рекомендуются только для тестирования, потому что могут содержать какие то ошибки.
Для начала решил проверить на смоделированной ситуации - ранлист нулевой записи был обнулён. Благо что в виртуалке сделал несколько гиговый диск, и уже через хх секунд появилось сообщение о том что файловая система серьёзно повреждена - то есть ничего не найти.
Ну да ладно, решил проверить на рабочем томе. И вот тут меня ожидало минимиум пара разочарований. Я смог скопировать нужные файлы на тот же том.......
Более того, не понимая как это случилось, но одна из папок, с которой работал переименовалась ) - в её имя добавился один символ.
Возможно что это как раз таки проблемы WIP версии, но невольно возникает вопрос о том зачем такую версию ставят первой в разделе загрузок.
Вот и с этой случилось что то невероятное - .