Есть ли команда для восстановления / восстановления удаленных файлов rm
?
$ rm -rf /path/to/myfile
Как я могу восстановиться myfile
? Если есть такой инструмент, как я могу его использовать?
Есть ли команда для восстановления / восстановления удаленных файлов rm
?
$ rm -rf /path/to/myfile
Как я могу восстановиться myfile
? Если есть такой инструмент, как я могу его использовать?
Ответы:
Ссылка, предоставленная кем-то в комментариях, вероятно, ваш лучший шанс.
Linux debugfs Hack: восстановление файлов
Эта статья, хотя выглядит немного пугающе, на самом деле довольно проста для подражания. В общем, следующие шаги:
Используйте debugfs для просмотра журнала файловых систем.
$ debugfs -w /dev/mapper/wks01-root
В приглашении debugfs
debugfs: lsdel
Образец вывода
Inode Owner Mode Size Blocks Time deleted
23601299 0 120777 3 1/ 1 Tue Mar 13 16:17:30 2012
7536655 0 120777 3 1/ 1 Tue May 1 06:21:22 2012
2 deleted inodes found.
Запустите команду в debugfs
debugfs: logdump -i <7536655>
Определить файлы inode
...
...
....
output truncated
Fast_link_dest: bin
Blocks: (0+1): 7235938
FS block 7536642 logged at sequence 38402086, journal block 26711
(inode block for inode 7536655):
Inode: 7536655 Type: symlink Mode: 0777 Flags: 0x0 Generation: 3532221116
User: 0 Group: 0 Size: 3
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4f9fc732 -- Tue May 1 06:21:22 2012
atime: 0x4f9fc730 -- Tue May 1 06:21:20 2012
mtime: 0x4f9fc72f -- Tue May 1 06:21:19 2012
dtime: 0x4f9fc732 -- Tue May 1 06:21:22 2012
Fast_link_dest: bin
Blocks: (0+1): 7235938
No magic number at block 28053: end of journal.
Используя приведенную выше информацию об индексах, выполните следующие команды
# dd if=/dev/mapper/wks01-root of=recovered.file.001 bs=4096 count=1 skip=7235938
# file recovered.file.001
file: ASCII text, with very long lines
Файлы были восстановлены в recovered.file.001
.
Если вышесказанное не для вас, photorec
в прошлом я использовал такие инструменты, как восстановление файлов, но он предназначен только для файлов изображений. Я подробно писал об этом методе в своем блоге в этой статье под названием:
Как восстановить поврежденный JPEG и мы файлы с SDD карты цифровой камеры на Fedora / CentOS / RHEL .
debugfs -w /dev/sdb2
но lsdel
0 deleted inodes found.
extundelete
легче ext3 / 4 и, вероятно , приведет к тем же результатам.
/dev/mapper/wks01-root: No such file or directory while opening filesystem
Где вы это взяли /dev/mapper/wks01-root
из?
С небольшой вероятностью иногда я могу восстановить удаленные файлы с помощью этого сценария или следующего решения в ответе:
#!/bin/bash
if [[ ! $1 ]]; then
echo -e "Usage:\n\n\t$0 'file name'"
exit 1
fi
f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep "$1 (deleted" | awk '{print $9}')
if [[ $f ]]; then
echo "fd $f found..."
cp -v "$f" "$1"
else
echo >&2 "No fd found..."
exit 2
fi
Есть еще одна полезная хитрость: если вы знаете шаблон в ваших удаленных файлах, наберите alt+ sys+ resuoдля перезагрузки + перемонтировать только для чтения, затем с live-cd используйте grep
для поиска на жестком диске:
grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover
затем отредактируйте, /tmp/recover
чтобы сохранить только те файлы, которые были раньше.
Эй, если с философией Unix все файлы, пришло время воспользоваться этим, нет?
grep
основанное на нем решение очень умно и работает для меня, даже если файловая система все еще смонтирована. Спасибо!
grep -av "[^[:print:]]"
grep
Решение работал для меня с модификацией: я сделал sudo grep --line-buffered -ab "$PATTERN" /dev/sda1 | tee lines
и получил смещение байта (как 123123123:line\n456456456:another\n...
), а затем сделал n=1000; sudo dd of=before if=/dev/sda1 ibs=1 skip=$[123123123-$n] count=$n
и n=1000; sudo dd of=after if=/dev/sda1 ibs=1 skip=123123123 count=$n
с разными n
значениями.
То, что сработало для меня, было предоставлено arch (относится только к текстовым файлам)
grep -a -C 200 -F 'Unique string in text file' /dev/sdXN
где /dev/sdXN
раздел, содержащий потерянный файл (проверьте, mount
если не уверены).
Это заняло немного времени, но сработало, когда я случайно удалил некоторый исходный код, который еще не зафиксировал!
rm data/*.json python myFile.py
вместоrm data/*.json && python myFile.py
/dev/sdXN
это для файловой системы, верно? Я нашел свой сdf -T | awk '{print $1,$2,$NF}' | grep "^/dev"
grep: conflicting matchers specified
Хотя этот Вопрос решен и ему несколько лет, я хочу упомянуть утилиту testdisk .
Как восстановить файлы с помощью testdisk хорошо объясняется в этом руководстве . Для восстановления файлов запустите testdisk /dev/sdX
и выберите тип таблицы разделов. После этого выберите [ Advanced ] Filesystem Utils
, затем выберите свой раздел и выберите [Undelete]
. Теперь вы можете просматривать и выбирать удаленные файлы и копировать их в другое место в вашей файловой системе.
У меня была та же проблема на прошлой неделе, и я пробовал много программ, таких как debugfs, photorec, ext3grep и extundelete. ext3grep была лучшей программой для восстановления файлов. Синтаксис очень прост:
ext3grep image.img --restore-all
или же:
ext3grep /dev/sda3 --restore-all --after date -d '2015-01-01 00:00:00' '+%s' --before `date -d ‘2015-01-02 00:00:00’ ‘+%s’
Это видео - мини-учебник, который может вам помочь.
Альтернативой может быть использование del
вместо rm
удаления:
http://fex.belwue.de/fstools/del.html
del
имеет функцию восстановления и работает с любой файловой системой.
Конечно, это не решение проблемы, если вы уже удалили свои файлы с помощью команды «не брать в плен». Rm: -}
del
команды.
подключите диск через внешний интерфейс
umount /dev/{sd*}
extundelete --restore-all /dev/{sd*}
Смотрите эту ссылку для получения дополнительной информации: восстановить только что удаленный файл на ext4 с помощью extundelete .
Инструменты восстановления - Командная строка:
Инструменты восстановления - Gui:
Информация:
По своему личному опыту я возвращаю свои данные с помощью ufs-explorer и photorec.
(1) = Не с открытым исходным кодом, не бесплатно
(2) = Не с открытым исходным кодом, бесплатно
(3) = с открытым исходным кодом и бесплатно
(4) = есть поддержка NTFS
(5) = иметь структуру каталогов
Я не согласен с тем, что это невозможно, просто очень и очень сложно, и я никогда не делал это на Linux:
Когда файлы удаляются, они на самом деле не удаляются. Что происходит, так это то, что пространство, на котором они находились на жестком диске, является своего рода сбросом, поэтому, если компьютер пытается записать данные туда, ничто не будет жаловаться. Как правило, данные на вашем жестком диске, которые вы считали удаленными, могут появиться почти год спустя. Или, по крайней мере, это мой опыт работы на компьютере с Windows. Я не уверен, работает ли он так же, как из командной строки в Linux, но вам, вероятно, понадобится отдельный Live CD, чтобы открыть такой раздел, и также нет гарантии, что файлы все еще там. Я сделал это на Windows XP несколько раз, используя Zero Assuming Recovery. Я уверен, что есть похожий инструмент, если вы посмотрите достаточно внимательно.
Когда вы удаляете файл, количество ссылок в таблице узлов для этого файла уменьшается на единицу. В Unix, когда количество ссылок уменьшается до 0, блоки данных для этого файла помечаются как свободные и, как правило, ссылки на эти блоки данных теряются. Я только что обнаружил из комментария @ fedorqui, что может быть какой-то способ доступа к этим блокам, но это применимо только к файловой системе ext3.
Одним из способов сохранения файлов будет написание функции, которая позволит вам перемещать файлы в корзину (скажем так $HOME/.trash
) и восстанавливать необходимые файлы оттуда. Эта функция может быть привязана к rm
. Вы можете запланировать задание cron для удаления файлов, которые находились в области мусора в течение определенного количества дней.
Это может спасти некоторых из вас.
Если вы когда-либо использовали gedit для редактирования этого файла, по умолчанию будет создана копия этого файла.
Например, давайте предположим, что мы случайно удалили «myfile.txt».
В папке, которая раньше содержала файл, который вы только что удалили, используйте эти команды, и вы восстановите копию оттуда:
ls | grep 'myfile.txt~'
если вам повезет, вы найдете ее и затем:
cp 'myfile.txt~' 'myfile.txt'
я только что восстановил файл, используя этот метод. Удачи!