Можно ли восстановить файлы, удаленные rm в Linux?

8

В окнах удаленных можно найти в корзине, если вы не нажали Shift ,

Как насчет файлов, удаленных rm -fв Linux

WAMP
источник
3
Windows называет его Корзиной уже более 10 лет; и когда вы нажимаете удалить, он явно говорит, что перемещает файл, а не удаляет его. rmснимает связь с i-узлом, связанным с файлом.
Крис С

Ответы:

13

Первое, что нужно запомнить - прекратить любые дальнейшие операции записи в файловой системе.

Затем вы можете попробовать некоторые инструменты, которые будут смотреть на файловую систему и пытаться найти данные в удаленном узле. ' extundelete' является одним из таких инструментов в SourceForge.

extundelete - это утилита, которая может восстанавливать удаленные файлы из раздела ext3 или ext4 . Файловая система ext3 является наиболее распространенной файловой системой при использовании Linux, а ext4 является ее преемником. extundelete использует информацию, хранящуюся в журнале раздела, чтобы попытаться восстановить файл, который был удален из раздела. Нет никаких гарантий, что какой-либо конкретный файл сможет быть восстановлен, поэтому всегда старайтесь иметь хорошую систему резервного копирования или, по крайней мере, устанавливайте ее после восстановления ваших файлов!

Nik
источник
3
Никакие дальнейшие записи не могут быть подчеркнуты достаточно. Он не является встроенным, поэтому «восстановление» - это вопрос программного обеспечения восстановления, собирающего оставшиеся части до того, как файловая система перезаписывает данные при будущих записях.
Джереми М
2

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

Как уже упоминалось, ext3grep и extundelete - это инструменты для семейства файловых систем ext.

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

Прежде всего это один из вариантов, который я использовал для этого.

Последний вариант, если вам известно о какой-то определенной строке в файле, это открыть диск в шестнадцатеричном редакторе и найти эту строку.

В зависимости от ваших настроек ваш оконный менеджер может предоставить корзину / мусорное ведро.

В конце концов, ничто не заменит хорошую настройку системы резервного копирования. Найдите тот, который делает свою работу, не касаясь его, и настройте его. Вы сэкономите много времени, проблем и боли в долгосрочной перспективе.

dpflug
источник
0

Как undelete_ext3 , кажется, нет, вот скромный Баш скрипт, который помог мне восстановить некоторые файлы , которые были недостижимы с помощью extundelete или debugfs . Решение поделилось.

Вы можете просмотреть список блоков для просмотра, см. PRESEED. Требуется один номер блока в строке. Если вы не используете preseed, все блоки будут найдены по умолчанию.

  • Для каждого блока первые байты проверяются на содержание gzip.
  • В случае успеха рассматриваемый блок будет застрелен для дальнейшего поиска строки «ustar» в байте 257, размечая архив tar.
  • Наконец, данные, соответствующие шаблону файла, извлекаются (стиль суффикс-пути с использованием параметра подстановки tar) и записываются для определенной строки. Смотрите переменные FILE_IN_TAR и FIT_CONTENT для этого.
  • Если найдено, сохраните файл.

Поскольку у вас, вероятно, будет другой сценарий использования, это может дать вам основу, на которой будет основана ваша собственная фильтрация. Вам обязательно нужно настроить значения при поиске других типов файлов.

Пример вызова: ./ext-undelete-tar-gz.sh devimage found_files/

#!/bin/bash

# Brute force (linear) search specific tar files with
# certain contents on ext2 / ext3 / ext4 devices or files
#
# .. this is a last resort if extundelete and/or debugfs
#    did not find what you were looking for and limited
#    in that recoverable data must not have been stored
#    in fragments, i.e. non-sequentially

[[ -n "$2" ]] || {
    echo "usage: $0 [ device | imagefile ] "\
    "[ destdir_for_recovered_data ] "\
    "[ max_blocks_to_search (optional) ]" 
    exit 1
}

IMG=$1
DEST=$2
TMP=/dev/shm/cand.tmp
PRESEED=/dev/shm/cand.list

GZMAGIC=$(echo -e "\x1f\x8b\x08")
TARMAGIC=$(echo -e "ustar")

# max bytes to read into $TMP when a .tar.gz has been found
LEN=$((160*1024))

# pick $TMP for recovery based on matched strings..
FILE_IN_TAR="debian/rules" # ..in the tar index (suffix-search)
FIT_CONTENT="link-doc="    # ..within FILE_IN_TAR matches

# determine FS parameters
BLOCKS=$(tune2fs -l $IMG | grep -Po "(?<=^Block count:).*" | xargs)
    BS=$(tune2fs -l $IMG | grep -Po "(?<=^Block size:).*"  | xargs)
LEN=$((LEN/BS))

function _dd     { dd     $@ 2>/dev/null ; }
function _gunzip { gunzip $@ 2>/dev/null ; }
function _tar    { tar    $@ 2>/dev/null ; }

function inspect_block {
    bnum=$1

    if _dd if="$IMG" skip=$bnum bs=$BS count=1 | tee "$TMP" \
    | _dd bs=1 count=3 \
    | grep -qF "$GZMAGIC" 
    then
        if _gunzip -c "$TMP" \
        | _dd bs=1 count=5 skip=257 \
    | grep -qF "$TARMAGIC"
        then
            _dd if="$IMG" skip=$((bnum+1)) bs=$BS count=$((LEN-1)) >> "$TMP"
            echo -n found $bnum.tar.gz

            if _tar xzf "$TMP" -O --wildcards *"$FILE_IN_TAR" \
            | grep -qF "$FIT_CONTENT"
            then
                echo " ..picked, stripping trailing garbage:"
                exec 3>&1
                gunzip -c "$TMP" 2>&3 | gzip > $DEST/$bnum.tar.gz
                exec 3>&-
            else
                echo
            fi
        fi
    fi

    echo -ne "$((bnum+1)) / $BLOCKS done.\r" >&2
}


if [[ -f "$PRESEED" ]]
then
    while read bnum
    do inspect_block $bnum
    done <"$PRESEED"
else
    for (( bnum = 0 ; bnum < ${3:-$BLOCKS} ; bnum++ ))
    do inspect_block $bnum
    done
fi | gzip >"$PRESEED.log.gz"

echo
  • Прекратите использование рассматриваемой файловой системы после того, как заметите ошибочное удаление как можно скорее.
  • Этот сценарий, вероятно, не будет работать с большими файлами, он не анализирует структуры более высокого уровня файловой системы.
  • По сути, современные файловые системы не предназначены для надежного восстановления несвязанных данных, поэтому нет гарантий восстановления потерянных данных.
  • Работать с резервной копией файловой системы.
Шеф-повар Мейстер
источник
Если файл больше 12 блоков, то я думаю, что вы, скорее всего, найдете блоки косвенности между блоками данных. В этом случае простое последовательное чтение приведет к выводу мусора. Но если вам удастся найти блоки косвенности, вы можете восстановить оставшуюся часть файла (если, конечно, он не был перезаписан).
Касперд