Жесткий диск объемом 3 ТБ определяется как 746 ГБ, затем CHKDSK сильно повредил файловую систему

0

Таким образом, у меня есть два жестких диска по 3 ТБ, один из которых является резервной копией другого, почти полный (содержащий в основном видео, телевизионные документальные фильмы и еще много чего), без проблем с оборудованием (параметры SMART все в порядке). Я подключил один из них через внешний корпус Akasa Integral через USB 2.0 к своему ноутбуку, работающему под управлением Windows Vista. Жесткий диск был ошибочно определен как 746 ГБ, и был рекомендован анализ CHKDSK, предположительно, чтобы избежать повреждения данных; Я не подумал дважды и позволил ему работать ... но затем я быстро обнаружил, что он сильно повредил файловую систему: сравнение с WinMerge показало, что более 100 ГБ файлов были повреждены в различной степени (для некоторых из них только кластер был заменен или перезаписан, некоторые были полностью неправильными и нечитаемыми, для некоторых начало было фактически началом другого файла любого другого типа - например, файл MP4, казалось, имел заголовок MHT или TXT файл оказался индексом каталога и т. д.). Выполнение еще одного анализа CHKDSK на моем настольном ПК под управлением Windows 7 с жестким диском, напрямую подключенным к SATA, не восстановило эти файлы. К счастью, я не потерял ни одного важного файла, так как у меня была практически полная резервная копия, но все же я хотел бы понять, что произошло и почему.

Теперь, что здесь произошло? Это известная проблема? Может ли это быть из-за ограничения USB-контроллера этого внешнего корпуса? Обычно Windows Vista должна нормально работать с жесткими дисками объемом 3 ГБ (в отличие от предыдущих версий). Я думаю (но я не уверен), что ранее я использовал этот же внешний корпус для подключения жесткого диска емкостью 3 ТБ к тому же ноутбуку в eSATA без такой проблемы.

И может ли кто-нибудь помочь мне понять, как CHKDSK может испортить файловую систему, хотя она должна обеспечивать ее постоянную и безупречную работу? Что он сделал с MFT, чтобы получить этот результат? Считал ли он, что какой-либо кластер за пределами 2 ТБ является недействительным и должен быть нераспределенным? Тем не менее, я не смог найти какой-либо конкретный шаблон в отношении расположения затронутых файлов: большинство из них были добавлены недавно, но некоторые из них были старше, поскольку были скопированы в массовом порядке при миграции с жесткого диска меньшей емкости; некоторые из них оказались в конце, некоторые в начале, до отметки 2 ТБ (я использовал WinHex и R-Studio, чтобы выяснить местоположение).

Любая подсказка будет оценена, спасибо!

GabrielB
источник
Контроллеры SATA-USB во внешних корпусах должны поддерживать определенный том диска, и я считаю, что он также должен поддерживать тип раздела. Если в корпусе нет контроллера, который может обрабатывать установленный вами диск, он может быть представлен ОС как нечто совершенно иное. Что касается chkdsk, следует понимать, что это прежде всего утилита файловой системы, поэтому она начинается с метаданных файловой системы NTFS, а затем оценивает, насколько хорошо диск соответствует описанным метаданным. если геометрия диска искажена, у него нет надежды на правильное функционирование.
Frank Thomas
@FrankThomas Wow, спасибо за этот очень быстрый ответ! Я не проводил дальнейших испытаний с этим внешним корпусом и жестким диском 3 ТБ +, подключенным через USB, опасаясь, что это может испортить что-то еще. Но есть ли способ понять, что именно произошло, как продвигался ЧКДСК? И, основываясь на этих знаниях, было бы возможно восстановить эти файлы, если бы у меня не было резервной копии? (Я почти уверен, что это уже случилось с кем-то ...)
GabrielB
В общем, восстановление данных зависит от физического состояния диска, от того, доступны ли метаданные файловой системы и являются ли они точными, и были ли данные перезаписаны. Другая проблема заключается в том, что для восстановления необходим том, вы абсолютно не можете восстановить потерянные данные на том, с которого вы восстанавливаете. период. Я хотел бы получить другой том (не используйте свой резервный том, он может вам все еще понадобиться), скопируйте на него текущий диск как резервную копию вашего состояния. Затем я переустановил диск, как это было до фиаско корпуса, и снова попробовал chkdsk.
Frank Thomas
если chkdsk не может это исправить, вам, вероятно, придется прибегнуть к утилитам восстановления, таким как recova или easus. если те не могут восстановить данные, вам придется попробовать утилиты для вырезания файлов, такие как photorec, но, к сожалению, они работают только для файлов определенного типа, и без информации о файловой системе, имя файла и расположение папки теряются, поэтому вы получаете каталог заполнены случайными именованными файлами без понятия, что они такое. с восстановлением данных никогда не бывает никаких гарантий, поэтому не рискуйте и не сгибайте углы. храните ваши резервные копии в безопасности.
Frank Thomas
В этом случае некоторые из поврежденных кластеров были перезаписаны (по индексам каталогов или тому, что выглядит как системные файлы); это не подлежит восстановлению. Но некоторые из этих файлов, как я объяснил, оказались неправильно проиндексированы и фактически соответствуют разным файлам на одном томе без какого-либо другого повреждения потока данных. Будет ли способ систематически восстанавливать файловую систему в таком случае или, по крайней мере, восстанавливать отдельные файлы? Или это невыполнимая задача? Что касается CHKDSK, где-то должно быть большое предупреждение, чтобы предотвратить подобные вещи ...
GabrielB