Случайно я использовал rm для файла, который не хотел удалять. Есть ли способ вернуть его под Linux?
63
15 ответов
49
Ниже приведены общие шаги для восстановления текстовых файлов.
Сначала используйте команду wall, чтобы сообщить пользователю, что система отключается в однопользовательском режиме:
# wall System is going down to .... please save your work.Нажмите CTRL+D, чтобы отправить сообщение.
Затем используйте команду init 1, чтобы перевести систему в однопользовательский режим:
# init 1Использование 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Затем используйте vi, чтобы увидеть file.txt.
Этот метод полезен, только если удаленный файл является текстовым файлом. Если вы используете файловую систему ext2, попробуйте восстановить команду.
Находится на http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html.
13
- Если это очень-очень важно, возьмите диск с компьютера и наймите компанию, которая сделает это за вас.
- Если это только очень важно, смонтируйте диск только для чтения, скопируйте весь раздел в файл, используя
ddи попытайтесь найти файл внутри него (используяgrepили редактор).
Изменить: иногда ddrescue работает лучше, чем dd .
8
Testdisk имеет отмененный вариант, который должен работать с Linux.
Существует пошаговое руководство для Linux. Обратите внимание, что это работает для ext2, ext3 и ext4.
5
Если это стандартный rm, надеюсь, у вас есть резервная копия. Процедура восстановления удаленного файла будет разной для каждой файловой системы, если это вообще возможно сделать. В Linux нет встроенной корзины. как только вы удалите файл, он почти исчез.
В любом случае вы захотите отключить компьютер от сети - как можно скорее, так как продолжение работы компьютера (даже выключение) вызывает запись на диск и увеличивает вероятность того, что некоторые блоки ранее были заняты файл будет перезаписан. Как только вы это сделаете, либо вставьте его в другой компьютер, перезагрузите живой CD (не устанавливайте диск, если вы не монтируете его только для чтения), либо извлеките жесткий диск и отнесите его специалисту по восстановлению данных.
4
Установите ваши ожидания на низком уровне. Если что-то было записано поверх «удаленных» данных, вы потеряете это.
Я провел небольшое количество восстановления, и лучшие инструменты, которые я нашел, часто предназначались для определенных форматов. Например, «photorec» был великолепен, когда я хотел восстановить десятки тысяч jpeg.
Recuva также помогла мне до сих пор и может быть вашим лучшим выбором. (Это бесплатно, не обманывайте их рекламой)
В конце дня, если то, что вы потеряли, важно, отключите диск и прекратите запись на него. Используйте все части программного обеспечения для восстановления, которые вы можете найти, пока не вернете свои данные или они не перестанут стоить того. Если это действительно важно, отправьте его профессионалам по высокой цене.
Если вам повезло с инструментом раньше, попробуйте еще раз, так как вы знакомы с ним. В конце концов, они не должны записывать на диск, поэтому вы можете использовать программное обеспечение, пока не найдете работающее.
4
Единственный правильный ответ: восстановить файл из резервной копии. У всех должна быть резервная копия. Для действительно важных файлов у вас должно быть две резервные копии. Вы не? Ну, очень плохо, вот урок (Извините, что звучит грубо, но я нахожусь в хранилище данных, и люди не копируют, пока не потеряли некоторые важные данные, это факт. Так что да, ты выглядишь глупо, но почти все остальные).
ОК, у вас нет резервной копии. Вы должны прекратить использование файловой системы, которая содержала файл ПРЯМО СЕЙЧАС . Любая операция записи может определенно скрыть данные файла, которые могут (только могут) оставаться на диске.
если вы допустили трагическую ошибку, чтобы использовать только один раздел в качестве корневой файловой системы и /home, это означает, что вы должны загрузиться с какого-то другого устройства. СЕЙЧАС
Если ваш файл имеет какой-то общий формат (файл Word, JPG и т.д.), Используйте Photorec . Photorec может получить наиболее распространенные форматы файлов.
Вы можете попробовать метод "ext3 undelete", предложенный ранее, но вы должны быть знакомы с командной строкой, понимать основные внутренние механизмы Linux и т.д.
Если ваш файл имеет какой-то особый формат, вам не повезло. Однажды я написал Perl-программу для сканирования диска на наличие специальных файлов, и она работала довольно хорошо; но для этого вам нужно знать некоторые программы, а также быть уверенным в Linux.
4
Я сделал это пару лет назад. Мой подход состоял в том, чтобы напрямую, не терять времени, размонтировать раздел, а затем
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 . ~ Половина моего ~ была удалена, но мне удалось вернуть все ценное через описанные выше grep и некоторые более или менее текущие резервные копии. У меня были некоторые очень ценные (читай: отнимающие много времени) и самые последние данные измерений на диске, которые были утеряны, но я сделал четырехкратное резервное копирование. Один здесь разочаровался, другой из-за сбоя системы в школе, другой был поврежден, и сначала я не смог найти четвертый, так как я по ошибке положил его в неправильную папку :-D. Если бы rm -r не застрял в файле, защищенном от записи, четвертый был бы съеден, так как эта папка была смонтирована через sshfs в моем ~ . С тех пор я гораздо осторожнее с такими вещами.
2
Если у вас открыто приложение, которое в данный момент читает файл, такое как VLC или LibreOffice, то этот потрясающий ответ L & U.SO помог мне выйти из этого беспорядка. Вот альтернативный способ сделать то же самое.
Основная идея состоит в том, чтобы найти ссылку в /proc/PID/fd/DESCRIPTOR_NUMBER и скопировать ее обратно в исходное местоположение. Используйте ps aux | grep APP_NAME чтобы найти PID, а затем ls -la /proc/PID/fd/ чтобы найти правильный DESCRIPTOR_NUMBER.
2
Вот отличный документ для вас. Там вы найдете множество практических советов.
Кстати, есть две группы людей:
- те, кто делает резервные копии
- те, кто будет делать резервные копии
Поздравляю, вы только что повысили себя до группы 2. ;-)
1
"Правильный" ответ состоит в том, чтобы предположить, что нет способа надежного восстановления, и вместо этого восстановить из резервных копий или клонированной системы или переустановить.
TestDisk - отличный инструмент, и существуют другие способы сохранения некоторых данных с физического диска в зависимости от файловой системы и времени удаления, но время и боль могут быть слишком велики, поэтому сохраняйте резервные копии (а также тестируйте что они действительны и восстанавливаемы)!
1
Если это не перезаписано другими пользователями, то вам повезло. Я случайно удалил исходный файл cpp и использовал инструмент под названием foremost, который помог мне восстановить 60G cpp-мусора с диска. Наконец, я восстановил свой файл, собирая эти обломки по частям. Я думаю, что он сканирует определенный шаблон для конкретного типа файла и обходит все inode на диске для восстановления файлов! Просто попробуйте!
0
Если вы случайно удалили файл из Linux, вы можете использовать эту команду:
find /root -name "search text" -type f -exec mv {} "/home" \;
вместо search text для поиска вы можете указать имя файла и указать каталог, куда вы хотите восстановить вместо /home .
0
Вы можете попробовать этот скрипт. Работает хорошо и предназначен для использования вместо rm, и я сейчас активно его использую.
https://github.com/nateshmbhat/safe-rm
Особенности :
- предназначен для использования вместо рм
- обрабатывает все аргументы, которые может принять rm
- обрабатывает столкновения имен файлов с файлами, уже находящимися в корзине
- автоматически обрабатывает некоторые проблемы с разрешениями
- если rm вызывается из любого другого скрипта или косвенно, то системная команда 'rm' используется автоматически
- показывает соответствующие сообщения об ошибках, подобные тем, которые появляются в
rm
-2
У меня была та же проблема на прошлой неделе, и я пробовал много программ, таких как 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’
Это видео показывает мини-учебник, который может вам помочь.