Не может восстановить отформатированную файловую систему раздела Ext4.:( Предложения?

Я был в этом в течение многих дней теперь, таким образом, я надеюсь, что можно помочь мне!

Исходная установка: Это - 200 ГБ firewire диск, первоначально отформатированный с помощью Диспетчера дисков Ubuntu 11.04 с Главной загрузочной записью и единственного раздела Ext4. Раздел был зашифрован через опцию Disk Manager, "шифруют базовую файловую структуру".

Незашифрованный раздел первоначально содержал много текстовых файлов и 2 Контейнера Файла Truecrypt на 63 ГБ, которые первоначально находились на картах с интерфейсом USB на 64 ГБ.

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

• В Диспетчере дисков у меня был исходный разблокированный раздел диска и не смонтированный. Я выбрал базовый раздел через GUI и нажал "Format Partition" как Ext4, никакое шифрование.

После того как я понял то, что происходило, я сорвал кабель и сразу сделал копию с dd и теперь отделываюсь от этого.

Состояние: Так как я не смешал с передней стороной диска, заголовок LUKS и MBR являются все еще исходными и неповрежденными, и раздел неблокируем через диалоговую или командную строку всплывающего окна Ubuntu. Сам незашифрованный раздел все еще имеет ту же геометрию, но так как это получило частичный формат, файловая система, по-видимому (частично?) поднятый.

• Новый раздел не смонтируется, и fsck возвраты 'неправильный тип фс', плохой суперблок, и т.д.

• Если я загружаюсь в Ubuntu и включаю диск без разблокирования,/dev/mapper имеет отображение с UUID устройства (я скопировал бы его в здесь, но я в настоящее время загружаюсь в Hiren). Я заметил от включения других зашифрованных дисков, они отображаются здесь UUID на, разблокировали, таким образом, я предполагаю, что это вызвано тем, что копия была сделана с dd с разделом, все еще разблокированным?

• Если я загружаюсь в BootCD Hiren и перешел к/dev/mapper, вышеупомянутое отображение не показывают (я предполагаю, что это происходит из-за того, как Ubuntu обрабатывает зашифрованные диски). Я могу разблокировать через cryptsetup luksOpen и успешно отобразите устройство здесь tho.

• fsck/e2fsck не может найти допустимый суперблок на связанном устройстве или на Ubuntu или на Hiren, я также попробовал каждый возможный резервный суперблок напрасно.

• TestDisk находит серию разделов спама со странными размерами и файловыми системами, которые никогда не существовали на диске. Я предполагаю, что это происходит из-за коллизий, когда это сканирует через Контейнеры Файла TrueCrypt. Насколько я понимаю, хотя, TestDisk, прежде всего, для восстановления таблиц разделов, не файловых систем, да?

• PhotoRec только возвращает 3 файла спама, а также быть бесполезным для восстановления Контейнеров Файла TrueCrypt, так как они шифруются от первого бита до последнего.

• A hexdump -C на связанном устройстве показывает 0 до строки 00020000. (Ubuntu обнуляет данные по формату по умолчанию??? Если это верно, я знаю, что я полностью безнадежен здесь.) Обновление: я предполагаю, что t его - то, где файловая система хранится в, не так ли?

Вопрос: у Меня есть довольно низкое понимание *, отклоняют командную строку и хранение данных низкого уровня, но изучали много на этой неделе, когда я работал над этим. Так как формат не завершался, мне нелегко полагать, что ВСЕХ исходных суперблоков не стало. Текстовые файлы потребляемы (они были по существу заархивированными электронными письмами), но я очень хотел бы иметь те Контейнеры Файла TrueCrypt назад. К сожалению, я знаю, что это - возможно, небольшой шанс, потому что они - гигантские зашифрованные файлы в шифровании.

Я видел mke2fs -S предложенный и собираюсь попробовать это после того, как я закончу делать новую копию плохого диска. Есть ли какая-либо надежда? Я проявляю неправильный подход к этому?:(

Эти данные представили месяцы работы и обычно сохраняются, это только не имело никакого резервного копирования в течение одного дня, потому что я беден и перемещал данные вокруг своих жестких дисков, пытающихся консолидировать пространство. Я фигурирую, взяло ли это меня, что долго для создания его стоит провести несколько недель, пытаясь возвратиться, таким образом, я открыт для какого-либо количества безумных предложений (как, я не мог теоретически сделать hexdump целого раздела и воссоздать эти файлы на 63 ГБ от этого?).

Заранее спасибо! :)

Обновление:

Я работал mke2fs -S -t ext4 /dev/mapper/sdb1crypt (забыл копировать результаты, собравшись пробовать его снова, таким образом, я отправлю его затем), сопровождаемый e2fsck -y /dev/mapper/sdb1crypt который занял приблизительно 10 часов для окончания. На перезагрузке я нашел приблизительно 400 000 случайных файлов в lost+found папке. Это не может быть правильно, не так ли?

Обновление 2:

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

# grep -R "txt" /dev/mapper/sdc1_crypt
Binary file /dev/mapper/sdc1_crypt matches
# grep -R "psd" /dev/mapper/sdc1_crypt
Binary file /dev/mapper/sdc1_crypt matches
# grep -R "ai" /dev/mapper/sdc1_crypt
Binary file /dev/mapper/sdc1_crypt matches
# grep -R "eps" /dev/mapper/sdc1_crypt
Binary file /dev/mapper/sdc1_crypt matches

Я также работал # grep -R "HALsGoneBad" /dev/mapper/sdc1_crypt, потому что я знаю, что у меня нет файлов, названных этим, и это все еще ищет (бывший похожий 10 минут).

Что grep нахождение, здесь? Это означает, что моя файловая система частично неповреждена где-нибудь? Gah! Я чувствую, что я так близок!

Я не знаю, как inode таблицы работают, но интересно, я могу возможно просмотреть inode таблицу так или иначе и просто искать ту, которая ссылается на файл на 63 ГБ?