Раздел NTFS больше не доступен, 3 записи MFT повреждены, способ их исправить?

Question

У меня есть жесткий диск Seagate ST2000DM001 объемом 2 ТБ с одним разделом NTFS. Я не использовал его несколько месяцев, когда я снова подключил его, этот раздел по непонятным причинам стал недоступен: буква тома появляется в Проводнике Windows, но размер раздела больше не распознается, возникает ошибка, если я пытаюсь открыть его. Появляется как «RAW» в диспетчере хранилища. CHKDSK сразу же перестает анализировать его с сообщением об ошибке, в котором говорится, что он не может определить версию и состояние тома.

Тем не менее, если я открою этот диск с помощью R-Studio, раздел сразу появится с его правильным размером (даже сканирование не требуется), я могу открыть его и получить доступ ко всем файлам, которые были там в последний раз, когда я использовал его нормально, с насколько я вижу, все дерево каталогов и содержимое файлов кажутся на 100% правильными. Аналогичным образом, если я открою весь диск с помощью WinHex, он правильно распознает раздел и отобразит файлы и папки с их правильным содержимым. Я также протестировал 2 программы дефрагментации (только в режиме анализа): MyDefrag может перечислять содержимое раздела и предоставлять действительную информацию для каждого блока, наведенного указателем мыши (имя файла, размер, LBA ...); но Дефраглер не может. Я также открыл его с помощью DMDE: как и R-Studio, он может мгновенно распознавать содержимое раздела; он также отображает красное предупреждение относительно записей MFT 1, 2, 3 ; они , как правило , соответствуют: $ MftMirr, $ LogFile и $ Volume, три важные системные файлы, которые действительно отсутствуют в каталоге «$ MetaData». Возвращаясь к R-Studio, я вижу, что эти файлы также отсутствуют в каталоге «Метафайлы». Если я проверю начало MFT с WinHex, я вижу, что запись MFT 0 в порядке (она указывает на сам MFT), но затем записи 1, 2 и 3 MFT повреждены, они заполнены «FF» (шестнадцатеричный код).) / «Ÿ» (ASCII). И странно то, что зеркало MFT (которое я все еще могу найти с WinHex, используя старый моментальный снимок тома, сделанное до появления проблемы, и его местоположение также указывается R-Studio в панели свойств раздела, по-видимому, и MFT, и У MFTMirr их LBA, записанные в загрузочном секторе), имеет точно такой же шаблон искажения: первая запись в порядке, затем следующие три заполняются «FF».

Теперь я предполагаю, что раздел недоступен, потому что эти три записи MFT отсутствуют, поэтому соответствующие файлы не могут быть найдены. И CHKDSK должен требовать, чтобы хотя бы эти файлы работали должным образом. Как это могло случиться? Как мог и MFT, и его зеркало (фактически, является только копией первых 4 записей, но в данном конкретном случае этого должно было быть достаточно, чтобы устранить проблему, поскольку 3 поврежденные записи входят в число этих 4), в конечном итоге поврежденные на в то же время ?
И как я могу исправить / воссоздать те недостающие записи MFT, чтобы исправить раздел «на месте», вместо того, чтобы извлекать все файлы (что я уже сделал в качестве меры безопасности), переформатировать раздел и передавать их обратно ? Я мог бы скопировать действительные записи из другого раздела и изменить значения переменных, зная шаблон, но до сих пор я мог только идентифицировать метки времени (которые я могу копировать из других системных файлов в том же разделе, так как они все созданы в в то же время), я пока не могу найти поля, указывающие размер расположения кластеров. Я также обнаружил, что $ Volume, который является резидентным файлом (расположен полностью в MFT), содержит уникальный идентификатор раздела, который может быть самым проблематичным препятствием: должно ли оно быть таким же, как и раньше, чтобы раздел был правильно распознан, и если да, хранится ли он где-то в системе, или он может быть выбран случайным образом, и если да, то существует ли определенный шаблон, которому он должен соответствовать? Информация об основной структуре записей MFT, по-видимому, скудна или очень трудно найти среди тысяч страниц блуждающих веток форума или статей со слишком широким охватом, чтобы их можно было использовать в подобном случае.

Я описал проблему более подробно о HDDGuru, но у меня не было соответствующего ответа на вопрос «как я могу это исправить?» (постоянные участники очень хорошо осведомлены, когда дело доходит до сбоев аппаратного / микропрограммного обеспечения, но для такого рода логических сбоев они, похоже, довольно быстро сдаются).
http://forum.hddguru.com/viewtopic.php?f=1&t=36969

Answer 1

Итак, мне удалось решить проблему самостоятельно. Я провел некоторое исследование о структуре записей MFT в целом и об особой структуре 3 поврежденных записей, которые мне пришлось воссоздать (подробности см. В связанном ветке HDDGuru), изучая их на нескольких допустимых разделах. Затем я скопировал их из действительного раздела во временный файл в WinHex, изменил некоторые значения ключей, которые отличались от одного раздела к другому, затем скопировал файл размером 3072 байта непосредственно в раздел, запустил CHKDSK, который можно продолжить и (после сообщалось, что в томе не было ошибок, и теперь раздел снова доступен. Я до сих пор не знаю, как это случилось, но это исправлено!

Значения, которые я должен был изменить:
- метки времени: все системные файлы имеют одинаковые метки времени, поэтому я просто скопировал поля меток времени из первой записи MFT (которая указывает на сам MFT) в поврежденном разделе;
- в каждой записи есть 1-байтовое поле с именем «fixup» в DMDE, присутствующее в трех разных местах в каждой, что, как мне кто-то объяснил в ветке HDDGuru, является просто «проверкой, чтобы убедиться, что запись действительна и не повреждена ”И может быть установлено любое значение, при условии, что оно одинаково во всех трех экземплярах этого поля;
- первый кластерный LBA для записи $ LogFile (я знал, где она была расположена, благодаря старому снимку тома WinHex, в противном случае мне пришлось бы искать файл на основе его заголовка, чтобы получить это значение; его размер по умолчанию ровно 64 МБ, или 67108864 байта, то же самое на всех разделах, которые я исследовал);
- для записи $ Volume (которая также содержит фактический файл $ Volume, поскольку этот файл является «резидентным», то есть полностью содержится в его записи MFT), мне пришлось найти исходный 16-байтовый идентификатор (или «идентификатор объекта») том, который был самой сложной частью: после некоторых неудачных попыток я нашел это значение в файле «tracking.log», в каталоге «System Volume Information» (сначала я проверил его на предмет допустимого раздела, значение которого соответствует который появился в $ Volume, поэтому я скопировал соответствующее поле из «tracking.log» на поврежденный раздел и вставил его в поле идентификатора тома в $ Volume);
- также в $ Volume я изменил имя тома, чтобы оно имело то же имя, что и раньше, но в этом не было необходимости, я мог бы пропустить имя из другого раздела и изменить его позже в свойствах тома, как только он снова станет доступен. (на самом деле я использовал небольшую хитрость здесь: я скопировал конец записи $ Volume из раздела с именем «TEMP», затем вместо того, чтобы изменить это имя на «Stockage», как этот раздел вызывался ранее, я поставил «Stoc», чтобы оно имело такое же количество символов, чтобы избежать неожиданного смещения и чтобы было уверенным, что значение «используемого размера» будет соответствовать, поскольку я еще не до конца понимаю структуру записи);
- поскольку я изменил имя тома, длина фактически используемой записи файла была другой, поэтому мне пришлось изменить поле, соответствующее «используемому размеру», чтобы отразить это и сохранить согласованность (я поставил тот же «используемый размер», что и один из раздела под названием «ТЕМП»);
- было еще одно значение, которое было другим, в начале записи $ Volume, называемой «LSNlo» в DMDE: на основании моего исследования «LSN» означает «порядковый номер $ LogFile», и это ссылка на последнее записанное изменение в $ LogFile относительно данной записи файла в $ MFT это не имеет решающего значения для согласованности, и в любом случае я обнаружил, что ограниченный по размеру $ LogFile регулярно «удаляет» старые записи, поэтому, так как я не использовал это диск за месяцы, запись, соответствующая значению, которое было там до его очистки, была удалена, поэтому я просто поставил нули в этом поле.

---

@DrMoishe Pippik: В качестве меры безопасности я извлек все содержимое с помощью R-Studio на другой диск, прежде чем пытаться исправить это на месте. Я также сделал частичное резервное копирование первых 5 ГБ (этого достаточно, чтобы вместить все соответствующие структуры файловой системы - хотя следует подчеркнуть, что не всегда достаточно получить весь MFT, я научился этому нелегко !). Я не пытался получить доступ к диску на другом компьютере, но я не вижу, как он мог бы отличаться (в любом случае, в системе Windows - возможно, он все равно был бы распознан и доступен в системе Linux), поскольку эти три Записи MFT оказались эффективно уничтожены в WinHex, и проблема сохранилась после перезагрузки.

@cybernard: я попробовал TestDisk, это была одна из моих первых идей после проверки состояния SMART (что было и остается в порядке): он нашел раздел и мог перечислить файлы (как и другие программы, о которых я упоминал), но он не мог решить проблему, поскольку все, что он может сделать в случае повреждения MFT, это восстановить первые 4 записи, скопировав их из $ MFTMirr, но здесь эти три поврежденные записи также были повреждены в $ MFTMirr, точно таким же образом. ,

@Andrea Lazzarotto: Согласно моим наблюдениям, $ MFTMirr всегда находится в секторе 16, то есть в самом начале тома, перед фактическим $ MFT, который по умолчанию составляет около 3 ГБ. CHKDSK, вероятно, не работал, потому что $ MFTMirr также был поврежден, и поэтому он не мог получить доступ к явно важному файлу $ Volume, который также был стерт, поскольку он является частью его записи MFT.