it-swarm-ru.tech

Как восстановить удаленный файл под Linux?

Случайно я использовал rm для файла, который не хотел удалять. Есть ли способ вернуть его под Linux?

65
HaiYuan Zhang

Ниже приведены общие шаги для восстановления текстовых файлов.

  1. Сначала используйте команду wall, чтобы сообщить пользователю, что система отключается в однопользовательском режиме:

    # wall
    System is going down to .... please save your work.
    

    Нажмите CTRL + D, чтобы отправить сообщение.

  2. Затем используйте команду init 1, чтобы перевести систему в однопользовательский режим:

    # init 1
    
  3. Использование grep (традиционный способ UNIX) для восстановления файлов

    Используйте следующий синтаксис grep:

    grep -b 'search-text' /dev/partition > file.txt
    

    OR

    grep -a -B[size before] -A[size after] 'text' /dev/[your_partition] > file.txt
    

    Куда,

    -i : Ignore case distinctions in both the PATTERN and the input files i.e. match both uppercase and lowercase character.
    -a : Process a binary file as if it were text
    -B Print number lines/size of leading context before matching lines.
    -A: Print number lines/size of trailing context after matching lines.
    

    Чтобы восстановить текстовый файл, начинающийся с «nixCraft» Word в/dev/sda1, вы можете попробовать следующую команду:

    # grep -i -a -B10 -A100 'nixCraft' /dev/sda1 > file.txt
    
  4. Затем используйте vi, чтобы увидеть file.txt.

    Этот метод полезен, только если удаленный файл является текстовым файлом. Если вы используете файловую систему ext2, попробуйте восстановить команду.

Найдено на http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html

50
Gabriel L. Oliveira
  • Если это очень-очень важно, возьмите диск с компьютера и наймите компанию, которая сделает это за вас.
  • Если это только очень важно, подключите диск только для чтения, скопируйте весь раздел в файл, используя dd, и попытайтесь найти файл в нем (используя grep или редактор).

Правка: иногда ddrescue работает лучше, чем dd.

13
Sjoerd

Если вашей файловой системой является ext3 , используйте ext3grep .

9
zaynyatyi

Testdisk имеет опцию восстановления, которая должна работать с Linux.

Существует прохождение для Linux . Обратите внимание, что это работает для ext2 , ext3 и ext4 .

8
James T

Если это стандартный rm , я надеюсь, у вас есть резервная копия. Процедура восстановления удаленного файла будет разной для каждой файловой системы, если это вообще возможно сделать. В Linux нет встроенной корзины. как только вы удалите файл, он почти исчез.

В любом случае вы захотите отключить компьютер от сети - как можно скорее, так как продолжение работы компьютера (даже выключение) вызывает запись на диск и увеличивает вероятность того, что некоторые блоки ранее были заняты файл будет перезаписан. Как только вы это сделаете, либо вставьте его в другой компьютер, перезагрузите компьютер с live CD (не устанавливая диск, если вы не монтируете его только для чтения), или извлеките жесткий диск и перенесите его на специалист по восстановлению данных.

5
cHao

Я сделал это пару лет назад. Мой подход состоял в том, чтобы напрямую, не терять времени, размонтировать раздел, а затем

dd if=/dev/hda1 of=backup_image.ext3

иметь файл резервной копии точного состояния раздела. Затем вы можете снова смонтировать раздел и продолжить работу в обычном режиме, когда будете искать удаленный файл в созданном вами образе. Изображение, вероятно, будет ОЧЕНЬ большим, так как вам нужно все «пустое» пространство, поэтому его хранение может оказаться практической проблемой.

Тогда это было просто для того, чтобы выполнять скучные поиски по фрагментам текста, которые я ожидал найти где-то в супе содержимого раздела. Например. чтобы найти .tex-файлы, я побежал

grep --binary-files=text -1000 "subsection" < backup_image.ext3 > latexfiles

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

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

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


Краткие технические примечания: есть технические трудности с восстановлением диска и Ext3/4. Объяснять это долго, но кратко (и неадекватно): Ext3/4 удаляет «маркеры», которые сообщают ОС, где файлы находятся на диске, когда вы их удаляете. Файлы не очищаются, но никто не знает, где на диске они начинаются и заканчиваются, а иногда они даже фрагментированы в нескольких местах. Некоторые другие файловые системы просто устанавливают статусы файлов как «удаленные», но сохраняют данные о местоположении. Тогда восстановить не сложнее, чем посмотреть на файловые указатели с этим флагом (они все равно должны быть доступны, если не произошло слишком много действий), и затем надеяться, что их содержимое не было перезаписано.

Что лучше? Риторический, на мой взгляд. Частое резервное копирование является ответом на все эти проблемы. Важные данные без автоматизированной системы резервного копирования - случайность, ожидающая случиться, ИМХО.


Обязательный личный анекдот: я собирался удалить foo\ foo* из ~. я написал

rm -r foo<Tab>*

К сожалению, поскольку foo, по-видимому, была символической ссылкой и единственным файлом, соответствующим этому, Shell

rm -r foo\ foo *

Я нажал Enter и сел там, глядя на команду, которая должна была занять максимум секунду. Через некоторое время rm спросил меня, хочу ли я «удалить файл с защитой от записи« что-то »». Довольно быстро я почувствовал озноб и мягко и очень контролируемо нажал Ctrl+c. ~ Половина моего ~ была удалена, но мне удалось вернуть все, что имело значение, с помощью описанного выше поиска и некоторых более или менее текущих резервных копий. У меня были некоторые очень ценные (читай: отнимающие много времени) и самые последние данные измерений на диске, которые были утеряны, но я сделал четырехкратное резервное копирование. Один здесь разочаровался, другой из-за сбоя системы в школе, другой был поврежден, и сначала я не смог найти четвертый, так как по ошибке положил его в неправильную папку :-D. Если бы rm -r не застрял в файле, защищенном от записи, четвертый был бы съеден, так как эта папка была смонтирована через sshfs в моем ~. С тех пор я гораздо осторожнее с такими вещами.

5
Daniel Andersson

Установите ваши ожидания на низком уровне. Если что-то было записано поверх «удаленных» данных, вы потеряете это.

Я провел небольшое количество восстановления, и лучшие инструменты, которые я нашел, часто предназначались для определенных форматов. Например, «photorec» был великолепен, когда я хотел восстановить десятки тысяч jpeg.

Recuva также помог мне до сих пор и может быть вашим лучшим выбором. (Это бесплатно, не обманывайте своих объявлений)

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

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

4
PriceChild
  • Единственный правильный ответ: восстановить файл из резервной копии. У всех должна быть резервная копия. Для действительно важных файлов у вас должно быть две резервные копии. Ты не? Что ж, очень плохо, вот урок (извините за грубость, но я нахожусь в хранилище данных, и люди не копируют, пока не потеряли некоторые важные данные, это факт. Так что да, вы выглядите глупо, но так почти все остальные).

  • ОК, у вас нет резервной копии. Вы должны остановить использовать файловую систему, которая содержала файл ПРЯМО СЕЙЧАС . Любая операция записи может определенно удалить данные файла, которые могут (только могут) остаются на диске.

  • если вы допустили трагическую ошибку, указав только один раздел в качестве корневой файловой системы и/home, это означает, что вы must загружаетесь с другого устройства.СЕЙЧАС.

  • Если ваш файл имеет какой-либо общий формат (файл Word, JPG и т.д.), Используйте Photorec . Photorec может получить наиболее распространенные форматы файлов.

  • Вы можете попробовать метод "ext3 undelete", предложенный ранее, но вам нужно уметь работать с командной строкой, понимать основные принципы работы Linux и т.д.

  • Если ваш файл имеет какой-то особый формат, то повезло Однажды я написал Perl-программу для сканирования дисков на наличие специальных файлов, и она работала довольно хорошо; но для этого вам нужно знать некоторые программы, и с linux тоже не спеша.

4
wazoox

Если у вас открыто приложение, которое в данный момент читает файл, такое как VLC или LibreOffice, то этот потрясающий ответ L & U.SO выручил меня из этого беспорядка. Вот альтернативный метод для того же.

Основная идея заключается в том, чтобы найти ссылку в /proc/PID/fd/DESCRIPTOR_NUMBER и скопировать ее обратно в исходное местоположение. Используйте ps aux | grep APP_NAME, чтобы найти PID, а затем ls -la /proc/PID/fd/, чтобы найти правильный DESCRIPTOR_NUMBER.

2
dotancohen

Вот отличный документ для вас. Там вы найдете множество практических советов.

Кстати, есть две группы людей:

  1. те, кто делает резервные копии
  2. те, кто будет делать резервные копии

Поздравляю, вы только что повысили себя до группы 2. ;-)

2
Michał Šrajer

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

TestDisk - отличный инструмент, и существуют другие способы сохранения некоторых данных с физического диска в зависимости от файловой системы и времени удаления, но время и боль могут быть слишком большими, поэтому KEEP BACKUPS (а также проверьте, что они действительны и восстанавливаемы)!

1
Andy Lee Robinson

Если это не перезаписано другими пользователями, то вам повезло. Я случайно удалил исходный файл cpp и использовал инструмент foremost , который помог мне восстановить 60G cpp-мусора с диска. Наконец, я восстановил свой файл, собирая эти обломки по частям. Я думаю, что он сканирует определенный шаблон для конкретного типа файла и обходит все inode на диске, чтобы восстановить файлы! Просто попробуйте!

1
Izana

Если вы случайно удалили файл из Linux, вы можете использовать эту команду:

find /root -name "search text" -type f  -exec mv {} "/home" \;

вместо search text вы можете указать имя файла и указать каталог, который вы хотите восстановить вместо /home.

0
santosh

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

https://github.com/nateshmbhat/safe-rm

Особенности :

  • предназначен для использования вместо рм
  • обрабатывает все аргументы, которые может принять rm
  • обрабатывает столкновения имен файлов с файлами, уже находящимися в корзине
  • автоматически обрабатывает некоторые проблемы с разрешениями
  • если rm вызывается из любого другого скрипта или косвенно, то системная команда 'rm' используется автоматически
  • показывает соответствующие сообщения об ошибках, подобные тем, которые появляются в rm
0
Natesh bhat