Это будет длинный текст, потому что я не уверен, какие части предыстории актуальны - если вы хотите пропустить скучные части, вы можете просто прочитать два последних абзаца, в которых есть актуальный вопрос.

Короче говоря, я был небрежен с утилитой разбиения и испортил свои разделы, возможно, испортил некоторые файлы, так как происходила операция изменения размера раздела, которая перемещала файлы, когда мне приходилось завершать процесс утилит. В результате последний раздел (около 420 ГБ) на диске исчез, забрав с собой мой компьютер /home. Мои резервные копии, скажем так, немного устарели, поэтому я решил попытаться восстановить столько, сколько смог, и почистить их позже.

Я запустил живой дистрибутив Linux, предназначенный для восстановления данных, и запустил Testdisk, чтобы посмотреть, сможет ли он найти отсутствующий раздел. При первом запуске я настроил "разделы Intel", проанализировал диск с помощью быстрого и более глубокого поиска и ничего не нашел. Я подумал, что, поскольку я знал, как выглядит таблица разделов до аварии, я использовал GParted, чтобы воссоздать потерянный раздел (без какого-либо форматирования) и повторить попытку. С разделами Intel, Testdisk все еще не мог найти ничего в конце диска, поэтому я попытался с опцией запуска "Без разделения". На этот раз анализ обнаружил раздел, который я воссоздал, и в списке файлов я мог фактически увидеть мои отсутствующие файлы (наряду с множеством файлов, которые я ранее также удалил). Выиграть!

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

Как я уже упоминал ранее, размер потерянного раздела составлял около 420 ГБ. Жесткий диск, на котором находится раздел, составляет 1 ТБ. На данный момент Testdisk работает около 15 часов (я копирую файлы через USB2.0, sloooow), и df сообщает, что на внешнем диске сейчас более 900 ГБ. Когда я проверяю содержимое копии, кажется, что там еще не так много контента, хотя, возможно, я пропустил несколько больших файлов.

Как TestDisk может скопировать более 900 ГБ данных из раздела размером 420 ГБ? Есть ли какое-то предварительное распределение для копирования удаленных файлов, которые Testdisk может видеть, но которые на самом деле больше не восстанавливаются?

1 ответ1

0

Ответ - testdisk/photorec, часто перехватывающий. Иногда начальный маркер, конечный маркер или размер файла повреждены, или он делает неправильное предположение и захватывает больше секторов, чем нужно для файла. Затем другой файл имеет указатель в этой области, и он снова захватывает перекрывающиеся сектора.

Итак, теперь файл 1 содержит все файлы 1 плюс случайные данные. Файл 2 содержит часть случайных данных. Часто эти программы плохо обрабатывают фрагментированные файлы, что также может привести к перехвату данных.

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

Я нашел файлы, такие как Word Docs, они говорят 2 ГБ, но при открытии и повторном сохранении под новым именем они возвращают туда правильный размер.

Представьте, что каждый символ представляет собой кластер хранилища.

G - это файл GIF W - это документ Word, который не используется

GGGGGWWWWUUUG

Большинство файлов имеют верхний и нижний колонтитулы. Поэтому, когда сканы обнаруживают заголовок GIF, он ищет нижний колонтитул для GIF. Итак, теперь восстановленный GIF-файл содержит GGGGGGGWWWWUUUG, потому что файл фрагментирован. Затем при сканировании вперед он обнаруживает W или верхний колонтитул слова и нижний колонтитул, поэтому текстовый документ корректно отображается как WWWW, несмотря на более ранний перехват.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .