Как восстановить файлы, усеченные `& gt;`?

Выполните следующие команды в терминале:

ls -la .VirtualBox/VirtualBox.xml*
cp .VirtualBox/VirtualBox.xml-prev .VirtualBox/VirtualBox.xml
1
задан 9 January 2014 в 23:48

2 ответа

Я случайно обрезал файл с помощью gedit. Он был усечен с 1800 КБ до 25 кБ.

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

Сначала перемонтируйте файловую систему как только для чтения !. Сделайте это как можно скорее.

sudo mount -o remount,ro /

В моем случае я не смог повторно установить readonly, поэтому ...

Не удалось выполнить команду mount. с ошибкой mount: / is busy.

Я рекомендую решительный шаг только жесткого отключения вашего устройства. Да, решительно! Но я не знаю, как долго будут остатки усеченного файла. Они могут быть перезаписаны в любой момент. Загрузитесь в Ubuntu LiveCD.

Это похоже на этот пост , я побежал telinit 1, который упал до уровня init 1. Это только сложные вещи, поэтому я не рекомендуем делать telinit 1. Я рекомендую жесткую власть.

попытка использования ext3grep

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

попытка использования sleuthkit

sleuthkit - классный набор инструментов. Вам, вероятно, придется его установить. Опять же, это получить сложно, если усеченный файл был / mount. Опять же, я рекомендую отключить питание, а затем запустить LiveCD. После этого сообщения в блоге и этого блога, инструкции по существу

apt-get install sleuthkit stat truncated-file | grep Inode запомните номер inode (назовите его INODE_NUMBER), создайте резервную копию файла, затем удалите его: cp -a truncated-file truncated-file.old rm truncated-file debugfs /dev/disk-device stats найдите блоки на группу. Это очень вероятно 32768. (назовите его BLOCKS_PER_GROUP ) imap, чтобы получить блок imap <$INODE_NUMBER>, запомните номер блока (назовите его BLOCK_NUMBER) используйте blkls для копирования блоков в файл blkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file вручную просмотрите и очистите восстановленный файл с помощью некоторой программы редактора

Но sleuthkit не работал для меня.

попытается использовать extundelete

это сообщение в блоге .

попытается использовать grep

53] Из этого сообщения grep для некоторой известной строки в усеченном файле. Это единственный метод, который работал для меня.

grep -a -A 1000 -F 'some known string' /dev/disk-device > recovered-file
2
ответ дан 24 May 2018 в 13:10

Извините, это невозможно ...

Вы можете восстановить удаленные файлы, но вы не можете восстановить файл с удаленным контентом ..

0
ответ дан 24 May 2018 в 13:10
  • 1
    Я не очень разбираюсь в файловых системах, но я полагаю, что когда вы просто устанавливали файл на нулевые байты, например, на OP, диск действительно не удаляет содержимое файла. Я считаю, что он просто устанавливает файл в нулевые байты, так что ранее занятое пространство становится «бесплатным». Поэтому теоретически это возможно, если я прав (конечно, предполагается, что жесткий диск не был навязан после операции) ... как вы думаете? Я сделаю какой-нибудь поисковик. – GabrielF 9 January 2014 в 23:36
  • 2
    Когда вы создаете файл, ОС просто резервирует пространство, необходимое для файла. во всяком случае, это 1 и 0 на самом деле не очень верно, что нет ни одного 1 и нет действительно 0 есть значения, близкие к 1 и 0. В любом случае. когда какое-то тело записывается в файл, пространство зарезервировано. когда u delete u make 1 останется 1. Я имею в виду, что Os все равно покажет, что этот файл найден, поэтому он напишет новый файл только поверх старого с тем же смещением и начальным и конечным секторами. Так что это невозможно, так или иначе, надеюсь, вы сможете найти что-то еще с Google – Maythux 9 January 2014 в 23:40

Другие вопросы по тегам:

Похожие вопросы: