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

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

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

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
   

   ИЛИ ЖЕ

   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» в / 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.

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

Изменить: иногда ddrescueработает лучше, чем dd.

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

Testdisk имеет отмененный вариант, который должен работать с Linux.

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

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

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

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

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

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

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

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

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видимому, это была символическая ссылка и единственный файл, соответствующий этому, оболочка превращена в

rm -r foo\ foo *

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функции :

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

У меня была та же проблема на прошлой неделе, и я пробовал много программ, таких как 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’

Это видео показывает мини-учебник, который может вам помочь.