LINUX.ORG.RU
ФорумAdmin

восстановление данных

 


0

1

В разделе файловая система ext4. Пытался восстановить данные testdisk-ком, но после записи резервной таблицы разделов и монтировании этого раздела, он как был пустой так и пустым остался, ни папок ни файлов, вообще ничего нет. Данные в большинстве своём были в резервных копиях, но некоторых в резерве не было, это некоторые фото - jpg, несколько doc файлов и немного текстовых файлов в кодировке utf8. Если в testdisk-е посмотреть список файлов, то он покажет все папки которые были в корне, при входе в папку, пишет вот что:
No file found, filesystem may be damaged.
Я так понимаю информации в таблице раздела о файлах нет? Использование программы autopsy дало тот же результат, папки в корне она видит, всё что дальше нет.
Потом открыл диск в hexedit и в поиске ancii кодировкой набрал номер телефона (он был в одном текстовом файле) и он нашёлся, мало того рядом был написан и второй номер телефона из этого файла.
В связи с этим у форумчан, хотел уяснить некоторые вопросы.
Если в таблице раздела и в резервных таблицах этого раздела удалить информацию о файлах, то testdisk их уже не увидит?
Можно такие файлы собрать из инодов разбросанных по диску? Есть ли информация в заголовках этих инодов о том какие принадлежат каким файлам в каком порядке они расположенных в файле и их количество?
Для текстовых файлов я так понимаю никакой информации в инодах не будет и получается их не собрать?
Есть ли такие программы в которых можно открыть диск и которые бы показали всю информацию в кодировке utf8, типа как hexedit, только не в 16-ричном выводе, а в текстовм - utf8, я бы тогда просто выбрал текстовую информацию которая нужна и пересохранил в другом файле, если есть такие, то как они называются?
За помощь заранее благодарен!

★★

Последнее исправление: v4567 (всего исправлений: 1)

то testdisk их уже не увидит

Естесно. И никто не увидит. Как минимум утеряно имя файла и атрибуты.

Можно такие файлы собрать из инодов разбросанных по диску?

Теоретически можно. Практически - собирается то, что небыло фрагментировано. Если разные куски одного файла лежат в разных кусках диска - вряд ли ты их сможешь сопоставить. Ну, есть, конечно, всякая эвристика по типу jpeg: тупо подставляем в файл всё, что осталось на диске пока он не станет валидным, или ручной просмотр.

типа как hexedit, только не в 16-ричном выводе, а в текстовм - utf8

photorec прогони. Если ей сказать, что искать текстовики, то на выходе будет много txt, а там из них сам уже выберешь, что надо. То, что не является текстом - будет отсеяно.

Ну или сделай дамп диска и открой его в текстовом редакторе, гг

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от Deleted

Woolf Спасибо за помощь!

По поводу инодов вот что хотел узнать. В самом первом иноде будет такая информация: тип файла - например jpg или doc, из скольких инодов этот файл состоит, это первый инод, в других инодах информация о том что они принадлежат этому файлу и их порядковые номера, или такой информации в самих инодах вообще нет? Правильно я понимаю такая информация должна быть в таблице раздела, а в не инодах?


photorec - сейчас пробую восстановить.
Пробовал восстановить программой scalpel. Указал ему только текстовые файлы, он понаходил - вообще не то.
По поводу открытия в редакторе, вот так можно открыть:

vim /dev/sdb2

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

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

Смотри. Во-первых, тебе нужно сделать всё же образ диска. Без вариантов. Потом уже этот образ моно примонтировать. Нахрена это надо? Всё просто: тебе нужно для начала попытаться произвести опасные операции на разделе.

Для начала, примонтировав ФС ты должен найти резервный суперблок. Как это делается - я не знаю (не задавался вопросом). При форматировании, обычно, mkfs показывает, где они лежат :).

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

Вот в общем, должно дать понимание.

Deleted
()
Ответ на: комментарий от Deleted

Woolf Чем посоветуете открыть образ диска. Пытаюсь less, в utf8 показывает отлично, но чем дальше к строкам делаю переход при запуске тем сильнее и сильнее вешает систему. При поиске то же систему постепенно завешивает.
Раздел где то около 40 гиг, я хотел его потихоньку просмотреть и найденную текстовую информацию сохранить, просто скопировав и сохранив в другом окне в файлик. Программы photorec, scalpel и им подобные не помогли, просто не нашли эти файлы и всё. В hexedit поиском находил номера телефонов, так что информация вся есть.
Пытался открыть образ при помощи vim, но ничего так и не получилось, может не так открывал. Из всего опробованного less лучше всего, но чем не дальше тем он всё сильней и сильней вешает систему. Открыв в less образ с нумерацией строк пытался перейти на последнюю строку, хотел узнать сколько всего строк, система умерла напрочь, не реагировала даже на клавиатуру, пришлось ресетом перезагружаться.

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

Как бы само по себе открытие терабайтного (?) файла 0 трудоемкая операция. Открыть можете хоть чем, но на мощной машине. Я бы предложил использовать mcedit - оно вроде большие файлы открывает нормлаьно. Но следует понимать, что поиск по такому файлу это... Гхм. Весьма и весьма трудозатратная операция. Можно нарезать файл на куски и открывать кусками. ПРи ручном поиске других вариантов нет. Я бы порезал файлы кусками по 10G и открывал в той же kate (надо естесно мощную машину и лагать все равно будет).

Deleted
()

Наиболее полезной будет extundelete или как-то так.

Deleted
()
Ответ на: комментарий от Deleted

mcedit тоже прекрасно вешается на больших файлах

нарезать файл на куски и открывать кусками

мысль здравая, но

файлы кусками по 10G

за гранью добра и зла

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.