65
65
Как восстановить удаленный файл под Linux?
Случайно я использовал rm на файле, который не хотел удалять. Есть ли способ вернуть его обратно под Linux?
Случайно я использовал rm на файле, который не хотел удалять. Есть ли способ вернуть его обратно под Linux?
Ниже приведены общие шаги по восстановлению текстовых файлов.
Сначала используйте команду “Стена”, чтобы сообщить пользователю, что система выходит из строя в однопользовательском режиме:
Затем используйте команду init 1, чтобы перевести систему в однопользовательский режим:
Использование grep (традиционный UNIX способ) для восстановления файлов
Далее используйте vi для просмотра file.txt.
Найдено по адресу http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html .
dd, и попытайтесь найти файл внутри него (используя grep, или редактор). Правка: иногда ddrescue работает лучше, чем dd.
Я сделал это пару лет назад. Мой подход заключался в том, чтобы напрямую, не теряя времени, размонтировать раздел, а затем
dd if=/dev/hda1 of=backup_image.ext3
иметь резервный файл с точным состоянием раздела. Затем вы можете смонтировать раздел еще раз и продолжить работу в обычном режиме по мере поиска удаленного файла в созданном образе. Образ, скорее всего, будет ОЧЕНЬ большим, так как вам нужно все “пустое” пространство, поэтому его хранение может стать практичной проблемой.
Тогда это было просто для выполнения скучного поиска после текстовых фрагментов, которые я ожидал оказаться где-то в супе с содержимым раздела. Например, чтобы найти .текстовые файлы, я запустил
grep --binary-files=text -1000 "subsection" < backup_image.ext3 > latexfiles
, который напечатал большой контекст вокруг фразы “подраздел” и сохранил вывод в файл для ручного поиска. Я распечатал такой большой контекст, так как поиск по изображению занял столько времени, что я не хотел бы делать это чаще, чем должен был.
Также команда strings помогла удалить бинарный мусор из вывода, но, если я правильно помню, она также удалила все новые строки, что могло стать проблемой.
Чтобы найти бинарные файлы таким же образом, можно успешно найти характерный заголовок или что-то вроде определенного файла, но я представляю это довольно большим приключением.
Краткое техническое примечание: есть технические сложности с восстановлением диска и Ext3/4. Это долго объяснять, но кратко (и неадекватно): Ext3/4 удаляет “маркеры”, которые сообщают операционной системе, где находятся файлы на диске при их удалении. Файлы не стираются, но уже никто не знает, где на диске они начинаются и заканчиваются, а иногда они даже фрагментируются в нескольких местах. Некоторые другие файловые системы просто устанавливают статус файлов “удалены”, но сохраняют данные о местонахождении. Тогда неудалить не сложнее, чем посмотреть на файловые указатели с этим флагом (они все равно должны быть доступны, если не произошло слишком большой активности), а потом надеяться, что их содержимое не было перезаписано.
Что лучше? Риторический, на мой взгляд. Частое резервное копирование - это ответ на все эти проблемы. Важные данные без автоматического резервного копирования системы случайно ждет, IMHO.
Обязательный личный анекдот: Я собирался удалить foo\ foo* из ~. Я написал
rm -r foo<Tab>*
, который, к сожалению, так как foo, видимо, была симлинк и единственный файл, соответствующий этому, оболочка, сделанная в
rm -r foo\ foo *
я нажал Enter и сидел там, глядя на команду, которая должна была занять секунду максимум. Через некоторое время rm спросила меня, хочу ли я “удалить файл с защитой от записи ‘что-то’”, и я быстро почувствовал озноб, и мягко и очень контролируемо нажал Ctrl+c. ~ Половина моей ~ была удалена, но мне удалось вернуть все ценное через описанную выше grepping и некоторые более или менее текущие бэкапы. У меня были некоторые лично очень ценные (читайте: трудоемкие) и самые последние данные измерений на диске, которые были потеряны, но я сделал четырехкратное резервное копирование. Одно здесь разочаровался, другое из-за перебоев в работе системы в школе, третье было повреждено, а четвертое я сначала не смог найти, так как по ошибке поместил его не в ту папку :-D . Если бы rm -r не застряла в файле с защитой от записи, четвертая была бы съедена, так как эта папка была смонтирована через sshfs в моей ~. С тех пор я гораздо осторожнее отношусь к таким вещам.
Единственный правильный ответ: восстановить файл из резервной копии. Все должны иметь резервную копию. Для действительно важных файлов у вас должно быть две резервные копии. А у вас нет? Очень жаль, но вот вам урок ( Простите, что звучу грубо, но я нахожусь в хранилище данных, и люди не делают резервных копий, пока не потеряют какие-то важные данные, это факт. Так что да, вы выглядите глупо, но и почти все остальные тоже).
Хорошо, у вас нет резервной копии. вы должны стоп использовать файловую систему, которая содержала файл ПРАВИЛЬНО СЕЙЧАС. Любая активность при записи определённо может привести к тому, что данные файла may (только may) останутся на диске.
если вы допустили трагическую ошибку, используя только один раздел в качестве корневой файловой системы и /home, то это означает, что вы must должны загрузиться с какого-то другого устройства. NOW.
если ваш файл имеет какой-то общий формат ( файл Word, JPG и т.д.), используйте Photorec . Photorec может получить наиболее распространенные форматы файлов.
Вы можете попробовать метод “ext3 undelete”, предложенный ранее, но вы должны быть удобны в командной строке, понимать основные внутренние механизмы linux и т.д.
Если ваш файл имеет какой-то особый формат, то вам не повезло. Однажды я написал Perl программу для сканирования диска на наличие некоторых специальных файлов, и она работала довольно хорошо, но для этого вам нужно знать некоторые программы, и быть вполне комфортно с linux тоже.
Если это стандартная rm , надеюсь, у вас есть резервная копия. Процедура восстановления удаленного файла будет разной для каждой файловой системы, если это вообще возможно. В Linux нет встроенной “корзины”; как только вы удаляете файл, все пропадает.
Любым способом, вы захотите отключить компьютер - как можно быстрее, так как продолжение работы компьютера (даже для его выключения) приводит к записи на диск и увеличивает шанс того, что некоторые блоки, ранее занятые файлом, будут перезаписаны. После этого, либо поместите его на другой компьютер, перезагрузите live CD (убедитесь, что диск не смонтирован, если вы не смонтируете его только для чтения), либо извлеките жесткий диск и отнесите его специалисту по восстановлению данных.
Установите свои ожидания на низком уровне. Если что-то было записано поверх “удаленных” данных, вы потеряете это.
Я сделал небольшое количество восстановления, и лучшие инструменты, которые я нашел, часто были разработаны для определенных форматов. Например, “photorec” был великолепен, когда я хотел восстановить десятки тысяч jpegs. Recuva также помогала мне и раньше и может быть вашим лучшим выбором. (Это бесплатно, не обманывайте себя в оплате своей рекламы)
В конце концов, если то, что вы потеряли важно, возьмите диск в автономном режиме и перестаньте записывать на него. Используйте каждое программное обеспечение для восстановления, которое вы можете найти до тех пор, пока вы не получите свои данные обратно или они перестанут стоить того. Если это действительно важно, отправьте его профессионалам по высокой цене.
Если вам повезло с инструментом раньше, попробуйте еще раз, так как вы знакомы с ним. В конце концов, они не должны записывать на диск, так что вы можете использовать программное обеспечение, пока не найдете тот, который работает.
Если у вас открыто приложение, которое в данный момент читает файл, например, VLC или LibreOffice, то этот потрясающий ответ L&U.SO помог мне выбраться из этой путаницы. Вот альтернативный метод для того, чтобы сделать то же самое.
Общая идея заключается в том, чтобы найти ссылку в /proc/PID/fd/DESCRIPTOR_NUMBER и скопировать ее обратно в ее оригинальное местоположение. Используйте ps aux | grep APP_NAME для поиска PID, а затем ls -la /proc/PID/fd/ для поиска нужного DESCRIPTOR_NUMBER.
Если он не переписан другими пользователями, то вам повезло. Я случайно удалил свой cpp исходный файл и использовал утилиту под названием прежде всего , которая помогла мне восстановить 60G cpp обломки с диска. Наконец, я восстановил свой файл, собирая этот мусор по частям. Я думаю, что он сканирует определенный шаблон на наличие определенного типа файлов и обходит все входы на диске, чтобы восстановить файлы! Просто попробуйте!
Правильный" ответ заключается в том, чтобы предположить, что нет способа надежного восстановления, а вместо этого восстановить из резервной копии или клонированной системы или переустановить.
TestDisk является отличным инструментом, и есть другие способы, чтобы иметь возможность спасти некоторые данные с физического диска в зависимости от файловой системы и recency удаления, но время и боль, связанная с этим может быть просто слишком большим, так что KEEP BACKUPS (а также проверить, что они действительны и восстанавливаются)!
Вот вам отличный документ . Там вы найдете массу практических советов.
BTW, есть две группы людей:
те, кто делает резервное копирование
те, кто будет делать резервное копирование
Поздравляю, вы только что перешли в группу 2. ;-)
Можешь попробовать этот сценарий. Работает хорошо и предназначен для использования вместо rm, и я использую его широко сейчас. https://github. com/nateshmbhat/safe-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’
Это видео показывает мини-учебник, который может помочь вам.